En AZ-305 el monitoreo no es "qué hace Azure Monitor" sino cómo diseñar la topología de workspaces, qué herramienta usar para cada señal (métricas, logs, trazas), y cómo balancear retención vs costo. La pregunta recurrente: ¿centralizado o descentralizado?
Contenido
| Herramienta | Señal | Cuándo en el diseño |
|---|---|---|
| Azure Monitor Metrics | Métricas numéricas de plataforma (casi tiempo real) | Alertas de CPU/latencia, autoscaling, dashboards en vivo |
| Azure Monitor Logs (Log Analytics) | Logs estructurados consultables con KQL | Análisis profundo, correlación, auditoría, alertas de log |
| Application Insights | Telemetría de aplicación (requests, dependencias, excepciones, trazas) | APM: rendimiento y fallos de apps, distributed tracing |
| Activity Log | Operaciones del plano de control (quién creó/borró qué) | Auditoría de cambios — exportar al workspace para retención |
| Diagnostic Settings | Router: envía resource logs/métricas a destinos | Workspace (análisis), Storage (archivo barato), Event Hubs (SIEM externo) |
| Microsoft Sentinel | SIEM/SOAR sobre Log Analytics | Detección de amenazas, hunting, respuesta automatizada |
| Network Watcher | Diagnóstico de red (flow logs, packet capture) | Troubleshooting de conectividad, NSG flow logs |
Regla mnemónica para diagnostic settings
Analizar → Log Analytics workspace. Archivar barato → Storage Account. Integrar con SIEM/terceros → Event Hubs. Un diagnostic setting puede enviar a varios destinos a la vez.
Recomendación general (y del CAF): un workspace central por región en la suscripción de Management. Empezar centralizado; separar solo cuando exista un driver real.
Workspace centralizado (default)
Cuándo separar workspaces
Control de acceso dentro de un workspace compartido
Qué aporta al diseño
Instrumentación
| Tipo de alerta | Señal | Cuándo diseñarla |
|---|---|---|
| Metric alert | Métrica numérica de plataforma (CPU, latencia, requests) | Baja latencia (~1 min); ideal para autoscaling triggers, SLA de rendimiento |
| Log alert | Query KQL sobre Log Analytics | Condiciones complejas (ej: 5 errores 500 en 10 min); latencia 1-5 min |
| Activity log alert | Operación del plano de control (ARM) | Auditoría: alguien borró un RG, cambió una policy, eliminó un Key Vault |
| Smart detection (App Insights) | Anomalías detectadas automáticamente | Sin umbral manual — ML detecta degradación, fallo en dependencias, excepciones inusuales |
| Prometheus alerts (AKS) | Métricas de Prometheus desde el clúster | Workloads Kubernetes — se define con reglas PromQL en Azure Monitor Workspace |
Action groups — el "a quién notificar"
Un action group es la lista de acciones a ejecutar cuando se dispara una alerta. Reutilizable: múltiples reglas de alerta apuntan al mismo group.
Principios de diseño de alertas
Señal en el examen
"Notificar al equipo cuando alguien borra un resource group" → activity log alert. "Alerta cuando CPU > 90%" → metric alert. "Ticket en ServiceNow automático al dispararse una alerta" → action group con ITSM connector. "Reiniciar automáticamente un servicio cuando falla" → action group con Automation Runbook.
| Capa | Característica | Uso de diseño |
|---|---|---|
| Retención interactiva | Datos consultables con KQL al rendimiento completo (hasta 2 años) | Operación diaria, alertas, dashboards |
| Long-term retention (archive) | Hasta 12 años, barato, no consultable directamente — restore o search jobs | Cumplimiento normativo de retención larga |
| Basic/Auxiliary table plans | Ingesta más barata, KQL limitado, retención corta | Logs de alto volumen y bajo valor (verbose, debug) |
| Commitment tiers | Descuento por compromiso de GB/día | Volúmenes predecibles ≥100 GB/día |
| Export a Storage | Diagnostic settings → storage account con lifecycle a Cool/Archive | Archivo más barato fuera del workspace, inmutabilidad |
| DCR transformations | Filtrar/transformar en la ingesta (Data Collection Rules) | Descartar columnas/filas irrelevantes antes de pagar por ellas |
El costo dominante es la INGESTA
Log Analytics cobra principalmente por GB ingerido. Las palancas de diseño: filtrar en origen (DCR transformations), planes de tabla Basic para logs verbose, sampling en App Insights, y archive/export para retención larga. Si el escenario pide "retener logs de auditoría 7 años al menor costo" → archive tier o export a storage con tier Archive.
| Requisito | Diseño |
|---|---|
| Correlacionar logs de 50 workloads con una query | Workspace central (suscripción Management) |
| Logs de Alemania no pueden salir de Alemania | Workspace dedicado en la región alemana |
| Cada equipo ve solo los logs de SUS recursos en el workspace compartido | Resource-context RBAC |
| Trazar una request a través de 10 microservicios | Application Insights (distributed tracing / App Map) |
| Probar disponibilidad de la web desde 5 regiones | App Insights availability tests |
| Retener auditoría 7 años al menor costo | Long-term retention (archive) o export a Storage Archive |
| Enviar logs al SIEM Splunk de la empresa | Diagnostic settings → Event Hubs |
| Reducir el costo de ingesta de logs verbose | DCR transformations + Basic table plan |
| Detección de amenazas y hunting sobre los logs | Microsoft Sentinel sobre el workspace |
| Notificar cuando CPU supere 90% en cualquier VM | Metric alert con scope en suscripción/RG + action group email |
| Alerta cuando alguien elimine un recurso crítico | Activity log alert (operación Delete en ese recurso) |
| Abrir ticket en ServiceNow al dispararse una alerta | Action group con ITSM connector |
| Reiniciar automáticamente un servicio al detectar fallo | Action group → Automation Runbook |
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa con workloads en West Europe diseña su monitoreo: (1) el SOC necesita correlacionar eventos de seguridad de todos los workloads, (2) cada equipo de aplicación debe ver únicamente los logs de sus propios recursos, (3) los logs de auditoría deben retenerse 7 años al menor costo. ¿Qué diseño cumple todo?
Inicia sesión para llevar tu progreso.