El examen AZ-400 no pregunta simplemente si un servicio está activo — evalúa si sabes cómo descubrir por qué se comporta de cierta manera. El foco está en el diseño de observabilidad con tres pilares: métricas, registros y trazas. Este artículo explica cómo Azure Monitor, Application Insights y Log Analytics desempeñan roles distintos, cómo KQL une los datos, y cómo SLO, Error Budget y las métricas DORA completan el panorama.
Monitoreo vs. Observabilidad
Imagina la pantalla de monitoreo en la sala de urgencias de un hospital. Cuando la presión arterial de un paciente sale del rango normal, suena una alarma. Eso es monitoreo — el sistema detecta que algo está fuera de lo esperado. Ahora imagina al médico preguntando: "¿Cómo llegó este paciente a este estado?" Responder esa pregunta exige cruzar 72 horas de registros de medicación, tendencias de análisis de sangre y trazados de ECG. Eso es observabilidad — la capacidad de razonar sobre causas, no solo detectar efectos.
Los sistemas de software funcionan igual. El monitoreo detecta modos de fallo conocidos. La observabilidad permite razonar sobre fallos desconocidos a partir del estado interno del sistema. La base son tres tipos de señales.
: Resúmenes numéricos a lo largo del tiempo — uso de CPU, conteo de solicitudes, latencia. Rápidas de consultar, ideales para alertas sobre el estado actual. : Registros de lo que ocurrió en un momento específico. Sin estructura fija, pero con gran riqueza de contexto. : El recorrido de una única solicitud al pasar por múltiples servicios. Responde "¿por qué esta solicitud tardó 3 segundos?"
En Azure, la plataforma que unifica las tres señales es Azure Monitor. Cada señal complementa a las demás: las métricas alertan sobre el síntoma, los registros describen el evento, las trazas muestran la cadena de causas.
!Monitoreo vs observabilidad
Arquitectura de Azure Monitor
Piensa en el tablero de instrumentos de un automóvil moderno. Velocímetro, indicador de combustible y luces de advertencia aparecen en un solo lugar — el conductor no necesita abrir aplicaciones separadas de cada fabricante de componentes. Azure Monitor cumple exactamente ese rol para los recursos de Azure: agrega señales de toda la plataforma en un único punto de acceso.
Metrics y Logs
Azure Monitor Metrics almacena datos de series temporales durante 93 días. Las métricas de plataforma como CPU de VM, transacciones de Storage Account y solicitudes HTTP de App Service se recopilan automáticamente sin ninguna configuración adicional. Las métricas personalizadas pueden emitirse desde el código de la aplicación. Puedes visualizarlas en Metrics Explorer o conectarlas directamente como fuentes de señal para las reglas de Alert.
Azure Monitor Logs almacena datos en un espacio de trabajo de Log Analytics. Al habilitar Diagnostic Settings en los recursos de Azure, los registros se envían al espacio de trabajo, donde KQL (Kusto Query Language) permite analizarlos libremente.
KQL se parece a SQL pero usa una estructura de tubería que hace que las transformaciones escalonadas sean fáciles de leer y componer. La consulta anterior agrega el conteo de solicitudes y el tiempo de respuesta promedio en intervalos de 5 minutos durante la última hora.
Workbooks
Azure Workbooks combina consultas KQL, gráficos de métricas y texto explicativo en una sola página interactiva. Admiten parámetros dinámicos y presentan datos de múltiples recursos en una misma vista. Son especialmente útiles para informes de SLA compartidos con el equipo y para documentar revisiones post-incidente con datos reales integrados.
Application Insights — Rastreo Distribuido
Imagina el sistema de seguimiento de equipaje de un aeropuerto. Cada maleta recibe un código de barras en el check-in, y cada escaneo — mostrador de facturación, cinta transportadora, bodega del avión — queda registrado. Si una maleta se pierde, encuentras inmediatamente el último punto de control. El rastreo distribuido de Application Insights funciona exactamente igual para las solicitudes HTTP en entornos de microservicios.
Mapas de Dependencias y Muestreo
En una arquitectura de microservicios, una solicitud HTTP puede recorrer API Gateway → Order Service → Inventory Service → Base de Datos. Application Insights asigna el mismo a cada salto, vinculando todo el recorrido en una sola traza. El Application Map muestra esto como un grafo visual con tasas de fallo y tiempos de respuesta para cada llamada entre servicios, facilitando la identificación del origen de la latencia.
Registrar cada solicitud en un servicio de alto tráfico puede disparar los costos rápidamente. Adaptive Sampling limita automáticamente la recopilación a aproximadamente 5 operaciones por segundo. Cuando necesitas diagnóstico en tiempo real inmediatamente después de un incidente, Live Metrics Stream te permite observar el estado actual con latencia prácticamente nula, sin esperar a que los datos se procesen en el pipeline de ingestión normal.
Incluso sin alertas configuradas manualmente, Smart Detection aprende una línea base de rendimiento y detecta automáticamente anomalías como aumentos repentinos en el tiempo de respuesta, picos en la tasa de fallos o degradación de dependencias. No requiere configuración de umbrales — el sistema aprende qué es normal y alerta cuando el comportamiento se desvía de esa línea base.
Reglas de Alerta y Action Groups
Piensa en un sistema automático de notificación de incendios en un edificio. El detector de humo dispara una señal, el panel de control la enruta a la estación de bomberos, y los camiones salen automáticamente. No hay ningún humano en el ciclo entre la detección y el despacho de la respuesta. Las reglas de Alert de Azure Monitor combinadas con Action Groups construyen exactamente esta estructura para tu infraestructura.
Una regla de Alert tiene tres partes. selecciona qué monitorear: valores de Metrics, resultados de consultas de Log Analytics o eventos del Activity Log. define cuándo disparar: umbral superado, conteo de filas en resultado de consulta o cambio de estado. define qué ocurre cuando se activa: correo electrónico, SMS, llamada de voz, invocación de Azure Function, disparador de Logic App o integración con ITSM.
El tráfego es alto durante el horario laboral y bajo durante la noche. Los umbrales fijos producen alertas de falsos positivos por la noche o pasan por alto anomalías durante las horas pico. Dynamic Thresholds aprende los patrones históricos y ajusta el rango normal por hora del día de forma automática, reduciendo la fatiga de alertas sin perder sensibilidad ante los verdaderos incidentes.
SLO, SLI, Error Budget y Métricas DORA
Si un equipo declara "nuestro servicio garantiza 99,9% de disponibilidad", ¿cómo verifican que se está cumpliendo esa promesa? Al igual que un equipo de ventas hace seguimiento semanal de sus ingresos frente a un objetivo trimestral, los equipos de ingeniería necesitan rastrear la fiabilidad del servicio de forma cuantitativa y continua.
Un SLI (Service Level Indicator) es la medición — por ejemplo, "porcentaje de respuestas exitosas en los últimos 30 días." Un SLO (Service Level Objective) es el objetivo para esa medición: "la tasa de éxito debe mantenerse en 99,9% o más." Los SLIs se calculan directamente en Log Analytics con KQL. Un SLO de 99,9% permite aproximadamente 43 minutos de inactividad por mes — ese margen es el Error Budget. Cuando el presupuesto se agota, la práctica SRE indica pausar los lanzamientos de nuevas características y redirigir el esfuerzo del equipo hacia mejoras de fiabilidad hasta que el presupuesto se recupere.
Las métricas DORA (DevOps Research and Assessment) miden la salud del proceso de entrega. Al conectar Log Analytics con datos de pipelines de Azure DevOps, los equipos rastrean cuatro indicadores clave: Deployment Frequency (con qué frecuencia se despliega), Lead Time for Changes (tiempo desde commit hasta producción), Change Failure Rate (porcentaje de despliegues que causan incidentes) y MTTR (Mean Time to Restore, tiempo promedio para recuperarse de un incidente).
Resumen para el Examen
Las preguntas de monitoreo del AZ-400 se centran en qué herramienta resuelve qué problema, no solo en los nombres de las herramientas.
"Rastrear una solicitud a través de múltiples servicios" -- Application Insights rastreo distribuido + Application Map "Almacenar y visualizar series temporales de métricas de plataforma" -- Azure Monitor Metrics + Metrics Explorer "Consultar registros para encontrar patrones de error" -- Log Analytics + KQL "Detectar anomalías automáticamente sin configurar umbrales" -- Application Insights Smart Detection "Invocar una Azure Function cuando se dispara una alerta" -- Action Groups (destino Azure Function) "Tener en cuenta diferencias de tráfico día/noche en alertas" -- Dynamic Thresholds "Calcular SLI y rastrear Error Budget" -- Consultas KQL en Log Analytics "Métrica DORA para tiempo de recuperación" -- MTTR (integración Azure DevOps + Log Analytics) "Visualizar latencia entre servicios dependientes" -- Application Insights Application Map "Informes de monitoreo interactivos compartibles para el equipo" -- Azure Monitor Workbooks
Azure Monitor = hub para todas las métricas y registros de la plataforma, Application Insights = rastreo distribuido y Smart Detection en la capa de aplicación, Log Analytics + KQL = motor de consultas que une todos los datos.