Microsoft AZ-400: Monitorización, observabilidad y retroalimentación — Guía de estudio

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Forma parte de la Microsoft DevOps Engineer Expert AZ-400 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Información general

Los equipos de DevOps modernos tratan el monitoreo, la observabilidad y la retroalimentación como un ciclo continuo que informa las decisiones de ingeniería, operaciones y producto. En Azure, la telemetría fluye desde las aplicaciones y la infraestructura hacia Azure Monitor y Log Analytics, donde se consulta, correlaciona y visualiza. El seguimiento distribuido une los servicios en transacciones de extremo a extremo, mientras que las alertas y las integraciones de guardia impulsan una remediación rápida. Los paneles de Azure DevOps, el análisis de elementos de trabajo y la experimentación cierran el ciclo al reincorporar los conocimientos en la planificación y la entrega. Esta sección proporciona la profundidad necesaria para diseñar una pila de observabilidad integrada que ofrezca retroalimentación procesable en cada etapa.

Telemetría, Seguimiento y Azure Monitor

Application Insights es el componente de supervisión del rendimiento de aplicaciones (APM) de Azure Monitor. La instrumentación se añade a través de:

SDK y auto-instrumentación: .NET/.NET Core, Java, JavaScript, Node.js, Python y el Application Insights Agent para .NET y Java. Use una cadena de conexión y establezca cloud_RoleName para distinguir los componentes.
Inicializadores y procesadores de telemetría: Añada o modifique propiedades (p. ej., tenantId) y filtre PII antes de la emisión.
Telemetría personalizada: TrackEvent para acciones de negocio, TrackMetric para KPI numéricos, TrackException para contextos de error y TrackDependency para llamadas externas que necesite modelar explícitamente.

Los tipos de telemetría incluyen solicitudes, dependencias (HTTP, SQL, SDK de Azure), seguimientos, excepciones, vistas de página, rendimiento de carga de página, resultados de pruebas de disponibilidad, eventos/métricas personalizados y métricas en vivo. El muestreo controla el volumen y el costo mientras preserva la señal: el muestreo adaptativo del SDK ajusta automáticamente las tasas por tipo para mantener el rendimiento y la correlación objetivo; el muestreo de tasa fija proporciona un muestreo determinista para el cumplimiento normativo. Dé preferencia al muestreo del lado del SDK para que los sistemas posteriores nunca procesen elementos descartados. Mantenga un muestreo persistente (sticky sampling) para la integridad del seguimiento de extremo a extremo.

El seguimiento distribuido proporciona visibilidad de las transacciones de extremo a extremo. Application Insights implementa el estándar W3C Trace-Context (traceparent/tracestate), propagando automáticamente los ID de correlación a través de HTTP; propague el contexto a través de los límites asíncronos y protocolos personalizados para evitar seguimientos rotos. El seguimiento de dependencias recopila automáticamente las llamadas salientes comunes; emita dependencias personalizadas para saltos en colas de mensajes o RPC no estándar para completar el gráfico de llamadas. App Map y Transaction Search visualizan los flujos entre servicios, las latencias y los puntos críticos de fallo. Para la correlación del front-end con el back-end, habilite el SDK de JavaScript y asegúrese de que se acepten las cabeceras de correlación del lado del servidor para medir los tiempos de carga de página reales y los recorridos del usuario.

Azure Monitor unifica la telemetría de la plataforma y de la aplicación:

Métricas: Multidimensionales, casi en tiempo real (granularidad de un minuto o mejor). Use alertas de métricas con umbrales estáticos o dinámicos para detecciones rápidas y de baja latencia.
Registros: Telemetría semiestructurada en un área de trabajo de Log Analytics, consultada con KQL para análisis profundo y búsqueda de anomalías.
Alertas: Las reglas de métricas, registros y registro de actividad se enrutan a grupos de acciones. Use umbrales dinámicos, selección de múltiples recursos y el esquema de alerta común para un manejo consistente.
Grupos de acciones: Correo electrónico/SMS/voz, notificaciones push, webhooks (incluyendo PagerDuty/OpsGenie), conectores ITSM, Logic Apps, Azure Functions y runbooks de Automation para la remediación.
Configuración de diagnóstico: Configure cada recurso de Azure para transmitir métricas/registros de la plataforma a Log Analytics, Azure Storage (para archivado) y Event Hubs (para la ingesta en SIEM). Asegure la consistencia con una implementación basada en directivas.

Consultas y Análisis con Log Analytics (KQL)

Un área de trabajo de Log Analytics es el límite de consulta y gobernanza para los registros. Planifique por entorno y soberanía de los datos: áreas de trabajo separadas para producción frente a no producción pueden simplificar el RBAC y las directivas de retención; la centralización facilita la correlación entre servicios. Los orígenes de datos incluyen Azure Diagnostics (registros/métricas de la plataforma), agentes de VM (eventos de Syslog/Windows, contadores de rendimiento), Container Insights/AKS, registros de componentes de Application Insights (unificados bajo Azure Monitor Logs), inicios de sesión de Azure AD, registros personalizados a través de API de ingesta y Reglas de Recopilación de Datos para un enrutamiento y transformación precisos de los flujos.

Kusto Query Language (KQL) está optimizado para el análisis de series temporales y telemetría:

Operadores principales: where (filtrar), project (seleccionar), extend (derivar), summarize by (agregar), join/union (correlacionar), parse/parse_json (extraer), mv-expand (arrays), make-series y bin para la agrupación por tiempo, render para la generación de gráficos.
Patrones: Consumo del presupuesto de errores (tasas de fallo ponderadas en el tiempo), distribuciones de latencia p50/p95, detección de valores atípicos en dependencias, tasa de éxito de solicitudes frente al tráfico y detección de anomalías usando series_decompose_anomalies para alertas que tienen en cuenta la estacionalidad.
Gobernanza: Las consultas y funciones guardadas promueven la reutilización; el RBAC y el acceso a nivel de tabla restringen los conjuntos de datos sensibles.
Entre recursos y entre áreas de trabajo: Use workspace(“workspaceNameOrId”).Table y la función workspaces() para combinar conjuntos de datos entre entornos y suscripciones; use resource() para uniones entre recursos. Aplique enlaces let y materialize() para controlar el rendimiento en uniones grandes.

Visualización y retroalimentación ágil en Azure DevOps

Los paneles (dashboards) en Azure DevOps comunican tanto la salud operativa como la del proceso. Los paneles a nivel de equipo se centran en el backlog, las iteraciones y el WIP del equipo; los paneles a nivel de proyecto muestran vistas de portafolio y entre equipos. Los widgets incluyen el gráfico de evolución (Sprint Burndown), el de finalización (Burnup), la velocidad (Velocity), el diagrama de flujo acumulado (CFD), el tiempo de ciclo (Cycle Time), el tiempo de entrega (Lead Time), gráficos de elementos de trabajo/resultados de consulta, resúmenes de compilación/lanzamiento y Markdown para runbooks y el estado de los SLO. Asegure los widgets con permisos de panel y limite el alcance de las consultas estrictamente a equipos/áreas para evitar la filtración de información entre equipos.

Las consultas de Boards (a través del generador de consultas o WIQL) alimentan muchos widgets. Parametrice las consultas por la ruta de área/iteración del equipo para su reutilización; prefiera los widgets basados en Analytics cuando estén disponibles por su precisión y rendimiento. Métricas clave de flujo:

Tiempo de ciclo (Cycle time): Tiempo transcurrido desde el estado Activo (en progreso) hasta Finalizado; utilice el widget de tiempo de ciclo para seguir la eficiencia de la ejecución.
Tiempo de entrega (Lead time): Tiempo transcurrido desde la creación/compromiso hasta Finalizado; indica el retraso total del sistema tal como lo perciben los clientes.
Rendimiento (Throughput): Elementos completados por intervalo de tiempo; compárelo con las políticas de WIP para detectar cuellos de botella.
Diagrama de flujo acumulado: Visualiza el tamaño de las colas por estado a lo largo del tiempo; el ensanchamiento de las bandas expone restricciones y cambios de contexto. Para el seguimiento de sprints, utilice el gráfico de evolución (Burndown) (tendencia del trabajo restante hacia cero) y el de finalización (Burnup) (alcance total frente a completado, resistente a los cambios de alcance). La velocidad (Velocity) informa el esfuerzo promedio completado por sprint y sirve de base para la planificación de la capacidad; agregue solo unidades de estimación del mismo tipo entre equipos.

Cuando se necesiten analíticas de producto, conecte Azure DevOps Analytics a Power BI para combinar métricas de entrega con telemetría operativa (p. ej., tiempo de entrega frente a tasa de escape de defectos) para priorizar mejoras.

Fiabilidad, Alertas y Retroalimentación Continua

Los SLI/SLO/SLA establecen la fiabilidad como una característica de primer nivel:

SLI: Medidas cuantitativas de la experiencia del usuario, p. ej., tasa de éxito de las solicitudes, latencia p95, disponibilidad de los puntos de conexión (endpoints) críticos o tasa de finalización de tareas en la UI.
SLO: Objetivos durante un período de tiempo, p. ej., 99.9% de disponibilidad mensual o p95 < 300 ms. Vincule los SLO a los recorridos del usuario, no a la infraestructura.
Presupuestos de error: 1 − SLO; gobiernan el riesgo de los lanzamientos, los criterios de reversión (rollback) y la respuesta a incidentes. Implemente alertas de tasa de consumo del presupuesto (burn-rate) (p. ej., consumo del presupuesto de 2x y 14x) usando KQL o alertas de métricas para incumplimientos tanto rápidos como lentos.
SLA: Compromisos externos con los clientes; suelen ser menos estrictos que los SLO e incluyen penalizaciones; impulsan pero no dictan las directrices de ingeniería.

Alertas y guardias (on-call):

Use alertas de métricas para condiciones sensibles a la latencia; use alertas de logs para predicados complejos (p. ej., correlación de múltiples señales o puntuaciones de anomalías).
Reduzca la fatiga por alertas con la deduplicación (reglas de procesamiento de alertas), umbrales dinámicos, ajuste de severidad y supresión automática durante el mantenimiento planificado.
Intégrese con PagerDuty/OpsGenie a través de webhooks de grupos de acciones usando el esquema de alerta común; mapee las claves de correlación de alertas para la deduplicación de incidentes y defina políticas de escalado por servicio.
Automatice la remediación con runbooks de Azure Automation, Functions o Logic Apps (p. ej., escalar horizontalmente según la profundidad de la cola, reciclar una instancia que falla, activar/desactivar un feature flag). Registre cada acción automática como un evento personalizado en Application Insights para su auditabilidad.

Retroalimentación continua y experimentación:

Pruebas A/B y despliegues graduales: Use Azure Front Door o Traffic Manager para la división de tráfico en el borde (edge), o implemente feature flags con Azure App Configuration Feature Manager para un despliegue por usuario o basado en cohortes. Proteja las rutas de código con flags y recopile telemetría de eventos por cada variante.
Telemetría de usuario: Emita TrackEvent con el estado del feature flag, propiedades del usuario (que no sea PII) e identificadores de escenario. Analice embudos (funnels), flujos de usuario, retención y rendimiento de cohortes en Application Insights para validar hipótesis.
Análisis de uso de funcionalidades: Construya dashboards que rastreen DAU/WAU/MAU, adopción de funcionalidades y métricas de conversión. Incorpore los resultados en la priorización del backlog. Use puertas (gates) de Azure Pipelines para bloquear el despliegue a producción cuando las líneas base de los SLI en el entorno de staging fallen o se detecten regresiones en los KPI de los experimentos.

Escenario de Problema Práctico

Spotify necesita mejorar la visibilidad de extremo a extremo y la retroalimentación para sus servicios de ingesta y reproducción de podcasts desplegados en Azure Kubernetes Service (AKS) y APIs de Azure App Service. Los incidentes se detectan tarde y los equipos de producto carecen de métricas de adopción fiables para las nuevas funcionalidades de reproducción.

Instrumentar y correlacionar la telemetría de la aplicación

Añada los SDK de Application Insights a los servicios de .NET y Node.js; habilite el SDK de JavaScript de Application Insights en los clientes web. Configure cloud_RoleName y las cadenas de conexión; habilite la propagación del contexto de traza (trace-context) W3C a través de microservicios y colas de mensajes. Por qué: Asegura IDs de correlación consistentes y seguimiento distribuido para una visibilidad completa de la transacción desde el navegador hasta los servicios y sus dependencias.

Transmitir diagnósticos de la plataforma a Log Analytics

Aplique configuraciones de diagnóstico a través de Azure Policy a todos los clústeres de AKS, planes de App Service, Application Gateways, Cosmos DB y cuentas de Storage, enrutando a un espacio de trabajo central de producción con 90 días de retención y archivado en Storage. Por qué: Garantiza una cobertura uniforme de los logs/métricas de la plataforma para la correlación con KQL y una retención a largo plazo rentable.

Definir SLI, SLO y presupuestos de error

SLI: Latencia p95 de la API, tasa de éxito de las solicitudes, rendimiento del pipeline de ingesta y éxito en el inicio del reproductor.
SLO: 99.95% de éxito mensual, inicio de reproducción p95 < 300 ms, retraso en la ingesta < 2 minutos.
Cree alertas de tasa de consumo del presupuesto de error (rápidas/lentas) basadas en KQL y alertas de métricas para la latencia con umbrales dinámicos. Por qué: Convierte los resultados de negocio en objetivos de fiabilidad medibles y accionables con alertas oportunas.

Construir alertas accionables e integración con el sistema de guardia (on-call)

Cree reglas de alerta en Azure Monitor con agrupación inteligente (smart grouping); enrute a un grupo de acciones que active PagerDuty a través de un webhook usando el esquema de alerta común. Asocie runbooks de Azure Automation para escalar horizontalmente según la profundidad de la cola y reiniciar pods en mal estado. Por qué: Reduce el MTTA/MTTR a través de un sistema de aviso (paging) fiable y una autorremediación segura y auditable.

Establecer dashboards para ingeniería y producto

Dashboards a nivel de equipo en Azure DevOps: Tiempo de Ciclo (Activo→Hecho), Tiempo de Entrega (Creado→Hecho), CFD, Velocidad y Gráfico de Burndown del Sprint para los equipos (squads). Dashboards a nivel de proyecto: Gráfico de Burnup para los lanzamientos, rendimiento entre equipos y estado de los SLO a través de widgets de Markdown/Analytics. Por qué: Proporciona a los equipos (squads) información sobre la ejecución, mientras que ofrece al liderazgo una visión de la salud del portafolio y la fiabilidad.

Implementar experimentación y análisis de uso

Use feature flags de Azure App Configuration para desplegar gradualmente una nueva funcionalidad de “Omitir Silencios Inteligente” (Smart Skip Silence). Divida las cohortes con reglas de Front Door para pruebas A/B en el borde (edge) donde sea necesario. Emita TrackEvent con featureFlagState, la cohorte del usuario y métricas de resultados. Por qué: Valida el impacto de forma segura mientras captura telemetría de usuario de alta fidelidad para tomar decisiones basadas en evidencia.

Garantizar la calidad de los lanzamientos con puertas (gates)

En Azure Pipelines, añada puertas (gates) que consulten Application Insights/Log Analytics para obtener los KPI del entorno de staging (latencia p95, tasa de fallos, rendimiento de la variante del experimento). Haga fallar las puertas si no se cumplen las líneas base o los umbrales alineados con los SLO. Por qué: Evita que las regresiones lleguen a producción y alinea las decisiones de despliegue con los KPI de fiabilidad y de producto.

← Estrategia de pruebas e ingeniería de calidad · Todos los dominios · Gestión de paquetes y gestión de artefactos →

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