Contoso Airlines tiene hoy una plataforma repartida en aplicaciones web, una API en un conjunto de escalado, contenedores, funciones efímeras, colas, temas, bases de datos y servicios de IA. Cuando algo va mal, la pregunta ya no es «¿está caído el servidor?», sino «¿qué parte de esta cadena está fallando, desde cuándo, para cuántos pasajeros y por qué». Responder a eso requiere que el sistema emita información y que alguien la haya recogido antes de que pasara el problema. Esa es la disciplina que abre este módulo.

Esta lección es el mapa. Vas a entender qué es la observabilidad y sus tres señales, cómo Azure Monitor las agrupa todas bajo un mismo paraguas, cómo se configuran las métricas de plataforma y la pieza que casi todo el mundo olvida —la configuración de diagnóstico—, y cómo se construye un sistema de alertas que despierta a alguien solo cuando merece la pena. Todo sobre los recursos reales de Contoso.

1. Observabilidad: tres señales, no una alerta de CPU
2. Azure Monitor como paraguas
3. Métricas de plataforma y el explorador de métricas
4. Configuración de diagnóstico: la pieza olvidada
5. Registro de actividad, registros de recurso y registros del sistema operativo
6. Alertas: tipos, condiciones y umbrales
7. Grupos de acciones y reglas de procesamiento
8. El conjunto de alertas de Contoso
9. SLI, SLO y presupuesto de error
10. Paneles y libros
11. Coste de la monitorización
12. Errores Comunes y Consejos
13. Ejercicios
14. Conclusión

Monitorizar es comprobar que unos indicadores conocidos siguen dentro de rango. Observabilidad es la propiedad de un sistema que permite responder a preguntas que nadie había previsto, sin desplegar código nuevo. La diferencia importa: una alerta de CPU al 90 % es monitorización, y no habría dicho absolutamente nada sobre el pasajero que pagó y no recibió su tarjeta de embarque.

Las tres señales clásicas:

La regla práctica: las métricas detectan, los registros explican, las trazas localizan. Un sistema que solo tiene métricas sabe que algo va mal y no sabe qué. Uno que solo tiene registros paga una fortuna y busca a ciegas. Contoso necesita las tres, y cada una tiene su lección en este módulo.

Azure Monitor no es un producto: es el nombre del conjunto. Conviene ver el mapa completo desde el principio para saber dónde encaja cada lección.

Tres ideas del diagrama: hay dos plataformas de datos —métricas y registros— con precios, retenciones y lenguajes de consulta distintos; los datos no llegan solos a los registros, hace falta una configuración de diagnóstico o un agente, y ese es el olvido más frecuente; e Insights (Application, Container, VM) no son almacenes separados, sino experiencias visuales montadas sobre esos mismos datos.

Las métricas de plataforma las emite Azure automáticamente, sin configurar nada y sin coste, para casi todos los recursos. Sus propiedades:

• Granularidad de un minuto en la mayoría de recursos, agregadas después a intervalos mayores.
• Retención de 93 días. Pasado ese plazo desaparecen, salvo que las exportes a Log Analytics.
• Dimensiones: atributos que permiten desglosar una métrica. Http5xx de una App Service se puede desglosar por instancia; las peticiones de Storage, por tipo de API o por código de respuesta.
• Agregaciones: promedio, mínimo, máximo, total y recuento. Elegir mal la agregación es el error clásico —el promedio de latencia de una hora oculta el pico que enfadó a los pasajeros.

Consulta desde CLI el tiempo de respuesta de la web de reservas:

• --metric acepta varias métricas a la vez; sus nombres son los internos, no los del portal. Para descubrirlos: az monitor metrics list-definitions --resource "$APP_ID".
• --interval PT5M es notación ISO 8601 de duración: 5 minutos. PT1H sería una hora.
• --aggregation pide las tres agregaciones para poder comparar promedio y máximo en la misma tabla.

En el portal, el explorador de métricas hace lo mismo de forma visual: eliges recurso, métrica, agregación, y añades una división por dimensión. El flujo típico de Marta Ríos ante una queja de lentitud es: HttpResponseTime en promedio y en percentil, dividido por instancia. Si una sola instancia está lenta, es un problema de esa instancia; si lo están todas, el problema está detrás —normalmente en sql-contoso-reservas-pro.

Las métricas de plataforma existen solas. Los registros de recurso, no. Un App Service no envía a ningún sitio sus registros HTTP, ni SQL Database sus consultas lentas, ni Key Vault quién accedió a qué, hasta que creas una configuración de diagnóstico que diga qué categorías se exportan y adónde. Es habitual descubrirlo el día del incidente, cuando ya es tarde: los registros no existen retroactivamente.

Cada tipo de recurso publica sus propias categorías. Ejemplos reales:

Y tres destinos posibles, combinables:

Crear la configuración de diagnóstico de la web de reservas:

Dos parámetros merecen atención. --export-to-resource-specific true hace que los datos aterricen en tablas dedicadas (AppServiceHTTPLogs) en lugar de en la tabla genérica AzureDiagnostics; es mejor esquema, mejor rendimiento y permite planes de tabla distintos, y lo aprovecharás en 07-02. --metrics AllMetrics duplica las métricas de plataforma en los registros: útil para correlacionar y conservarlas más allá de 93 días, pero es ingesta que se paga, así que actívalo solo donde lo necesites.

Hacer esto recurso a recurso no escala. Por eso Contoso ya tiene, dentro de la iniciativa «Base de gobernanza de Contoso» del módulo 4, la asignación diagnostico-app-service con efecto DeployIfNotExists: cualquier App Service nuevo recibe automáticamente su configuración apuntando a log-contoso-pro. El cumplimiento se comprueba con az policy state summarize --resource-group rg-contoso-reservas-pro. La política es lo que convierte «acuérdate de activar los diagnósticos» en una garantía. Recuerda que DeployIfNotExists solo actúa sobre recursos nuevos o al ejecutar una tarea de corrección sobre los existentes.

Tres capas que se confunden constantemente:

El registro de actividad responde siempre a la pregunta «¿qué cambió justo antes de que se rompiera?», que resuelve una parte notable de los incidentes:

Para las máquinas virtuales, el agente de Azure Monitor sustituye a los agentes antiguos y no decide por su cuenta qué recoger: lo determina una regla de recopilación de datos (DCR), un recurso independiente y reutilizable que dice qué orígenes se leen, cómo se transforman y a qué área van. Esa separación permite cambiar la recopilación de cien máquinas editando un único objeto: se crea la DCR dcr-contoso-servidores una vez y se asocia a cada máquina con az monitor data-collection rule association create.

Un detalle de coste con consecuencias: una DCR mal filtrada que recoja todo el syslog de un servidor locuaz puede costar más que la propia máquina virtual. Las DCR admiten transformaciones KQL en el momento de la ingesta para descartar lo irrelevante antes de pagarlo; volveremos sobre ello en 07-02.

Una alerta es una regla que evalúa un origen de datos y, si se cumple la condición, dispara un grupo de acciones. Los tipos disponibles:

Las de estado del servicio y estado del recurso son gratuitas y casi nadie las configura, siendo las que distinguen «hemos roto algo» de «Azure tiene un problema en la región». Configúralas siempre.

Sobre los umbrales:

• Estático: tú fijas el número. Predecible y auditable. Adecuado cuando existe un compromiso —el SLO dice 800 ms, alertas a 800 ms.
• Dinámico: Azure aprende el patrón histórico, incluida la estacionalidad diaria y semanal, y alerta ante desviaciones. Ideal para métricas con ciclo natural: el tráfico de app-contoso-reservas-pro cae de madrugada, y un umbral estático de «menos de 100 peticiones por minuto» dispararía cada noche.

Dos parámetros gobiernan el ruido: la frecuencia de evaluación (cada cuánto se comprueba) y la ventana de agregación (cuánto tiempo se agrega en cada comprobación). Evaluar cada minuto sobre una ventana de un minuto dispara ante cualquier pico transitorio. Contoso usa evaluación cada 5 minutos con ventana de 15 para latencia, y cada minuto con ventana de 5 para disponibilidad.

Un grupo de acciones es la lista de a quién se avisa y qué se ejecuta. Se define una vez y se reutiliza en todas las reglas.

• --short-name (máximo 12 caracteres) es lo que aparece como remitente en el SMS.
• useCommonAlertSchema fuerza el esquema común de alertas, un JSON con la misma forma para todos los tipos. Sin él, cada tipo de alerta manda una carga distinta y el consumidor se vuelve inmantenible. Actívalo siempre.

Los tipos de acción disponibles: correo, SMS, notificación push, llamada de voz, correo a un rol de Azure Resource Manager, webhook, webhook seguro con Entra ID, Logic App, Azure Function, runbook de Automation y conector ITSM. Contoso usa tres grupos:

Las reglas de procesamiento de alertas actúan sobre las alertas ya generadas, sin tocar las reglas. Sirven para dos cosas: silenciar durante una ventana de mantenimiento y añadir un grupo de acciones a un conjunto de alertas de golpe.

Sin esto, la noche del despliegue mensual el equipo recibe cuarenta SMS, y a la tercera vez alguien silencia el teléfono de guardia de forma permanente. El ruido no es una molestia: es la forma en que un sistema de alertas se muere.

Esta es la tabla real que Marta mantiene, y su valor está tanto en lo que contiene como en lo que deliberadamente no contiene:

Fíjate en lo que no hay: ninguna alerta de CPU, ninguna de memoria, ninguna de disco de aplicación. No porque no importen, sino porque son causas, no síntomas. Una CPU al 95 % con la latencia dentro del objetivo y sin errores no es un problema: es una máquina bien aprovechada. Alertar sobre causas produce despertares inútiles y, peor, entrena al equipo a ignorar el teléfono. Se alerta sobre lo que el pasajero nota; las causas se investigan después, con métricas y registros, que para eso están.

Una regla de métrica por CLI, para fijar el patrón (las etiquetas obligatorias también aquí: una regla de alerta es un recurso facturable y debe atribuirse a CC-1042):

Sin estos tres conceptos, los umbrales se eligen por intuición y se discuten para siempre.

• SLI (indicador de nivel de servicio): la medida concreta. «Porcentaje de peticiones a /api/disponibilidad respondidas correctamente en menos de 800 ms.»
• SLO (objetivo de nivel de servicio): el valor comprometido. «99,5 % mensual.»
• Presupuesto de error: lo que el SLO te permite fallar. Un 99,5 % mensual son 3 horas y 39 minutos de incumplimiento.

El presupuesto de error convierte una discusión de opiniones en una de aritmética: si en la primera semana se ha consumido el 70 %, se congelan los cambios arriesgados y el esfuerzo va a fiabilidad; si a fin de mes sobra, se despliega con más alegría. Y responde a la pregunta incómoda que Nuria Peña hará en el módulo 8: pasar del 99,5 % al 99,99 % no cuesta un poco más, cuesta multiplicar la infraestructura.

Dos herramientas que se parecen y no son lo mismo:

El panel de operaciones de Contoso vive en una pantalla del centro de control y muestra seis elementos: disponibilidad del punto de salud, peticiones por minuto y latencia p95 de la API, errores 5xx de la web, profundidad de cola-emision-tarjetas, DTU de db-reservas y alertas activas por gravedad. Nada más: un panel con treinta gráficas no lo mira nadie. El libro parametrizado «Salud de reservas» es en cambio la herramienta de investigación, con tres parámetros —intervalo, entorno y localizador— que rellenan las consultas KQL de la lección siguiente; la misma plantilla sirve para producción y desarrollo cambiando un desplegable, y se versiona en el repositorio contoso-infra junto a las plantillas Bicep. Las pruebas de disponibilidad que alimentan la primera alerta de la tabla pertenecen a Application Insights y se explican en 07-03.

Un aviso que conviene interiorizar ya, aunque el detalle llegue en 07-02: la ingesta y la retención de datos en Log Analytics es una de las facturas de Azure que más sorprende. Nada te avisa de que has dejado activados los registros de depuración en producción; simplemente, a fin de mes la línea de Log Analytics es la mayor de la suscripción. Contoso lo vivió: activar AppServiceConsoleLogs en las cuatro aplicaciones durante una investigación y olvidarse de desactivarlo costó más que el plan de App Service que lo generaba.

Dos consecuencias prácticas: una alerta de registros evaluada cada minuto en cincuenta recursos es una factura considerable, así que ajusta la frecuencia a lo que realmente necesitas detectar; y las alertas con destino SMS conviene reservarlas para gravedades 0 y 1, que es justo lo que hace ag-guardia-contoso.

• Creer que los registros existen sin configuración de diagnóstico. El día del incidente descubres que no hay nada, y los registros no aparecen retroactivamente. Actívalos con política, no a mano.
• Alertar sobre causas. CPU, memoria y disco generan ruido; alerta sobre síntomas visibles para el pasajero.
• Elegir mal la agregación. El promedio esconde los picos. Para latencia, percentiles; para errores, totales.
• No configurar las alertas gratuitas. Estado del servicio y estado del recurso no cuestan nada y evitan investigar durante una hora un problema que es de Azure.
• Ventanas de evaluación demasiado cortas o mantenimiento sin silenciar. Ambas producen ruido previsible, y el ruido mata la credibilidad del sistema: usa reglas de procesamiento de alertas.
• Consejo: define el SLO antes que el umbral. Si no sabes qué has prometido, cualquier número es discutible.
• Consejo: toda alerta debe llevar en su descripción un enlace al procedimiento de actuación; una alerta a las 3 de la mañana sin instrucciones es una alerta a medias. Y revisa trimestralmente cuáles se dispararon y qué se hizo con ellas: las que nunca llevaron a una acción, se borran.

Ejercicio 1. Contoso quiere vigilar la nueva API pública de «Contoso Millas» (centro-coste=CC-2077), desplegada en un App Service de rg-contoso-reservas-dev. Define: qué señales activarías, con qué configuración de diagnóstico, tres alertas con su gravedad y grupo de acciones, y una decisión de coste justificada.

Ejercicio 2. Durante dos semanas el equipo ha recibido 340 alertas y ha actuado sobre 6. Analiza qué está pasando, propón cuatro medidas concretas y explica el riesgo de no hacer nada.

Ejercicio 3. El negocio pide para db-reservas un SLO de disponibilidad del 99,99 %. Calcula el presupuesto de error mensual, indica qué implica técnicamente y qué contrapropuesta harías.

Solución 1:

• Señales y diagnóstico: métricas de plataforma (gratuitas, ya existen); registros de recurso vía configuración de diagnóstico con AppServiceHTTPLogs y AppServiceAppLogs —no AppServiceConsoleLogs, que es el que dispara la factura— hacia log-contoso-pro con --export-to-resource-specific true y retención corta por ser un ensayo; y trazas con Application Insights (07-03). Si la asignación diagnostico-app-service alcanza a rg-contoso-reservas-dev, la configuración se despliega sola: conviene verificarlo.
• Alertas: (1) estado del recurso, gravedad 1, ag-guardia-contoso, gratuita; (2) Http5xx > 25 en 5 min, gravedad 2, ag-equipo-contoso, porque un proyecto secundario no justifica despertar a nadie; (3) HttpResponseTime con umbral dinámico, gravedad 3, ag-registro-contoso, porque aún no hay línea base conocida.
• Coste: notificaciones por correo, sin SMS, y evaluación cada 15 minutos en lugar de cada minuto. Etiquetas entorno=desarrollo, proyecto=contoso-millas, centro-coste=CC-2077, propietario.

Solución 2: la ratio es de 1 acción por cada 57 avisos: el sistema ha dejado de ser informativo y el equipo ya ha aprendido a ignorarlo. Causas habituales: alertas sobre causas (CPU, memoria), ventanas de evaluación de un minuto que capturan picos transitorios, ausencia de silenciado durante despliegues y mantenimiento, y una misma incidencia que dispara diez reglas a la vez. Medidas: (1) eliminar toda alerta que no haya provocado una acción en tres meses; (2) ampliar ventanas de agregación a 15 minutos en métricas ruidosas y pasar a umbrales dinámicos donde hay estacionalidad; (3) crear reglas de procesamiento de alertas para las ventanas de despliegue y mantenimiento; (4) reasignar gravedades para que solo 0 y 1 usen SMS, dejando el resto en correo o incidencia. El riesgo de no actuar es concreto: la próxima caída real llegará como el aviso número 341 y nadie lo mirará.

Solución 3: el 99,99 % mensual deja 4 minutos y 23 segundos de presupuesto de error al mes —menos de lo que tarda una conmutación por error manual—. Técnicamente implica conmutación automática con fg-contoso-reservas, un nivel de servicio con el SLA correspondiente, redundancia de zona, reintentos con lógica de reconexión en la aplicación y despliegues sin tiempo de inactividad, además de que el SLA de Azure para un único servidor lógico ya no basta. Contrapropuesta razonable: 99,95 % para la base de datos (21 minutos y 54 segundos de presupuesto) combinado con un SLO de experiencia —«el pasajero puede consultar su reserva»— apoyado en una caché de solo lectura durante la conmutación. Cuesta una fracción y protege lo que el negocio realmente valora. Y, además, el compromiso debe medirse sobre un SLI acordado, no sobre la disponibilidad declarada por el proveedor.

Ya tienes el mapa completo. Sabes que la observabilidad se apoya en tres señales —métricas para detectar, registros para explicar, trazas para localizar— y que Azure Monitor es el paraguas que agrupa las dos plataformas de datos, las experiencias de Insights y el consumo mediante alertas, libros y paneles. Conoces las métricas de plataforma, gratuitas, con granularidad de un minuto y 93 días de retención, sus dimensiones y agregaciones, y cómo explorarlas sobre app-contoso-reservas-pro. Y, sobre todo, dominas la pieza que casi todo el mundo olvida: la configuración de diagnóstico, sus categorías por tipo de recurso, sus tres destinos y su despliegue a escala mediante la asignación diagnostico-app-service con DeployIfNotExists.

Distingues el registro de actividad —quién cambió qué— de los registros de recurso y de los del sistema operativo, recogidos por el agente de Azure Monitor con sus reglas de recopilación de datos. Has visto los cinco tipos de alerta, incluidas las gratuitas que casi nadie activa, los umbrales estáticos frente a los dinámicos y el papel de la frecuencia de evaluación; has creado ag-guardia-contoso con el esquema común de alertas y sabes silenciar el mantenimiento con reglas de procesamiento. El conjunto de alertas de Contoso te ha enseñado la regla que sostiene todo lo demás —alertar sobre síntomas, nunca sobre causas—, con SLI, SLO y presupuesto de error como criterio para elegir umbrales en lugar de discutirlos, y con paneles y libros parametrizados como superficie de consulta. Y llevas la advertencia de coste: métricas y alertas de plataforma son casi gratis, los SMS se pagan y la ingesta de registros es la partida que sorprende.

Precisamente ahí va la lección siguiente. Todo lo que has enviado con las configuraciones de diagnóstico ha aterrizado en log-contoso-pro, y hasta ahora solo lo has almacenado. En 07-02, Log Analytics y consultas KQL, aprenderás a interrogarlo: las tablas que te vas a encontrar, el lenguaje KQL desde cero y explicado línea a línea, el recorrido completo para investigar la queja del pasajero que pagó y no recibió su tarjeta de embarque, y las tres palancas —qué se ingiere, en qué plan y cuánto tiempo se guarda— con las que se controla esa factura que acabamos de anunciar.