En el examen AZ-305, la arquitectura de monitoreo y registro es el dominio que valida directamente tus capacidades como arquitecto de soluciones. La mayoría de las preguntas no se centran en memorizar nombres de servicios, sino en juzgar qué configuración elegir ante un escenario determinado. Si comprendes cómo se conectan Azure Monitor, Log Analytics, Application Insights, Diagnostic Settings y Alert Rules, podrás resolver la gran mayoría de las preguntas de este dominio. Este artículo sintetiza los conceptos clave y los criterios de decisión a partir de 25 preguntas reales del examen.
---
Flujo de datos en Azure Monitor
Azure Monitor es la plataforma de monitoreo unificada que supervisa todo el entorno en la nube. Recopila datos en cuatro categorías principales.
Las métricas son datos numéricos de series temporales: utilización de CPU, uso de memoria, rendimiento de red y mediciones similares. La mayoría de los recursos de Azure emiten métricas de forma automática y el período de retención predeterminado es de 93 días.
Los registros son eventos estructurados que responden a "quién hizo qué y cuándo". Por defecto, los registros permanecen dentro del propio recurso. Para analizarlos, debes enrutarlos a un área de trabajo de Log Analytics mediante Diagnostic Settings.
El Activity Log es un registro de plataforma que registra automáticamente todas las operaciones de administración realizadas a través de Azure Resource Manager: implementaciones de recursos, eliminaciones, cambios de configuración y otros eventos del plano de control. No se requiere instalación de agente ni Diagnostic Settings; puedes consultarlo de inmediato y se retiene 90 días de forma predeterminada.
Los registros de diagnóstico son datos operativos generados dentro de un recurso: SQLInsights para Azure SQL Database, registros de App Service, registros de acceso a Key Vault, entre otros. Debes configurar Diagnostic Settings para especificar un destino (Log Analytics, Storage Account o Event Hub) antes de que se recopile cualquier dato.
Trampa del examen: "Consultar el historial de administración de inmediato, sin agente ni configuración adicional" → Activity Log. Analizar registros operativos dentro de un recurso → Diagnostic Settings debe ir primero.
---
Diseño del área de trabajo de Log Analytics
El área de trabajo de Log Analytics es el almacén central de registros de Azure Monitor. Las preguntas del examen suelen indagar sobre el número adecuado de áreas de trabajo y cómo optimizar los costos.
Una sola vs. múltiples áreas de trabajo
Network Insights, Application Insights basado en área de trabajo, Microsoft Sentinel y VM Insights se pueden consolidar en una sola área de trabajo de Log Analytics. El número de servicios no es igual al número de áreas de trabajo. Un solo área de trabajo es suficiente cuando el objetivo es la centralización y la correlación entre servicios; considera múltiples áreas de trabajo solo cuando los equipos requieran aislamiento completo o soberanía de datos. Dado que un solo recurso admite hasta cinco Diagnostic Settings, dos equipos que cada uno quiera su propio área de trabajo independiente pueden simplemente crear dos Diagnostic Settings que apunten a dos áreas de trabajo distintas.
Agentes de recopilación de datos: AMA y DCR
El Azure Monitor Agent (AMA) reemplaza al antiguo MMA y se utiliza junto con un Data Collection Rule (DCR). Un DCR es un recurso de política que define qué recopilar y a dónde enviarlo.
Al calcular el número de DCRs necesarios, el factor determinante no es la cantidad de VMs sino la diferencia en el sistema operativo y el tipo de fuente de datos. Si tienes 20 VMs con Windows recopilando registros de eventos de seguridad y 15 VMs con Linux recopilando Syslog, necesitas como mínimo dos DCRs porque los tipos de sistema operativo son diferentes.
Un Data Collection Endpoint (DCE) solo es necesario en entornos con aislamiento de red. Si las máquinas pueden alcanzar un endpoint público y no hay requisito de aislamiento, el recuento de DCEs es cero. A menos que la pregunta mencione Private Link o bloqueo de internet, asume que no se necesita un DCE.
Retención de datos y optimización de costos
El período de retención predeterminado de un área de trabajo de Log Analytics es de 30 días. La retención interactiva máxima es de 730 días (2 años); con el nivel de archivo, los datos pueden conservarse hasta 4.383 días (aproximadamente 12 años). El nivel interactivo admite consultas KQL pero tiene un costo mayor; el nivel de archivo restringe las consultas pero resulta más económico.
Para reducir los costos de ingesta, cambia a un plan de precios de Commitment Tier. Puedes ahorrar más del 30% en comparación con el pago por uso, y el cambio no afecta los Alert Rules existentes ni los runbooks de automatización. Ten en cuenta que el parámetro retention days en una Diagnostic Settings de Storage Account controla el ciclo de eliminación automática de blobs; es independiente del período de retención consultable en Log Analytics.
---
Application Insights y trazado distribuido
Application Insights es un servicio dedicado de monitoreo del rendimiento de aplicaciones (APM). A diferencia de Azure Monitor, que se enfoca en métricas de infraestructura, Application Insights se especializa en el análisis a nivel de transacción y en el análisis del comportamiento del usuario.
Tres capacidades principales
Application Map visualiza las relaciones de llamada y las dependencias entre microservicios en un gráfico interactivo. Puedes identificar de un vistazo los servicios con tasas de error elevadas y los cuellos de botella en la latencia de respuesta.
El trazado distribuido (Distributed Tracing) rastrea la línea de tiempo completa de extremo a extremo de una sola solicitud a medida que atraviesa múltiples microservicios.
La analítica de usuarios ofrece seis tipos de análisis: Users, Sessions, Funnels, Retention, User Flows y más, todo dentro de un único servicio.
Codeless Attach y pruebas de disponibilidad
Codeless Attach activa la instrumentación automática en Azure App Service sin ningún cambio en el código ni en el SDK; lo configuras únicamente desde el portal. Siempre que una pregunta requiera análisis de tiempos de respuesta a nivel de transacción y llamadas a dependencias sin modificar el código, esta función es la respuesta correcta.
Las pruebas de disponibilidad (Availability Tests) son monitoreo de transacciones sintéticas que simulan periódicamente flujos de usuario sin usuarios reales. Se admiten tres tipos: pruebas de URL Ping, pruebas estándar y pruebas web de varios pasos. Se ejecutan desde ubicaciones de Azure en todo el mundo sin necesitar instalación de agente. Cuando una pregunta pida monitoreo sintético sin infraestructura adicional, elige las Availability Tests de Application Insights.
---
Diseño de alertas y respuesta automatizada
El sistema de alertas se compone de tres elementos: un Alert Rule, un Action Group y un Alert Processing Rule.
Alert Rules y Action Groups
Las alertas de métricas se basan en umbrales numéricos (utilización de CPU, tasa de errores HTTP 5xx) y pueden evaluarse con una frecuencia de hasta un minuto. Las alertas basadas en consultas de registro se disparan según los resultados de una consulta KQL. Un único Action Group puede compartirse entre múltiples Alert Rules. Si tres eventos (reinicio de VM, desasignación de VM y apagado de VM) necesitan notificar a los mismos destinatarios, el diseño óptimo es un Action Group combinado con tres Activity Log Alert Rules. Cuando los destinatarios cambien, solo necesitas actualizar el Action Group. Los Alert Processing Rules se utilizan para suprimir notificaciones durante ventanas de mantenimiento.
Si los registros deben recopilarse únicamente por rutas privadas, sin pasar por internet, utiliza Azure Monitor Private Link Scope (AMPLS). AMPLS conecta los espacios de trabajo de Log Analytics y Application Insights a Private Endpoints dentro de tu VNet.
---
Tabla comparativa de servicios
La siguiente tabla resume los principales tipos de datos recopilados por la plataforma Azure Monitor y las características de cada servicio.
| Tipo de dato | Servicio principal | Almacenamiento | Recopilación automática | Casos de uso principales | |---|---|---|---|---| | Métricas | Azure Monitor Metrics | Base de datos de métricas (93 días) | Mayormente automática | Monitoreo de rendimiento en tiempo real, alertas por umbral | | Registros | Área de trabajo de Log Analytics | Log Analytics (predeterminado 30 días) | Requiere Diagnostic Settings | Consultas KQL, análisis de correlación, auditoría a largo plazo | | Trazas | Application Insights | Vinculado a Log Analytics (predeterminado 90 días) | SDK o Codeless Attach | Trazado distribuido, análisis de transacciones | | Activity Log | Azure Activity Log | Automático de plataforma (predeterminado 90 días) | Totalmente automático | Auditoría de operaciones de administración, historial de implementaciones |
Perspectiva de tabla: registros de eventos de seguridad de VMs con Windows → tabla SecurityEvent; syslog de Linux → tabla Syslog; operaciones de administración de Azure → tabla AzureActivity; registros de diagnóstico de recursos → tabla AzureDiagnostics. SecurityEvent y Syslog se diferencian por sistema operativo.
---
Criterios de decisión que confunden en el examen
Escenario 1: Auditoría de operaciones de administración
"Consultar el historial de implementación de recursos de inmediato, sin agente ni configuración adicional" — la respuesta es Activity Log. Se retiene automáticamente durante 90 días. Para agregar Activity Logs de múltiples suscripciones en un informe mensual, enrútalos a Log Analytics y usa consultas KQL.
Escenario 2: Análisis de rendimiento sin cambios de código
"Analizar tiempos de respuesta a nivel de transacción y llamadas a dependencias sin cambios de código" — Application Insights Codeless Attach e