AZ-104
Deep Dive
Las alertas de Azure Monitor notifican cuando hay condiciones de interés en tus recursos — umbrales de métrica, cambios de estado o eventos específicos en logs. El AZ-104 evalúa la creación y configuración de alert rules, tipos de alerta y action groups.
Contenido
Una Alert Rule monitorea continuamente datos y crea una alerta cuando se cumplen condiciones definidas. Consta de: Scope (qué monitorear), Condition (cuándo disparar), Actions (qué hacer) y Alert Details (cómo se llama y documenta).
Partes de una Alert Rule
Scope
Qué recurso(s) monitorear. Puede ser un recurso específico, un grupo de recursos, o toda una suscripción. Para alertas de log: el Log Analytics Workspace.
Condition (Signal + Logic)
Qué señal monitorear (métrica, log, activity log, health) y bajo qué condición disparar (umbral, ventana de tiempo, operador).
Actions
Qué hacer cuando se dispara: Action Group con notificaciones y/o automatizaciones.
Alert Details
Nombre, descripción, severidad (0-4) y si la alerta se crea habilitada o deshabilitada.
Estados de una alerta
Metric Alerts
Basadas en valores de métricas de Azure Monitor. Evaluación frecuente (cada minuto). Baja latencia.
Log Search Alerts
Basadas en resultados de queries KQL en Log Analytics. Mayor latencia (mínimo 1 minuto, típicamente 5-15 min). Para patrones complejos.
Activity Log Alerts
Basadas en eventos del Activity Log (operaciones sobre recursos). Para detectar cambios de configuración o eventos de servicio.
Service Health Alerts
Notifican de incidentes, mantenimiento planificado y avisos de salud de servicios Azure que afectan a tu suscripción/región.
| Nivel | Nombre | Descripción | Ejemplo |
|---|---|---|---|
| Sev 0 | Critical | Servicio caído — impacto inmediato en producción | VM down, base de datos inaccesible |
| Sev 1 | Error | Problema grave que requiere atención urgente | CPU >95% sostenido, disco >90% |
| Sev 2 | Warning | Situación que podría convertirse en error | CPU >80%, conexiones DB altas |
| Sev 3 | Informational | Evento de información — sin impacto inmediato | Inicio de mantenimiento planificado |
| Sev 4 | Verbose | Información detallada para diagnóstico | Logs de debug, eventos de tracing |
Buenas prácticas
Límites de action groups
• Máx 5 action groups por alert rule
• Máx 1000 email per hour (rate limiting)
• SMS: 1 por 5 minutos por número de teléfono
• Voice: 1 por 5 minutos por número
• Webhook: reintentos automáticos si falla (exponential backoff)
Las Alert Processing Rules (antes llamadas Action Rules) permiten modificar el comportamiento de alertas ya disparadas: suprimir notificaciones durante ventanas de mantenimiento, agregar action groups adicionales o filtrar qué alertas reciben qué acciones.
Supresión por mantenimiento
Silencia todas las alertas de ciertos recursos durante una ventana programada. Ej: silenciar alertas de CPU durante actualizaciones de OS de 00:00-04:00.
Añadir action group
Agrega un action group adicional a alertas que cumplan ciertos criterios, sin modificar las alert rules existentes. Útil para notificar a múltiples equipos.
Asignar propietario
Asigna automáticamente alertas a un equipo o persona según el recurso, severidad o grupo de recursos afectado.
Los Smart Groups agrupan automáticamente alertas relacionadas usando ML, reduciendo el ruido de alertas. En lugar de recibir 50 alertas individuales de distintas VMs durante un incidente, recibes 1 Smart Group con todas ellas relacionadas.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Un equipo quiere recibir una alerta cuando la CPU de cualquier VM en una suscripción supera el 90% durante más de 5 minutos consecutivos. ¿Qué tipo de alerta y configuración es más eficiente?