Microsoft AZ-204: Supervisión, diagnóstico e integración con DevOps de Azure — Guía de estudio

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Forma parte de la Microsoft Azure Developer Associate AZ-204 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Descripción general

Azure Monitor y Application Insights proporcionan una pila de observabilidad unificada y centrada en el desarrollador para las aplicaciones de Azure. Application Insights recopila telemetría de la aplicación, como solicitudes, dependencias, excepciones y trazas, mientras que Azure Monitor agrega métricas y registros de todos los recursos en un área de trabajo de Log Analytics e impulsa las alertas y las integraciones de DevOps. Dominar las opciones de instrumentación, la semántica de la telemetría, las pruebas de disponibilidad, el Kusto Query Language (KQL), las alertas con grupos de acciones, el seguimiento distribuido y la infraestructura como código con plantillas ARM garantiza soluciones fiables, diagnosticables y automatizables.

Instrumentación y telemetría de Application Insights

Los recursos de Application Insights se identifican para la ingesta mediante una clave de instrumentación o una cadena de conexión. La clave de instrumentación es el GUID único heredado que utilizan los SDK para enrutar la telemetría. La cadena de conexión es la recomendación actual; incluye la clave de instrumentación más metadatos de los puntos de conexión (endpoints de ingesta y de Live Metrics) y permite el enrutamiento a puntos de conexión no predeterminados (para nubes soberanas o privadas). Utilice la cadena de conexión en el código y la configuración nuevos; permite futuros cambios en los puntos de conexión sin necesidad de volver a implementar el código. Dentro de un App Service, habilitar Application Insights a nivel de plataforma rellenará la cadena de conexión en la configuración del entorno para los entornos de ejecución detectados automáticamente.

La instrumentación se puede realizar a través de un SDK o mediante instrumentación automática. El enfoque de SDK (por ejemplo, Microsoft.ApplicationInsights.AspNetCore para .NET, applicationinsights para Node.js y el agente de Application Insights para Java) ofrece control a nivel de código: eventos personalizados, métricas y telemetría enriquecida a través de TelemetryInitializers y procesadores, incluido el muestreo adaptativo. La instrumentación automática (vinculación sin código) está disponible para App Service y algunas pilas de computación, y utiliza extensiones/agentes del sitio para recopilar solicitudes entrantes, dependencias y excepciones sin cambios en el código. Utilice la instrumentación por SDK cuando necesite eventos personalizados, métricas de negocio o correlación explícita en trabajos en segundo plano; utilice la vinculación sin código para una visibilidad rápida y de bajo esfuerzo o para cargas de trabajo de tipo lift-and-shift. En ambos casos, establezca el nombre del rol en la nube (cloud role name) para distinguir los servicios en una arquitectura de microservicios y configure el muestreo cuidadosamente para equilibrar la fidelidad y el coste.

Application Insights emite varios tipos de telemetría principales:

Las Solicitudes capturan operaciones entrantes (solicitudes HTTP, invocaciones de funciones), con duración, código de respuesta y éxito.
Las Dependencias capturan llamadas salientes (HTTP, SQL, llamadas a SDK de Azure, colas), con el destino, tipo, duración y éxito.
Las Excepciones capturan errores lanzados, seguimientos de pila y excepciones controladas cuando se rastrean explícitamente.
Las Trazas capturan mensajes de registro; los SDK se integran con los marcos de registro populares para que los registros y la telemetría compartan la correlación.
Los Eventos capturan sucesos personalizados a nivel de negocio a través de TrackEvent, admitiendo dimensiones y recuentos personalizados.
Las Métricas capturan mediciones numéricas; puede realizar un seguimiento de métricas personalizadas para los KPI e inspeccionarlas en el Explorador de métricas.

El seguimiento distribuido en Application Insights se basa en la correlación. Cada operación de extremo a extremo tiene un ID de operación (ID de traza en términos de W3C) que se comparte entre la telemetría relacionada; cada tramo (span) tiene relaciones padre-hijo que se aplican mediante encabezados de propagación. Los SDK modernos utilizan el W3C Trace Context (traceparent, tracestate). El campo Operation_Id en KQL vincula las Solicitudes, Dependencias, Excepciones y Trazas para la misma transacción. Asegúrese de que los clientes HTTP salientes propaguen los encabezados; para .NET, System.Diagnostics.Activity y el SDK de AI se encargan de esto automáticamente. El seguimiento de dependencias instrumenta clientes comunes (HTTP, SQL, Service Bus, Storage). Cuando los servicios cruzan fronteras (p. ej., de App Service a AKS), una propagación coherente produce un único mapa de transacciones conectado. Para flujos asíncronos y basados en mensajes, asegúrese de que los SDK capturen y transmitan los ID de correlación en los metadatos del mensaje; la mayoría de los SDK de Azure lo hacen por defecto.

Pruebas de disponibilidad y monitorización sintética

Las pruebas de disponibilidad validan la accesibilidad externa y la capacidad de respuesta desde múltiples geografías. La prueba de ping de URL emite solicitudes HTTP a una frecuencia configurada desde múltiples ubicaciones de prueba y valida los códigos de estado, la salud del SSL y, opcionalmente, la coincidencia de contenido. Utilice reintentos y múltiples ubicaciones para reducir los falsos positivos y configure alertas sobre los fallos de las pruebas para recibir notificaciones procesables.

Las pruebas de disponibilidad de varios pasos ejecutaban históricamente secuencias grabadas de solicitudes HTTP con cookies de estado para verificar flujos de trabajo. Las pruebas web clásicas de varios pasos han sido retiradas; para escenarios de múltiples solicitudes o autenticados, implemente pruebas sintéticas instrumentando su propio cliente o servicio utilizando la API TrackAvailability (o exportadores de OpenTelemetry) para emitir AvailabilityTelemetry. Este enfoque permite la autenticación personalizada, cargas útiles (payloads) y validación específica del dominio, al tiempo que se conservan los informes y las alertas centralizados.

El uso personalizado de TrackAvailability le da control sobre:

Nombre de la prueba, ubicación de ejecución e identificadores de secuencia para el análisis de tendencias y la deduplicación.
Duración y semántica de éxito basadas en sus validaciones, no solo en el estado HTTP.
Mensajes enriquecidos y dimensiones personalizadas para obtener pistas sobre la causa raíz y para la correlación con la telemetría del backend.

Combine las pruebas de disponibilidad con la telemetría de dependencias y solicitudes del backend para diferenciar rápidamente los problemas de disponibilidad del punto de conexión (red, DNS, TLS) de los fallos de la aplicación (excepciones, tiempos de espera) y las interrupciones de servicios dependientes (SQL, API externas). Vincule los fallos de las pruebas de disponibilidad a grupos de acciones para impulsar los flujos de trabajo de incidentes.

Datos de Azure Monitor, KQL y alertas con grupos de acciones

Azure Monitor ingesta dos tipos de datos principales: métricas y registros. Las métricas son series temporales numéricas y ligeras con ingesta casi en tiempo real y segmentación multidimensional (p. ej., por instancia, ruta de API). Son ideales para la detección rápida (CPU, memoria, tasa de solicitudes, latencia, disponibilidad) y admiten hasta 93 días de retención por defecto. Los registros son registros estructurados y consultables almacenados en un área de trabajo de Log Analytics e incluyen datos de Application Insights, registros de recursos de la plataforma y registros personalizados con retención configurable. Utilice la configuración de diagnóstico (Diagnostic settings) para enrutar las métricas de la plataforma y los registros de recursos a un área de trabajo, Event Hub o Storage para archivado y análisis.

Kusto Query Language (KQL) impulsa el análisis exploratorio, los paneles y las alertas de registro. Los patrones principales incluyen:

Consultas básicas: Table | take 10 para un muestreo rápido; restrinja siempre el tiempo con where TimeGenerated >= ago(…) al principio para mejorar el rendimiento.
Filtrado y proyección: Table | where Column == “Value” | project KeyColumns para reducir la carga útil (payload) y centrar el análisis.
Agregación: summarize count() by bin(TimeGenerated, 5m), Dimension para calcular tasas, percentiles o promedios; use percentile() y make-series para gráficos de tiempo.
Uniones (Joins): join kind=inner o leftouter sobre claves de correlación como operation_Id para conectar Requests con Dependencies o Exceptions; para uniones entre recursos, asegúrese de que ambos envíen datos a la misma área de trabajo o habilite las consultas entre recursos.
Tablas útiles: requests, dependencies, exceptions, traces, availabilityResults para Application Insights; AzureDiagnostics y AzureActivity para registros de plataforma; Perf y Heartbeat para VM insights.
Buenas prácticas: proyecte solo las columnas necesarias, filtre al principio, agrupe (bin) en intervalos razonables y evite uniones cruzadas (cross-joins) costosas en ventanas de tiempo grandes a menos que sea necesario.

El sistema de alertas abarca métricas y registros. Las alertas de métricas evalúan umbrales de métricas casi en tiempo real, admiten dimensiones y la división por dimensión, y pueden usar umbrales estáticos o dinámicos (líneas base basadas en ML). Tienen estado (stateful) y pueden activarse y resolverse automáticamente según los resultados de la evaluación, produciendo una única notificación cuando el estado cambia. Las alertas de registro (consulta programada) ejecutan KQL con una cadencia determinada y se activan según los resultados de la consulta (número de coincidencias o umbrales de medida). Use alertas de registro cuando las condiciones dependan de patrones complejos entre tablas o requieran análisis de texto. La detección inteligente (Smart detection) y las alertas de anomalías en Application Insights pueden resaltar regresiones sin umbrales explícitos.

Los grupos de acciones (Action groups) definen conjuntos de respuestas reutilizables para las alertas. Los tipos de notificación incluyen correo electrónico, SMS, voz y notificaciones push a la aplicación móvil de Azure. Las integraciones incluyen:

Webhooks (v1 y v2) con el Esquema de Alerta Común (Common Alert Schema) para cargas útiles (payloads) consistentes; configure encabezados personalizados para la autenticación y enrute a sistemas de incidentes (p. ej., PagerDuty o receptores personalizados).
Azure Functions, Logic Apps y runbooks de Automation para remediación y enriquecimiento programáticos; use Logic Apps para transformaciones flexibles y conectores.
Conectores ITSM (p. ej., ServiceNow) para abrir incidentes con campos mapeados. Combine los grupos de acciones con reglas de procesamiento de alertas para suprimirlas durante el mantenimiento, enrutarlas por gravedad o aplicar acciones dinámicas. Para webhooks salientes seguros, restrinja el receptor a las IP de Azure o requiera firmas/encabezados y valide las propiedades del Common Alert Schema como Essentials.AlertRule y AlertContext.

Plantillas ARM para monitorización e implementación repetible

Las plantillas de Azure Resource Manager (ARM) definen de forma declarativa los recursos y la configuración de monitorización como código. La estructura de una plantilla incluye:

$schema y contentVersion para identificar la versión de la plantilla.
parameters para valores externalizados (p. ej., nombres de áreas de trabajo, ubicaciones, SKU). Use secureString/secureObject para los secretos.
variables para valores calculados para evitar la repetición.
resources para la implementación declarativa de Application Insights, áreas de trabajo de Log Analytics, reglas de alerta, grupos de acciones y configuraciones de diagnóstico.
outputs para emitir valores como el connectionString de Application Insights para etapas de implementación posteriores.

Use plantillas vinculadas o anidadas para componer implementaciones complejas. Un recurso de implementación (Microsoft.Resources/deployments) hace referencia a una plantilla secundaria a través de templateLink (URI externo) o la incrusta en línea. Pase objetos de parámetros a través de parameters o parametersLink, defina dependsOn para el ordenamiento y reutilice módulos entre entornos. Ejemplos de monitorización por defecto a través de ARM:

Implementar un área de trabajo de Log Analytics y establecer los outputs de workspaceResourceId utilizados por los recursos de Application Insights (modo basado en área de trabajo).
Crear Application Insights (basado en área de trabajo) y emitir su connectionString; evitar exponer las claves de instrumentación heredadas.
Habilitar la configuración de diagnóstico (Diagnostic settings) en los recursos (p. ej., App Service, Key Vault, Storage) para transmitir registros y métricas al área de trabajo y/o a Event Hub.
Aprovisionar alertas de métricas (microsoft.insights/metricAlerts) con criterios y dimensiones, y alertas de consulta programada (microsoft.insights/scheduledQueryRules) con KQL, vinculando grupos de acciones por su ID de recurso.
Definir grupos de acciones (microsoft.insights/actionGroups) con receptores de correo electrónico/SMS y webhook; parametrizar direcciones y puntos de conexión para un enrutamiento específico del entorno.

Adopte condiciones y bucles de copia (copy loops) para implementaciones escalables (p. ej., aplicar la configuración de diagnóstico a un conjunto de ID de recursos). Use funciones de ARM como resourceId, subscriptionResourceId, reference, concat y guid para construir referencias dinámicas y nombres estables. Mantenga la configuración de telemetría consistente entre servicios centralizando las convenciones de nombres de rol y el muestreo en la configuración de la aplicación entregada a través de ARM o los recursos de configuración de App Service.

Escenario de un problema práctico

Adobe necesita observabilidad de extremo a extremo para una nueva canalización de procesamiento de medios multirregional construida sobre API de Azure App Service y microservicios de AKS. Requieren una detección rápida de regresiones de latencia, seguimiento distribuido entre servicios, comprobaciones proactivas de disponibilidad para los puntos de conexión públicos y enrutamiento automatizado de incidentes a su sistema de guardias (on-call) con repetibilidad mediante infraestructura como código.

Instrumentar servicios con Application Insights usando cadenas de conexión

Configurar cada carga de trabajo de App Service y AKS para usar la cadena de conexión de Application Insights en lugar de las claves heredadas, asegurando los puntos de conexión de ingesta correctos y un enrutamiento preparado para el futuro. Establecer los nombres de rol en la nube (cloud role names) por servicio para permitir un filtrado y mapas claros. Elegir la instrumentación basada en SDK en las API principales para emitir eventos y métricas de dominio; habilitar la vinculación sin código (codeless attach) para los servicios auxiliares para acelerar la cobertura. Por qué: Las cadenas de conexión permiten flexibilidad en los puntos de conexión; los SDK proporcionan telemetría personalizada mientras que la vinculación sin código mantiene bajo el coste de adopción.

Habilitar el seguimiento distribuido y el seguimiento de dependencias

Asegurarse de que los clientes HTTP de salida y los SDK de Azure propagan el contexto de seguimiento de W3C; verificar la continuidad de operation_Id en KQL. Para los flujos de mensajes en segundo plano (Service Bus), confirmar que la correlación es inyectada y extraída por los SDK; complementar con TelemetryInitializers donde se utilizan encabezados personalizados. Por qué: La propagación consistente del seguimiento produce una latencia de extremo a extremo y una atribución de fallos precisas entre microservicios.

Implementar pruebas de disponibilidad y comprobaciones sintéticas personalizadas

Configurar pruebas de ping de URL para las API públicas desde múltiples geografías con una coincidencia de contenido en un punto de conexión de estado ligero. Para flujos autenticados (adquisición de tokens y envío de medios), implementar un cliente sintético que llame al flujo de trabajo y emita resultados de TrackAvailability con la ubicación de ejecución y mensajes detallados. Por qué: Los pings de URL proporcionan una verificación externa rápida; TrackAvailability admite flujos de negocio complejos y autenticados más allá de los pings básicos.

Centralizar datos en un área de trabajo de Log Analytics y enrutar los registros de la plataforma

Implementar un área de trabajo y configurar la configuración de diagnóstico (Diagnostic settings) en App Services, los registros del plano de control de AKS, Key Vault y Storage para transmitir registros y métricas al área de trabajo. Asegurarse de que los recursos de Application Insights estén basados en el área de trabajo para unificar las consultas. Por qué: Un área de trabajo única permite KQL entre servicios, uniendo solicitudes, dependencias y registros de la plataforma para una investigación holística.

Crear alertas de métricas y de registros con grupos de acciones

Definir alertas de métricas sobre los percentiles de duración de las solicitudes y la disponibilidad por ubicación con umbrales dinámicos, dividiendo por el nombre del rol en la nube (cloud role name). Añadir alertas de consulta programada que detectan picos de errores por nombre de operación y los correlacionan con fallos de dependencias usando un join de KQL en operation_Id. Por qué: Las alertas de métricas proporcionan una detección casi en tiempo real; las alertas de registro capturan patrones complejos que no se pueden expresar como umbrales simples.

Integrar la respuesta a incidentes mediante grupos de acciones y webhooks

Configurar un grupo de acciones con correo electrónico para los propietarios del servicio, SMS para los líderes de guardia (on-call) y un webhook seguro a la plataforma de incidentes de Adobe usando el Esquema de Alerta Común (Common Alert Schema). Añadir un receptor de Logic App para enriquecer las cargas útiles (payloads) con resultados de consultas KQL recientes y metadatos de topología. Por qué: Las notificaciones multicanal reducen el MTTA; el webhook y Logic App permiten la creación automatizada de tiques e incidentes ricos en contexto.

Codificar la monitorización con plantillas ARM

Crear plantillas ARM para implementar el área de trabajo de Log Analytics, Application Insights (basado en área de trabajo), la configuración de diagnóstico, las alertas de métricas, las alertas de consulta programada y los grupos de acciones. Parametrizar los nombres de los entornos, las regiones y los puntos de contacto; emitir el connectionString de Application Insights para la configuración de la aplicación posterior. Usar plantillas vinculadas para módulos propiedad del equipo (plataforma vs. aplicación). Por qué: La infraestructura como código garantiza una observabilidad consistente y repetible en los entornos de desarrollo, preproducción y producción, y es compatible con CI/CD.

Validar con paneles de control de KQL

Construir paneles de control usando KQL que resumen la latencia por servicio (resumir los percentiles por intervalo (bin) y rol), las tasas de error unidas (joined) a los destinos de las dependencias y la disponibilidad sintética por ubicación. Incorporar filtros de rango de tiempo y desglose detallado (drill-through) a seguimientos y excepciones. Por qué: KQL proporciona un análisis flexible y visualizaciones accionables para los equipos de ingeniería y operaciones.

← Almacenamiento en caché · Todos los dominios

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →