Kies de juiste querystrategie voor Azure Resource Graph

Azure Resource Graph (ARG) is gebouwd voor snelle, grootschalige queries over je Azure-resources. Omdat ARG data asynchroon indexeert, is het belangrijk te begrijpen wanneer je ARG direct moet opvragen en wanneer je moet terugvallen op de resource provider (RP) die de resource bezit – de bron van waarheid voor de resourcestatus. Dit artikel legt uit hoe ARG past in het Azure-controlevlak, wanneer een hybride ARG + RP-querystrategie gebruikt moet worden, en hoe je kunt kiezen tussen RP, de Query API van ARG en de Get/List API.

Hoe ARG past in het Azure-controlevlak

Het resource control plane bestaat uit drie componenten:

• Azure Resource Manager (ARM) – de request gateway voor ARG. ARM stuurt verzoeken naar ARG zonder dat er individuele aanroepen naar elke resource provider hoeven te worden gedaan.

• Resource providers (bijvoorbeeld de Compute Resource Provider, of CRP) – de bron van waarheid voor resourcestatus. Directe aanroepen naar de API's van een resource provider leveren sterk consistente data terug.

• Azure Resource Graph (ARG) – een asynchrone index voor gegevens van het besturingsvlak, ontwikkeld voor query's met hoge doorvoer die schaalbaar zijn voor grote resourceverzamelingen. ARG is bijna real-time en volgt een uiteindelijk consistent model, vanwege de gedistribueerde aard van het systeem dat de API ondersteunt. Het loopt kort achter op de bron van de waarheid, soms zelfs langer als er backend-onderbrekingen zijn.

ARG blijft gesynchroniseerd via twee mechanismen: asynchrone wijzigingsmeldingen van ARM en resourceproviders, en periodieke reconciliatierondes die alles opvangen wat een melding heeft gemist.

Gebruik een hybride querystrategie voor kritieke scenario's

In situaties waarin datavernieuwing en databetrouwbaarheid belangrijk zijn, gebruik een hybride strategie: zoek naar ARG voor schaalbaarheid, en val terug op de resource provider API wanneer je een probleem met dataversheid, een indexeringsvertraging of verhoogde latentie detecteert, of voordat je een kritieke actie onderneemt op basis van resourcestatus. Deze aanpak voorkomt twee faalmodi tegelijk – de kosten van altijd direct aanroepen van de RP, en het risico om te handelen op verouderde ARG-data alsof deze actueel is (bijvoorbeeld het herstarten of deprovisioneren van een resource op basis van verouderde toestand).

Veelvoorkomende scenario's

Polling direct na het aanmaken van een resource - Sommige workflows pollen een resource binnen 1–2 seconden na het aanmaken — bijvoorbeeld wachten tot provisioningState een eindtoestand is bereikt, of wachten tot bepaalde eigenschappen in de respons verschijnen. Omdat ARG-indexering mogelijk niet compleet is, kan een query die zo kort na creatie wordt uitgevoerd terugkeren 404 Not Found , ook al bestaat de resource. Gebruik een hybride strategie om valse negatieven te voorkomen: als ARG direct na een schrijfactie de status 'niet gevonden' retourneert, schakel dan terug naar de resourceprovider voordat je dit als een fout behandelt.

Status verifiëren vóór een destructieve operatie - Als je workflow ARG gebruikt om kandidaatbronnen voor een operatie te identificeren, en die operatie is destructief (delete, restart, deprovision), handel dan niet direct op het ARG-resultaat. Backend-latentie kan ervoor zorgen dat het ARG-beeld van een resource verouderd is. Dit risico is aanzienlijk wanneer de resulterende actie niet ongedaan kan worden gemaakt.

Richtlijnen voor het omgaan met uiteindelijke consistentie voor ARG

• Controleer alleen vóór onomkeerbare acties, niet bij elke peiling. Voeg een secundaire resourceprovider-check toe vóór klantbeïnvloedende of destructieve workflows — niet bij elke ARG-query. Elke pollaanvraag controleren ondermijnt het doel van ARG en kan op grote schaal throttling veroorzaken. Het patroon is: vertrouw op ARG voor identificatie en schaal, verifieer bij de bron van waarheid vlak voordat je iets onomkeerbaars doet.

  Tip

  Als verificatie op het volume van je operatie zorgen oproept over beperking, neem dan contact op met Microsoft voordat je een limiet bereikt. Quotaverhogingen ter ondersteuning van dit patroon zijn een aanvaardbare, verwachte vraag — geen uitzondering.

• Voeg de wachttijd toe tussen volgende ARG-query's waar jouw scenario het toelaat. Waar het zo is, gebruik exponentiële backoff: begin met een paar seconden voor de eerste herpoging, en verleng de wachttijd bij elke volgende poging (bijvoorbeeld 2s → 4s → 8s → 16s...) tot een maximum van enkele minuten. Stop met verhogen zodra je dat plafond bereikt, en blijf pollen op het gelimiteerde interval of val terug op de resource provider API.

• Overweeg de ARG Get/List API voor hoogfrequente polling. Zie deze sectie die meer gaat over het opzetten van een fallback met de Get/List API.

API-vergelijking

Gebruik deze tabel om te bepalen welke API bij jouw situatie past.

Zowel het hybride fallback-patroon als de Get/List API helpen ervoor te zorgen dat je de meest nauwkeurige resourcestatus ophaalt, zonder geblokkeerd te worden door kortstondige data-versheidsgaps.