Elige la estrategia de consulta adecuada para Azure Resource Graph

Azure Resource Graph (ARG) está diseñado para consultas rápidas y a gran escala en tus recursos de Azure. Como ARG indexa los datos de forma asíncrona, es importante entender cuándo consultar directamente ARG y cuándo recurrir al proveedor de recursos (RP) que posee el recurso, es decir, la fuente de verdad para su estado de recurso. Este artículo explica cómo encaja ARG en el plano de control de Azure, cuándo usar una estrategia híbrida ARG + RP de consulta, y cómo elegir entre RP, la API de consulta de ARG y su API Get/List.

Cómo encaja el ARG en el plano de control de Azure

El plano de control de recursos tiene tres componentes:

• Azure Resource Manager (ARM) – la pasarela de solicitudes para ARG. ARM enruta las solicitudes a ARG sin necesidad de realizar llamadas individuales a cada proveedor de recursos.

• Proveedores de recursos (por ejemplo, el Proveedor de Recursos de Cálculo, o CRP) – la fuente de verdad para el estado del recurso. Las llamadas directas a las APIs de un proveedor de recursos devuelven datos fuertemente consistentes.

• Azure Resource Graph (ARG) – un índice asíncrono sobre datos del plano de control, diseñado para consultas escalables y de alto rendimiento a través de grandes conjuntos de recursos. ARG es casi en tiempo real; sigue un modelo de consistencia eventual debido a la naturaleza distribuida del sistema que sustenta la API. Va por detrás de la fuente de verdad por un breve periodo, a veces más por si hay alguna interrupción en el backend.

ARG se mantiene sincronizado mediante dos mecanismos: notificaciones de cambios asíncronas de ARM y proveedores de recursos, y pases periódicos de conciliación que detectan cualquier notificación que haya pasado por alto.

Utilizar una estrategia de consulta híbrida para escenarios críticos

En escenarios donde la frescura y fiabilidad de los datos importan, utiliza una estrategia híbrida: consulta el ARG para escalar y recurre a la API del proveedor de recursos cuando detectes un problema de frescura de datos, un retraso en la indexación o una latencia elevada, o antes de tomar una acción crítica basada en el estado del recurso. Este enfoque evita dos modos de fallo a la vez: el coste de llamar siempre directamente al RP y el riesgo de actuar sobre datos ARG obsoletos como si estuvieran vigentes (por ejemplo, reiniciar o desprovisionar un recurso basándose en un estado desactualizado).

Escenarios comunes

Consulta inmediatamente después de la creación del recurso - Algunos flujos de trabajo consultan un recurso en un plazo de 1–2 segundos tras crearlo — por ejemplo, esperando a provisioningState que alcance un estado final o esperando a que aparezcan ciertas propiedades en la respuesta. Como la indexación ARG puede no estar completa, una consulta emitida poco después de la creación puede devolverla 404 Not Found aunque el recurso exista. Utiliza una estrategia híbrida para evitar falsos negativos: si ARG devuelve un "no encontrado" inmediatamente después de una operación de escritura, recurre al proveedor de recursos antes de tratarlo como un error.

Verificación del estado antes de una operación destructiva - Si tu flujo de trabajo utiliza ARG para identificar recursos candidatos a una operación, y esa operación es destructiva (eliminar, reiniciar, desprovisionar), no actúes directamente sobre el resultado del ARG. La latencia del backend puede dejar desactualizada la vista de ARG sobre un recurso. Este riesgo es significativo cuando la acción resultante no puede deshacerse.

Directrices para gestionar la coherencia eventual para ARG

• Verifica solo antes de acciones irreversibles, no en todas las encuestas. Añade una segunda comprobación del proveedor de recursos antes de flujos de trabajo que afecten al cliente o sean destructivos — no en todas las consultas ARG. Verificar cada encuesta va en contra del propósito de usar ARG y puede desencadenar la limitación a gran escala. El patrón es: confiar en ARG para la identificación y la escalabilidad, y verificar con la fuente de verdad justo antes de cualquier acción irreversible.

  Tip

  Si verificar el volumen de tu operación genera preocupaciones sobre la limitación, contacta con Microsoft antes de alcanzar un límite. Los aumentos de cuota para apoyar este patrón son una solicitud justificable y esperada, no un caso límite.

• Añade el tiempo de espera entre consultas ARG posteriores cuando tu escenario lo permita. Cuando sí, usa retroceso exponencial: empieza con un par de segundos antes del primer intento y aumenta el tiempo de espera con cada intento posterior (por ejemplo, 2s → 4s → 8s → 16s...) hasta un límite de unos minutos. Deja de aumentar cuando alcances ese límite y sigue haciendo sondeos en el intervalo límite o recurre a la API del proveedor de recursos.

• Considera la API ARG Get/List para sondeos de alta frecuencia. Consulta esta sección que explica más sobre cómo configurar un respaldo con la API Get/List.

Comparación de API

Usa esta tabla para decidir qué API se adapta a tu situación.

Tanto el patrón híbrido de respaldo como la API Get/List ayudan a garantizar que obtengas el estado del recurso más preciso disponible, sin que te bloqueen breves desfases en la actualización de los datos.