Se ha publicado la versión 2.0 del proyecto IncidentRelay, que desarrolla un sistema abierto para la organización de guardias, la racionalización de alertas y el seguimiento de incidentes, el cual se implementa en un servidor propio (self-hosted). El proyecto está orientado a equipos de SRE, DevOps e infraestructura que requieren una alternativa local a las plataformas en la nube para la gestión de guardias. El código está escrito en Python y se distribuye bajo la licencia MIT.
IncidentRelay acepta eventos de Prometheus Alertmanager, Grafana Alerting, Zabbix, Sentry, LibreNMS, RMON, AWS SNS/CloudWatch, Datadog, Uptime Kuma y controladores webhook arbitrarios. Después de la normalización, el evento se vincula a un servicio, equipo y rotación, se aplican reglas de enrutamiento y políticas de escalamiento, y la notificación se envía al guardia actual. Se admiten plataformas de entrega como Mattermost, Slack, Telegram, Discord, Microsoft Teams, correo electrónico, webhook, notificaciones push en navegador/PWA y proveedores de llamadas de voz.
La principal novedad de la versión 2.0 es el mecanismo de Orquestación de Eventos, que proporciona una capa separada de procesamiento de eventos entre las integraciones entrantes y el ciclo de vida de la alerta. Los cambios principales son:
- Se ha añadido un editor visual de reglas de orquestación. Las reglas pueden aplicarse globalmente o a un servicio específico, agruparse en grupos anidados de condiciones y cambiar secuencialmente la prioridad, el nivel de importancia, las etiquetas, el equipo, la ruta, el método de agrupamiento, las políticas de notificación y escalamiento;
- Se implementaron acciones para suprimir, descartar y pausar el procesamiento de eventos, extraer valores mediante expresiones regulares y JSON Path, dividir cadenas, crear variables y transformar valores;
- La configuración de la orquestación se divide en borradores editables y versiones publicadas inalterables. Se admiten la verificación de configuración, la publicación, la reversión a versiones anteriores y la adición de comentarios sobre los cambios;
- Se prevén modos disabled, shadow y active. En el modo shadow, los resultados de la ejecución de las reglas se guardan para análisis, pero no afectan el enrutamiento real. Para el período de transición, se ofrecen modos de compatibilidad legacy, hybrid y orchestration;
- Se han añadido herramientas de simulación y reproducción de eventos. Estas permiten verificar las reglas en un evento normalizado o en el payload original de la integración sin generar una alerta real. Se proporciona un rastreo de ejecución, datos de Explain y métricas del modo sombra para analizar los resultados;
- Se han implementado acciones de webhook reutilizables que se ejecutan de forma asíncrona después del procesamiento de eventos. Los encabezados se almacenan de forma cifrada, los secretos están ocultos en la API y en los registros, y por defecto, se prohíben las llamadas a redes privadas. Se pueden configurar los tiempos de espera, los reintentos y la lista de direcciones internas permitidas;
- Se ha añadido la integración con Uptime Kuma, que acepta mensajes de webhook estándar sobre el estado de los monitores. Se han implementado la normalización de estados UP y DOWN, la determinación de importancia, el procesamiento de etiquetas y un nuevo tipo de ruta entrante uptime_kuma;
- Para silencias y ventanas de mantenimiento programadas, ahora hay parámetros apply_to_existing y reactivate_on_end. El primero permite aplicar la supresión a alertas ya abiertas, mientras que el segundo determina si se debe reanudar su procesamiento al finalizar el período de supresión. Se pausan y restauran notificaciones, recordatorios y cadenas de escalado;
- Para los tokens API personales se han introducido permisos de lectura y modificación por separado para grupos, equipos, usuarios, rutas, canales, servicios, rotaciones, políticas, ventanas de servicio, verificaciones de heartbeat, SSO y orquestaciones. Los antiguos permisos agregados resources:read, resources:write y * se mantienen para la compatibilidad hacia atrás;
- Se ha añadido una interfaz de registro de auditoría con filtrado y paginación. El registro apunta a las operaciones con orquestaciones, acciones de webhook, silencias y ventanas de mantenimiento programadas, eliminando los valores confidenciales de los datos mostrados;
- En la interfaz web se ha añadido un tema oscuro y configuraciones personalizadas de idioma y apariencia. Se ha agregado localización al francés, se han ampliado las traducciones para las secciones de orquestación y mantenimiento, y se ha corregido la edición de las reglas de mapeo de grupos SSO;
- Se ha mejorado el funcionamiento de las verificaciones de heartbeat: se ha excluido la recreación de eventos de tiempo de espera, la recuperación de la señal cierra correctamente la alerta y envía una notificación sobre la resolución del problema, unificando la representación de las marcas de tiempo;
- Se ha preparado la documentación para el despliegue en Kubernetes utilizando Helm. Se ha añadido un controlador separado de Slack Socket Mode en el chart de Helm, necesario para el funcionamiento de los botones interactivos de confirmación y cierre de incidentes;
- Se ha reforzado la protección de las solicitudes HTTP salientes, expresiones regulares y datos confidenciales, se ha centralizado el manejo de UTC y zonas horarias, se han revisado los cálculos de los horarios de rotación y se ha ampliado la cobertura con pruebas automáticas.
Se recomienda realizar una copia de seguridad de la base de datos antes de la actualización. Los cambios necesarios en el esquema se llevan a cabo mediante el mecanismo de migraciones de IncidentRelay. Para una implementación gradual de Event Orchestration, los desarrolladores recomiendan utilizar primero los modos shadow y hybrid, verificar los rastreos de ejecución de las reglas y solo después cambiar la orquestación a modo active.
Fuente: opennet.ru
