{"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\/fr\/blog\/news\/incidentrelay-2-0-release-on-call-scheduling-and-alert-routing-system","title":{"rendered":"Sortie d'IncidentRelay 2.0, un syst\u00e8me pour l'organisation des gardes et le routage des alertes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
La version 2.0 du projet IncidentRelay a \u00e9t\u00e9 publi\u00e9e, d\u00e9veloppant un syst\u00e8me open source pour l'organisation des astreintes, le routage des alertes et le suivi des incidents, d\u00e9ployable sur un serveur local (auto-h\u00e9berg\u00e9). Le projet est destin\u00e9 aux \u00e9quipes SRE, DevOps et infrastructures qui recherchent une alternative locale aux plateformes de gestion des astreintes bas\u00e9es sur le cloud. Le code est \u00e9crit en Python et distribu\u00e9 sous la licence MIT. <\/p>\n
IncidentRelay re\u00e7oit des \u00e9v\u00e9nements de Prometheus Alertmanager, Grafana Alerting, Zabbix, Sentry, LibreNMS, RMON, AWS SNS\/CloudWatch, Datadog, Uptime Kuma et de n'importe quel gestionnaire de webhook. Apr\u00e8s normalisation, l'\u00e9v\u00e9nement est associ\u00e9 \u00e0 un service, une \u00e9quipe et une rotation, des r\u00e8gles de routage et des politiques d'escalade lui sont appliqu\u00e9es, puis la notification est envoy\u00e9e \u00e0 l'astreint actuel. Pour la livraison, les supports incluent Mattermost, Slack, Telegram, Discord, Microsoft Teams, email, webhook, notifications push pour navigateur\/PWA et fournisseurs d'appels vocaux. <\/p>\n
La principale nouveaut\u00e9 de la version 2.0 est le m\u00e9canisme d'orchestration des \u00e9v\u00e9nements, fournissant une couche distincte de traitement des \u00e9v\u00e9nements entre les int\u00e9grations entrantes et le cycle de vie de l'alerte. Les modifications principales : <\/p>\n
\n
Ajout d'un \u00e9diteur visuel pour les r\u00e8gles d'orchestration. Les r\u00e8gles peuvent \u00eatre appliqu\u00e9es globalement ou \u00e0 un service sp\u00e9cifique, regroup\u00e9es en groupes de conditions imbriqu\u00e9s et modifier successivement la priorit\u00e9, le niveau d\u2019importance, les \u00e9tiquettes, l\u2019\u00e9quipe, le route, la m\u00e9thode de regroupement, ainsi que les politiques de notification et d'escalade.\n
Mise en place d'actions pour supprimer, ignorer et suspendre le traitement des \u00e9v\u00e9nements, extraire des valeurs \u00e0 l'aide d'expressions r\u00e9guli\u00e8res et de JSON Path, d\u00e9composer des cha\u00eenes, cr\u00e9er des variables et transformer des valeurs.\n
La configuration d'orchestration est divis\u00e9e en brouillons \u00e9ditables et versions publi\u00e9es immuables. La v\u00e9rification de la configuration, la publication, le retour \u00e0 une version pr\u00e9c\u00e9dente et l'ajout de commentaires sur les modifications sont pris en charge.\n
Les modes disabled, shadow et active sont pr\u00e9vus. En mode shadow, les r\u00e9sultats des r\u00e8gles sont enregistr\u00e9s pour analyse, mais n'affectent pas le routage r\u00e9el. Des modes de compatibilit\u00e9 legacy, hybrid et orchestration sont disponibles pour la p\u00e9riode de transition.\n
Des outils de simulation et de reproduction d'\u00e9v\u00e9nements ont \u00e9t\u00e9 ajout\u00e9s. Ils permettent de v\u00e9rifier les r\u00e8gles sur un \u00e9v\u00e9nement normalis\u00e9 ou sur le payload d'origine de l'int\u00e9gration sans cr\u00e9er d'alerte r\u00e9elle. Pour l'analyse des r\u00e9sultats, une trace d'ex\u00e9cution, des donn\u00e9es Explain et des m\u00e9triques de mode shadow sont fournies;\n
Des actions webhook r\u00e9utilisables, ex\u00e9cut\u00e9es de mani\u00e8re asynchrone apr\u00e8s le traitement de l'\u00e9v\u00e9nement, ont \u00e9t\u00e9 mises en \u0153uvre. Les en-t\u00eates sont stock\u00e9s sous forme chiffr\u00e9e, les secrets sont masqu\u00e9s dans l'API et les journaux, et l'acc\u00e8s aux r\u00e9seaux priv\u00e9s est par d\u00e9faut interdit. Des d\u00e9lais d'attente, des tentatives de r\u00e9p\u00e9tition et une liste des adresses internes autoris\u00e9es peuvent \u00eatre configur\u00e9s;\n
Une int\u00e9gration avec Uptime Kuma a \u00e9t\u00e9 ajout\u00e9e, acceptant les messages webhook standard sur l'\u00e9tat des moniteurs. La normalisation des \u00e9tats UP et DOWN, la d\u00e9termination de l'importance, le traitement des \u00e9tiquettes et un nouveau type de route d'entr\u00e9e uptime_kuma ont \u00e9t\u00e9 mis en \u0153uvre;\n
Pour les silences et les fen\u00eatres de maintenance, les param\u00e8tres apply_to_existing et reactivate_on_end ont vu le jour. Le premier permet d'appliquer un silence aux alertes d\u00e9j\u00e0 ouvertes, et le second d\u00e9termine s'il faut reprendre leur traitement apr\u00e8s la fin de la p\u00e9riode de silence. Les notifications, rappels et cha\u00eenes d'escalade sont suspendus et restaur\u00e9s;\n
Pour les jetons API personnels, des droits de lecture et de modification s\u00e9par\u00e9s pour les groupes, \u00e9quipes, utilisateurs, routes, canaux, services, rotations, politiques, fen\u00eatres de maintenance, v\u00e9rifications heartbeat, SSO et orchestrations ont \u00e9t\u00e9 introduits. Les anciens droits agr\u00e9g\u00e9s resources:read, resources:write et * sont conserv\u00e9s pour la compatibilit\u00e9 ascendante;\n
Une interface de journal de contr\u00f4le a \u00e9t\u00e9 ajout\u00e9e avec filtration et pagination. Le journal enregistre les op\u00e9rations li\u00e9es aux orchestrations, actions webhook, silences et fen\u00eatres de maintenance, avec des valeurs sensibles effac\u00e9es des donn\u00e9es affich\u00e9es;\n
Une th\u00e9matique sombre et des r\u00e9glages personnalis\u00e9s de langue et de pr\u00e9sentation sont d\u00e9sormais disponibles dans l'interface web. La localisation fran\u00e7aise a \u00e9t\u00e9 ajout\u00e9e, les traductions des sections d'orchestration et de maintenance ont \u00e9t\u00e9 \u00e9tendues, et l'\u00e9dition des r\u00e8gles de correspondance des groupes SSO a \u00e9t\u00e9 corrig\u00e9e;\n
Le fonctionnement des v\u00e9rifications heartbeat a \u00e9t\u00e9 am\u00e9lior\u00e9 : la recr\u00e9ation d'\u00e9v\u00e9nements de d\u00e9passement a \u00e9t\u00e9 \u00e9vit\u00e9e, la restauration du signal ferme correctement l'alerte et envoie une notification de r\u00e9solution, et la pr\u00e9sentation des horodatages a \u00e9t\u00e9 unifi\u00e9e;\n
La documentation pour le d\u00e9ploiement dans Kubernetes \u00e0 l'aide de Helm a \u00e9t\u00e9 pr\u00e9par\u00e9e. Un gestionnaire distinct pour Slack Socket Mode a \u00e9t\u00e9 ajout\u00e9 au chart Helm, n\u00e9cessaire au fonctionnement des boutons interactifs de confirmation et de fermeture des incidents ;\n
La protection des requ\u00eates HTTP sortantes, des expressions r\u00e9guli\u00e8res et des donn\u00e9es sensibles a \u00e9t\u00e9 renforc\u00e9e, le traitement des UTC et des fuseaux horaires a \u00e9t\u00e9 centralis\u00e9, les calculs des horaires de rotation ont \u00e9t\u00e9 retravaill\u00e9s et la couverture par des tests automatiques a \u00e9t\u00e9 \u00e9largie. <\/ul>\n
Avant la mise \u00e0 jour, il est recommand\u00e9 de cr\u00e9er une sauvegarde de la base de donn\u00e9es. Les modifications n\u00e9cessaires \u00e0 la structure sont effectu\u00e9es par le m\u00e9canisme standard de migrations d'IncidentRelay. Pour une mise en \u0153uvre progressive de l'orchestration des \u00e9v\u00e9nements, les d\u00e9veloppeurs recommandent d'abord d'utiliser les modes shadow et hybrid, de v\u00e9rifier les traces d'ex\u00e9cution des r\u00e8gles, et seulement apr\u00e8s cela de basculer l'orchestration en mode actif. \n Source : opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"