Por qué tu resumen de 12 horas en Zabbix omite problemas
Hay algo muy satisfactorio en recibir un correo de resumen bien estructurado. Cada 12 horas llega a tu bandeja de entrada un informe limpio, etiquetado, filtrado y mostrando exactamente lo que tu equipo necesita ver. Transmite una sensación de control y orden, como si por fin hubieras domado el ruido, hasta que te das cuenta de que solo te está contando la mitad de la historia.
Las alertas históricas son sencillas porque ya terminaron. Están cerradas y acotadas en una ventana de tiempo clara. Consultas los eventos de las últimas 12 horas, aplicas tus filtros de etiquetas, formateas la salida y la envías, y los datos regresan limpios, con límites definidos y sin ambigüedades.
Las alertas activas son donde todo se complica. En el momento en que intentas incluir los problemas actuales, estás consultando estado en lugar de historial, y Zabbix gestiona ambas cosas de manera distinta. Los eventos históricos viven en un plano y los problemas en curso viven en otro.
Si tu script consulta event.get con un filtro temporal, probablemente solo estés capturando los eventos ocurridos durante las últimas 12 horas. Eso funciona a la perfección para un informe de resumen. Sin embargo, puede que una alerta activa empezara hace 3 días y siga abierta, por lo que nunca aparecerá en una consulta simple de «últimas 12 horas». Esa es la trampa.
Lo que realmente buscas son alertas que continúen en estado de problema, algo muy diferente a las alertas ocurridas recientemente. Eso exige otra llamada a la API, o al menos un filtro distinto. En lugar de filtrar por tiempo, necesitas filtrar por value=1 (estado de problema) y recent=true, o la lógica equivalente según tu enfoque de API.
En otras palabras, tu script de resumen probablemente requiera dos consultas:
- Eventos históricos en las últimas 12 horas.
- Problemas actuales sin importar su hora de inicio.
Después combinas los resultados de forma inteligente. No basta con anexar los datos sin más; la combinación debe evitar duplicados cuando un problema comenzó en las últimas 12 horas y aún continúa activo.
Aquí es donde muchos se atascan. Han programado un script de informes centrado en el historial de eventos, pero en las versiones recientes de Zabbix los problemas activos se obtienen mucho mejor con problem.get, ya que ese endpoint interpreta el estado de los problemas en curso con mayor limpieza.
Si estás en las versiones 6.x o 7.x, problem.get es tu mejor aliado. Elimina la necesidad de comprobar manualmente si existe un evento de recuperación y te muestra directamente lo que está roto en ese instante.
Cuesta admitirlo, pero la sección de alertas activas puede tener más valor que el resumen histórico. Los resúmenes históricos resultan útiles para analizar tendencias: «¿Qué falló anoche?» «¿Qué osciló esta mañana?» Las alertas activas representan la verdad operativa y responden a la única pregunta que de verdad importa a las 9 AM, que es qué sigue ardiendo ahora mismo.
El hecho de que ya utilices etiquetas para filtrar el contenido supone una base sólida, porque las etiquetas facilitan la escalabilidad. Puedes aplicar los mismos filtros de etiquetas a tus consultas históricas y activas, de modo que el correo solo contenga aquello que a tu equipo le interesa.
La estructura del correo electrónico también importa. Si te limitas a volcar las alertas activas en la misma sección que las históricas, el resultado confunde. Un enfoque más claro:
- Sección 1: Problemas activos (abiertos ahora mismo)
- Sección 2: Problemas en las últimas 12 horas (incluidos los resueltos)
Esa separación evita la sobrecarga cognitiva, porque quien lo lee distingue de inmediato qué requiere atención urgente y qué quedó ya resuelto.
También hay una decisión lógica que debes tomar: ¿quieres incluir problemas activos prolongados en cada correo? Si un fallo lleva abierto 30 días, aparecerá cada 12 horas de forma continua. Algunos equipos prefieren mantenerlo visible para no perder la presión sobre el problema. Otros ocultan las incidencias que superan cierto umbral de antigüedad a menos que cambie su gravedad. Esa es una decisión organizativa más que técnica.
La otra cuestión planteada, sobre si existe un repositorio compartido de scripts para este tipo de tareas, resulta interesante. En realidad no hay un catálogo centralizado de scripts de Zabbix. La mayoría de administradores sube sus herramientas puntuales a GitHub y las comparte por si a otros les sirven.
Eso tiene ventajas y desventajas. Mantiene el ecosistema abierto y flexible, pero también provoca que todo el mundo reinvente scripts similares una y otra vez; resúmenes de alertas, exportaciones de SLA y paneles directivos abundan repartidos en decenas de repositorios privados. Si pules el tuyo y lo publicas, es muy probable que otra persona esté lidiando exactamente con el mismo reto.
Conviene valorar otro ángulo: ¿realmente necesitas un script independiente? Las versiones más recientes de Zabbix permiten programar informes. Si tu caso de uso consiste únicamente en resúmenes por correo, podrías crear un panel personalizado con widgets filtrados mediante etiquetas y programar su envío como informe. Ese método incluye los problemas activos automáticamente porque los paneles reflejan el estado en tiempo real. En cambio, si tu script necesita agregaciones complejas, formatos avanzados o lógica específica, mantener el uso de la API tiene todo el sentido.
El origen del problema radica casi con seguridad en consultar eventos por tiempo cuando deberías consultar problemas por estado. En cuanto cambias esa perspectiva mental, el fallo de las alertas activas desaparecidas se resuelve.
Al incorporar esa segunda consulta, tu resumen se convierte en una auténtica radiografía operativa en vez de una simple recapitulación histórica, mostrando lo que sigue pasando junto a lo que ya pasó. Ese es el correo que la gente de verdad lee.