Tras cinco meses de desarrollo, se ha lanzado IncidentRelay 1.1. Este sistema de código abierto permite la gestión de guardias, el enrutamiento de alertas y la respuesta a incidentes, y se ejecuta en un servidor propio. IncidentRelay 1.1 es la primera versión estable (la rama 1.0 estaba en fase beta). El proyecto está dirigido a ingenieros de fiabilidad del sitio (SRE), equipos de DevOps e infraestructura que buscan una alternativa local a los servicios SaaS para la gestión de guardias, las políticas de escalamiento y la respuesta a incidentes. El código del proyecto está escrito en Python y se distribuye bajo la licencia MIT.
IncidentRelay recibe eventos de los sistemas de monitoreo, los asocia con el servicio, el equipo y la rotación, y luego envía notificaciones a los oficiales o equipos de guardia responsables. El sistema implementa horarios de guardia, rotaciones, anulaciones de turno, acuse de recibo de incidentes, estado de ACK/Resolución, recordatorios, escalamientos, reemplazos temporales de oficiales de guardia, tiempos de mantenimiento programados y supresión de alertas.
La principal ventaja del proyecto reside en el control total sobre la infraestructura y la lógica de enrutamiento. IncidentRelay se implementa en su propio entorno, funciona con su propia base de datos y permite una separación explícita de las rutas, los comandos, las rotaciones y los canales de entrega entrantes. Los tokens entrantes pertenecen a las rutas, no a los canales, lo que facilita la comprensión de qué fuente externa tiene permiso para enviar eventos a un comando específico.
IncidentRelay admite la recepción de eventos de Prometheus Alertmanager, Grafana Alerting, Zabbix, Sentry, LibreNMS, RMON, AWS SNS/CloudWatch y webhooks personalizados. Las notificaciones se pueden enviar a través de Mattermost, Slack, Telegram, Discord, Microsoft Teams, correo electrónico, webhooks, notificaciones push en navegadores/PWA y proveedores de llamadas de voz. En Mattermost y Telegram, las notificaciones pueden incluir acciones para confirmar y resolver el problema, lo que permite gestionar los incidentes sin necesidad de cambiar a una interfaz independiente.
El proyecto se puede ejecutar mediante Docker Compose, un paquete RPM para distribuciones tipo Red Hat, manualmente a través de systemd o en Kubernetes utilizando un gráfico de Helm. Se puede usar SQLite para instalaciones pequeñas, mientras que se recomienda PostgreSQL para entornos de producción y cargas de trabajo elevadas.
La nueva versión propone los siguientes cambios:
- Se añadieron rotaciones de guardia multinivel con límites de tiempo, prioridades por niveles y consideración de reemplazos temporales;
- Han aparecido un calendario de guardias, CalDAV y suscripciones ICS para calendarios externos;
- Se implementaron políticas de escalamiento de incidentes con cadenas de escalamiento de varios pasos;
- Se añadieron grupos de alertas, agrupación de eventos, notificaciones diferidas y fusión manual de alertas relacionadas;
- Han aparecido ventanas para tareas programadas y alertas "silenciosas";
- Se ha añadido la posibilidad de agregar comentarios a las alertas;
- Se añadieron prioridades de incidentes (P1-P5) y escalamiento automático de prioridades en función del nivel de importancia;
- Se implementaron el catálogo de servicios, las dependencias de servicios, los SLI/SLO, el historial de impacto del servicio y los servicios empresariales;
- Se ha añadido Explain Trace para analizar el enrutamiento: por qué una alerta se incluyó o no en un comando, se agrupó, se suprimió o se envió a un canal específico;
- Se han añadido comprobaciones (latidos/interruptor de hombre muerto) para el sistema de vigilancia, la copia de seguridad, ETL y otras tareas en las que el problema es la ausencia de la señal esperada.
Fuente: opennet.ru
