En un entorno de producción no todos los eventos tienen la misma importancia. Que un backend esté en mantenimiento, que todos los backends estén down, que el cluster IP pase a otro nodo, que el certificado vaya a caducar en 30 días o que se supere el umbral de request rate exigen respuestas operativas distintas. Si todo esto se convierte en una alarma uniforme por correo, el equipo sufre fatiga de alarmas en poco tiempo.
En los enfoques clásicos la notificación suele limitarse a correo y syslog. Sin embargo, los equipos de operación quieren recibir distintos eventos por distintos canales: el failover crítico por SMS, el aviso rutinario por la interfaz, el evento de seguridad por SNMP o Syslog, el resumen para directivos por correo. Sin separación de canales, o bien todos reciben todo, o bien los eventos críticos pasan desapercibidos.
La gestión de horas de silencio también es importante. Despertar a todo el equipo a las 03:00 por un aviso de baja importancia es innecesario; pero una interrupción real o un cambio de cluster IP debe seguir siendo visible. La hora de silencio no debe significar que el evento desaparezca por completo, sino que se gestione por el canal correcto y en el momento correcto.
Reportar con el mismo texto eventos como pool down, backend down, cluster IP swap y cierre de zona dificulta el análisis de causa raíz. El operador primero intenta entender qué significa la alarma y luego toma acción. Ese retraso, especialmente en plataformas de alto tráfico, se refleja directamente en la calidad del servicio.
El Sistema de Notificaciones de TR7 separa los eventos con ciclo de vida de alarmas, más de 30 claves de estado predefinidas, multicanal, multilingüe, horas de silencio y gestión de umbrales por pool; los entrega a la persona correcta, por el canal correcto, con el contexto correcto.
TR7 gestiona las notificaciones no como mensajes únicos, sino como objetos de alarma con ciclo de vida y acciones basadas en canales.
Las alarmas activas se mantienen por alarmKey, se actualizan con updateAlarm y se cierran con endAlarm. Así el mismo evento no se produce una y otra vez como una alarma nueva; se rastrean el inicio, la actualización y el cierre del evento.
El estado de la alarma y la notificación puede transferirse a los demás nodos dentro del cluster. Así el equipo de operación puede ver no solo los eventos del nodo al que está conectado, sino también la situación crítica de todo el cluster.
El estado del pool se clasifica con los valores UNKNOWN, OK, WARN, DISABLED, ERR y EVALUATING. Este modelo no reduce las situaciones de mantenimiento, aviso, error y evaluación a un mismo texto de alarma plano.
Los estados de cluster IP se evalúan con señales distintas como la accesibilidad de la interfaz, el conflicto de IP, la transición de IP y el comportamiento de dos nodos. Los eventos de failover se entregan al equipo de operación con un contexto más claro.
El Sistema de Notificaciones ofrece ciclo de vida de alarmas, umbrales de pool, multicanal, multilingüe, horas de silencio, aviso de certificado e historial de eventos archivable.
El flujo updateAlarm, endAlarm y getAlarms sigue las alarmas activas con su ciclo de vida. Cuando vuelve a llegar el mismo alarmKey, el evento se actualiza; no se duplica como una alarma completamente nueva. Con campos como staticPayload, ifAbsent y dontNotify, el comportamiento del evento puede gestionarse de forma más controlada. Esta estructura reduce el ruido de alarmas y hace más significativo el historial de eventos.
Para cada pool pueden definirse umbrales de serviceStatus, poolStatus, bandwidth, request rate, current session y new connection. Dentro de la misma estructura pueden establecerse las preferencias de canal email, SMS, WhatsApp, BiP, SNMP y la interfaz. Así un servicio crítico puede monitorizarse con una política de alarma más agresiva y un servicio de baja importancia con una política más silenciosa. El comportamiento de notificación no se aplica de forma uniforme a toda la plataforma.
TR7 ofrece un modelo de notificación que soporta múltiples canales como email, SMS, WhatsApp, BiP, SNMP, Syslog y la interfaz. Los eventos críticos de infraestructura pueden entregarse por SMS o SNMP a los sistemas de gestión de red, los resúmenes para directivos por correo y las situaciones rutinarias a través de la interfaz. El mismo evento puede enviarse a distintos canales con distinta prioridad. Esta flexibilidad reduce la dependencia de un gestor de alarmas externo.
NotificationTranslator puede producir los textos de notificación en distintos idiomas con una lógica de traducción basada en diccionario. Un equipo de operación puede recibir las notificaciones en un idioma y otro equipo internacional en otro. Es posible entregar el mismo evento a distintos usuarios en distintos idiomas. Esto reduce el riesgo de interpretación errónea en operaciones multipaís.
Pueden usarse más de 30 claves de estado como poolDisabled, allBeDown, noBeGiven, beDown, beStateUnknown, beMaint, poolDown, poolInterfaceAbsent, zoneClosed, clusterIpBoth, clusterIpPossibleCollide, clusterIpSwitched y clusterIpNone. Estas claves hacen más explícito el texto de la alarma. El operador no recibe solo un mensaje de "servicio con problema"; también ve el tipo del problema. El tiempo de intervención se acorta.
Con silentAtNight pueden silenciarse determinadas notificaciones durante las horas nocturnas. Esto no significa que el evento desaparezca por completo; puede seguir mostrándose en la interfaz o incluirse en el resumen de la mañana. Aplicando una política de canal aparte para los eventos críticos, las alarmas realmente importantes pueden seguir entregándose. Se reduce la fatiga de alarmas mientras se conserva la visibilidad operativa.
Con el campo notifyDaysBeforeCertificateExpiry puede generarse un aviso un número determinado de días antes de la fecha de vencimiento del certificado. Por ejemplo, faltando 30 días puede enviarse una notificación por correo o por la interfaz. Así la operación de renovación de certificados no se deja para el último día. Los olvidos que podrían provocar una interrupción TLS se detectan en una fase temprana.
Los miembros de un contact group pueden definirse con direcciones de correo, números de SMS e información de tipo de usuario. Las notificaciones pueden dirigirse a un usuario individual, a un grupo de equipo o a un tipo de usuario. Este modelo facilita orientar por separado a los equipos de guardia, SOC, SRE o de dirección. Los cambios de personas pueden gestionarse sin romper la política de canales.
Pueden configurarse host SMTP, puerto, authentication, username, password, seguridad TLS, validación de certificado, sender name, sender address, cc, bcc, attachment y los ajustes de mensaje HTML. El valor de timeout de conexión de correo puede mantenerse en torno a los 10 segundos. Esta estructura facilita la integración con el relay de correo o la infraestructura SMTP existente de la organización. Las notificaciones por correo pueden adaptarse a las políticas de marca y de seguridad.
Los logs de alarmas y de notificaciones pueden archivarse con nombres separados. Con compresión zip y un alto nivel de compresión, los eventos pasados pueden conservarse para auditoría e investigación. En los procesos de PCI, gestión de cambios o análisis posterior a incidentes, el historial de notificaciones puede usarse como evidencia. Puede funcionar junto con procesos de archivado externos sin perder la visibilidad local.
El campo NotificationType realiza la distinción entre alarma, notification e info con clases como A, N e I. Esta distinción es importante para la criticidad del evento y la forma en que se presenta al usuario. No todo mensaje de información se comporta como una alarma; ni toda alarma desaparece como una notificación ordinaria. El comportamiento de la interfaz y de los canales externos puede alimentarse de esta clasificación.
El campo pairId de BasicNotification puede usarse para relacionar las notificaciones que pertenecen al mismo grupo de eventos. Por ejemplo, la apertura, la actualización y el cierre de una alarma pueden rastrearse dentro de la misma familia de eventos. Esto facilita ver junta la cadena de eventos en el lado SIEM o de auditoría. En lugar de mensajes individuales, puede analizarse todo el proceso del evento.
El Sistema de Notificaciones se opera junto con los valores de estado, los nombres de log, la compresión, la seguridad SMTP y la máquina de estados de cluster IP.
Los valores de estado del pool se clasifican como UNKNOWN=-1, OK=0, WARN=1, DISABLED=2, ERR=3 y EVALUATING=4. Este modelo numérico proporciona una base coherente para la evaluación de alarmas y la representación en la interfaz. Los estados se tratan no solo como texto, sino como valores sobre los que se puede decidir.
Los logs de alarmas pueden mantenerse con el nombre basic-alarms y los de notificaciones con basic-notifications. Esta separación permite investigar por separado el ciclo de vida del evento y las notificaciones entregadas al usuario. Los procesos de operación y auditoría pueden leer distintos tipos de log según su propia necesidad.
Los archivos de alarmas y notificaciones pueden mantenerse en formato zip y con un alto nivel de compresión. Esto reduce el coste de conservación a largo plazo. Se facilita el acceso a los registros de notificación pasados para auditoría.
Bajo `_lb.*` se encuentran más de 30 claves de estado predefinidas. Estas claves se usan para describir de forma más granular los comportamientos de pool, backend, interfaz, zona y cluster IP. El texto de notificación y la lógica de decisión se enriquecen mediante estas claves.
En el envío de correo, el valor de timeout de conexión puede configurarse en 10000 ms. El comportamiento de la seguridad TLS y la validación de certificado está bajo control del usuario. Esto permite realizar la integración con el relay de correo según los requisitos de seguridad de la organización.
Los estados de cluster IP se interpretan con una máquina de estados aparte. Situaciones como la inaccesibilidad de la IP, el estado de la interfaz, un posible conflicto o la transición de nodo pueden convertirse en valores de estado de cluster IP consolidados. Las alarmas de failover se producen con mayor precisión con este contexto.
Cuando un evento de backend down de baja importancia ocurre a las 02:00, silentAtNight puede detener el envío de correo. El evento permanece activo en la interfaz y puede incluirse en el resumen de la mañana. Así se reduce la alarma nocturna innecesaria sin que el evento desaparezca por completo.
El equipo de operación puede ajustar el valor de notifyDaysBeforeCertificateExpiry en 30 días. Cuando se acerca la vigencia del certificado, el sistema genera una notificación por correo o por la interfaz. Disminuyen los riesgos de renovación de última hora que podrían provocar una interrupción TLS.
Cuando el cluster IP pasa a otro nodo, puede generarse el evento clusterIpSwitched. Este evento puede entregarse al equipo de operación por SMS, SNMP o la interfaz. Cuando se produce el failover, el equipo se entera en el momento del evento, no después.
Cuando se supera el umbral de request rate, bandwidth, session o new connection, puede generarse una notificación SNMP. El sistema de gestión de red recoge este evento en su propio panel de alarmas. Los equipos de operación de seguridad y de red ven el mismo umbral en un flujo de monitorización común.
Los logs de alarmas y notificaciones pueden conservarse como un archivo comprimido. Durante la auditoría puede mostrarse qué evento ocurrió y cuándo, qué canal se utilizó y si la alarma se cerró o no. El historial de notificaciones se convierte en evidencia operativa.
Mientras un equipo recibe la misma alarma por correo en un idioma, otro equipo de operación internacional puede recibir el mensaje en otro idioma. NotificationTranslator produce el texto del evento según el idioma del usuario. En operaciones multipaís se reduce el malentendido de la alarma.
Ciclo de vida de alarmas, más de 30 claves de estado, multicanal y horas de silencio. Mostrémoslo en una instalación en vivo en su propio entorno.