{"id":183054,"date":"2026-08-20T10:54:33","date_gmt":"2026-08-20T08:54:33","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/vypusk-incidentrelay-2-0-sistemy-dlya-organizaczii-dezhurstv-i-marshrutizaczii-opoveshhenij"},"modified":"2026-08-20T10:54:38","modified_gmt":"2026-08-20T08:54:38","slug":"incidentrelay-2-0-release-on-call-scheduling-and-alert-routing-system","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/incidentrelay-2-0-release-on-call-scheduling-and-alert-routing-system","title":{"rendered":"Lanzamiento de IncidentRelay 2.0, un sistema para la organizaci\u00f3n de turnos y la enrutaci\u00f3n de alertas","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Se ha publicado la versi\u00f3n 2.0 del proyecto IncidentRelay, que desarrolla un sistema abierto para la organizaci\u00f3n de guardias, la racionalizaci\u00f3n de alertas y el seguimiento de incidentes, el cual se implementa en un servidor propio (self-hosted). El proyecto est\u00e1 orientado a equipos de SRE, DevOps e infraestructura que requieren una alternativa local a las plataformas en la nube para la gesti\u00f3n de guardias. El c\u00f3digo est\u00e1 escrito en Python y se distribuye bajo la licencia MIT. <\/p>\n
IncidentRelay acepta eventos de Prometheus Alertmanager, Grafana Alerting, Zabbix, Sentry, LibreNMS, RMON, AWS SNS\/CloudWatch, Datadog, Uptime Kuma y controladores webhook arbitrarios. Despu\u00e9s de la normalizaci\u00f3n, el evento se vincula a un servicio, equipo y rotaci\u00f3n, se aplican reglas de enrutamiento y pol\u00edticas de escalamiento, y la notificaci\u00f3n se env\u00eda al guardia actual. Se admiten plataformas de entrega como Mattermost, Slack, Telegram, Discord, Microsoft Teams, correo electr\u00f3nico, webhook, notificaciones push en navegador\/PWA y proveedores de llamadas de voz. <\/p>\n
La principal novedad de la versi\u00f3n 2.0 es el mecanismo de Orquestaci\u00f3n 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: <\/p>\n
\n
Se ha a\u00f1adido un editor visual de reglas de orquestaci\u00f3n. Las reglas pueden aplicarse globalmente o a un servicio espec\u00edfico, agruparse en grupos anidados de condiciones y cambiar secuencialmente la prioridad, el nivel de importancia, las etiquetas, el equipo, la ruta, el m\u00e9todo de agrupamiento, las pol\u00edticas de notificaci\u00f3n y escalamiento;\n
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;\n
La configuraci\u00f3n de la orquestaci\u00f3n se divide en borradores editables y versiones publicadas inalterables. Se admiten la verificaci\u00f3n de configuraci\u00f3n, la publicaci\u00f3n, la reversi\u00f3n a versiones anteriores y la adici\u00f3n de comentarios sobre los cambios;\n
Se prev\u00e9n modos disabled, shadow y active. En el modo shadow, los resultados de la ejecuci\u00f3n de las reglas se guardan para an\u00e1lisis, pero no afectan el enrutamiento real. Para el per\u00edodo de transici\u00f3n, se ofrecen modos de compatibilidad legacy, hybrid y orchestration;\n
Se han a\u00f1adido herramientas de simulaci\u00f3n y reproducci\u00f3n de eventos. Estas permiten verificar las reglas en un evento normalizado o en el payload original de la integraci\u00f3n sin generar una alerta real. Se proporciona un rastreo de ejecuci\u00f3n, datos de Explain y m\u00e9tricas del modo sombra para analizar los resultados;\n
Se han implementado acciones de webhook reutilizables que se ejecutan de forma as\u00edncrona despu\u00e9s del procesamiento de eventos. Los encabezados se almacenan de forma cifrada, los secretos est\u00e1n ocultos en la API y en los registros, y por defecto, se proh\u00edben las llamadas a redes privadas. Se pueden configurar los tiempos de espera, los reintentos y la lista de direcciones internas permitidas;\n
Se ha a\u00f1adido la integraci\u00f3n con Uptime Kuma, que acepta mensajes de webhook est\u00e1ndar sobre el estado de los monitores. Se han implementado la normalizaci\u00f3n de estados UP y DOWN, la determinaci\u00f3n de importancia, el procesamiento de etiquetas y un nuevo tipo de ruta entrante uptime_kuma;\n
Para silencias y ventanas de mantenimiento programadas, ahora hay par\u00e1metros apply_to_existing y reactivate_on_end. El primero permite aplicar la supresi\u00f3n a alertas ya abiertas, mientras que el segundo determina si se debe reanudar su procesamiento al finalizar el per\u00edodo de supresi\u00f3n. Se pausan y restauran notificaciones, recordatorios y cadenas de escalado;\n
Para los tokens API personales se han introducido permisos de lectura y modificaci\u00f3n por separado para grupos, equipos, usuarios, rutas, canales, servicios, rotaciones, pol\u00edticas, 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\u00e1s;\n
Se ha a\u00f1adido una interfaz de registro de auditor\u00eda con filtrado y paginaci\u00f3n. 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;\n
En la interfaz web se ha a\u00f1adido un tema oscuro y configuraciones personalizadas de idioma y apariencia. Se ha agregado localizaci\u00f3n al franc\u00e9s, se han ampliado las traducciones para las secciones de orquestaci\u00f3n y mantenimiento, y se ha corregido la edici\u00f3n de las reglas de mapeo de grupos SSO;\n
Se ha mejorado el funcionamiento de las verificaciones de heartbeat: se ha excluido la recreaci\u00f3n de eventos de tiempo de espera, la recuperaci\u00f3n de la se\u00f1al cierra correctamente la alerta y env\u00eda una notificaci\u00f3n sobre la resoluci\u00f3n del problema, unificando la representaci\u00f3n de las marcas de tiempo;\n
Se ha preparado la documentaci\u00f3n para el despliegue en Kubernetes utilizando Helm. Se ha a\u00f1adido un controlador separado de Slack Socket Mode en el chart de Helm, necesario para el funcionamiento de los botones interactivos de confirmaci\u00f3n y cierre de incidentes;\n
Se ha reforzado la protecci\u00f3n 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\u00e1lculos de los horarios de rotaci\u00f3n y se ha ampliado la cobertura con pruebas autom\u00e1ticas. <\/ul>\n
Se recomienda realizar una copia de seguridad de la base de datos antes de la actualizaci\u00f3n. Los cambios necesarios en el esquema se llevan a cabo mediante el mecanismo de migraciones de IncidentRelay. Para una implementaci\u00f3n gradual de Event Orchestration, los desarrolladores recomiendan utilizar primero los modos shadow y hybrid, verificar los rastreos de ejecuci\u00f3n de las reglas y solo despu\u00e9s cambiar la orquestaci\u00f3n a modo active. \n Fuente: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"