IncidentRelay 2.0, un système open source de gestion des astreintes, de routage des alertes et de réponse aux incidents, est désormais disponible. Il peut être déployé sur un serveur auto-hébergé. Ce projet s'adresse aux ingénieurs SRE, aux équipes DevOps et aux équipes d'infrastructure qui recherchent une alternative sur site aux plateformes de gestion des astreintes basées sur le cloud. Le code est écrit en Python et distribué sous licence MIT.
IncidentRelay reçoit les événements provenant de Prometheus Alertmanager, Grafana Alerting, Zabbix, Sentry, LibreNMS, RMON, AWS SNS/CloudWatch, Datadog, Uptime Kuma et des gestionnaires de webhooks personnalisés. Après normalisation, l'événement est associé à un service, une équipe et un système de rotation, les règles de routage et les politiques d'escalade sont appliquées, et une notification est envoyée au gestionnaire de permanence. Les méthodes de diffusion prises en charge incluent Mattermost, Slack, Telegram, Discord, Microsoft Teams, le courrier électronique, les webhooks, les notifications push navigateur/PWA et les fournisseurs d'appels vocaux.
La principale innovation de la version 2.0 réside dans le mécanisme d'orchestration des événements, qui fournit une couche de traitement des événements distincte entre les intégrations entrantes et le cycle de vie des alertes. Les principaux changements sont les suivants :
- Un éditeur visuel de règles d'orchestration a été ajouté. Les règles peuvent être appliquées globalement ou à un service spécifique, regroupées en groupes de conditions imbriqués et modifiées séquentiellement selon la priorité, le niveau de gravité, les étiquettes, la commande, la route, la méthode de regroupement, les politiques de notification et l'escalade.
- Actions mises en œuvre pour la suppression, l'abandon et la suspension du traitement des événements, l'extraction de valeurs à l'aide d'expressions régulières et de JSON Path, la division des chaînes, la création de variables et la conversion des valeurs ;
- La configuration d'orchestration est divisée en brouillons modifiables et en versions publiées immuables. La révision de la configuration, la publication, le retour à une version précédente et l'ajout de commentaires aux modifications sont pris en charge ;
- Les modes désactivé, fantôme et actif sont disponibles. En mode fantôme, les résultats d'exécution des règles sont stockés à des fins d'analyse, mais n'affectent pas le routage effectif. Les modes hérité, hybride et de compatibilité avec l'orchestration sont disponibles temporairement.
- Des outils de simulation et de relecture d'événements ont été ajoutés. Ils permettent de tester des règles sur un événement normalisé ou sur la charge utile d'intégration d'origine sans générer d'alerte réelle. Des traces d'exécution, des données d'explication et des indicateurs en mode fantôme sont fournis pour analyser les résultats.
- Des actions webhook réutilisables sont implémentées et exécutées de manière asynchrone après le traitement de l'événement. Les en-têtes sont chiffrés, les secrets sont masqués dans l'API et les journaux, et l'accès aux réseaux privés est interdit par défaut. Les délais d'attente, les tentatives de reconnexion et la liste des adresses internes autorisées sont configurables.
- Intégration ajoutée avec Uptime Kuma, qui accepte les messages webhook standard relatifs à l'état du système de surveillance. La normalisation des états « En service » et « En panne », la détection de l'importance des messages, le traitement des balises et un nouveau type de route entrant, uptime_kuma, ont été implémentés.
- Les paramètres apply_to_existing et reactivate_on_end ont été ajoutés aux silences et aux fenêtres de travail planifiées. Le premier applique la suppression aux alertes déjà ouvertes, tandis que le second détermine s'il faut reprendre leur traitement après la fin de la période de suppression. Les notifications, les rappels et les chaînes d'escalade sont suspendus et rétablis ;
- Pour les jetons d'API personnels, des autorisations de lecture et de modification distinctes ont été introduites pour les groupes, les équipes, les utilisateurs, les routes, les canaux, les services, les rotations, les politiques, les fenêtres de maintenance, les contrôles de disponibilité, l'authentification unique (SSO) et les orchestrations. Les anciennes autorisations agrégées de lecture et d'écriture des ressources (resources:read, resources:write, *) ont été conservées pour assurer la compatibilité avec les versions précédentes.
- Une interface de journalisation des audits avec filtrage et pagination a été ajoutée. Le journal enregistre les opérations impliquant des orchestrations, des webhooks, des mises en veille et des fenêtres de travail planifiées, les données sensibles étant masquées.
- L'interface web propose désormais un thème sombre et des paramètres de langue et de design personnalisables. La localisation française a été ajoutée, les traductions des sections orchestration et maintenance ont été enrichies et l'édition des règles de correspondance des groupes SSO a été améliorée.
- Amélioration des contrôles de pulsation : suppression de la création répétée d'événements en retard, la récupération du signal ferme correctement l'alerte et envoie une notification indiquant que le problème est résolu, et la présentation des horodatages a été normalisée ;
- La documentation relative au déploiement de Kubernetes avec Helm est disponible. Un gestionnaire Slack Socket Mode dédié a été ajouté au graphique Helm ; il est nécessaire pour les boutons interactifs de confirmation et de clôture des incidents.
- Nous avons renforcé la sécurité des requêtes HTTP sortantes, des expressions régulières et des données sensibles, centralisé la gestion de l'UTC et des fuseaux horaires, retravaillé les calculs des calendriers de rotation et étendu la couverture des tests automatisés.
Avant la mise à niveau, il est recommandé de créer une sauvegarde de la base de données. Les modifications de schéma nécessaires sont effectuées à l'aide du mécanisme de migration intégré d'IncidentRelay. Pour une implémentation progressive de l'orchestration d'événements, les développeurs recommandent d'utiliser d'abord les modes fantôme et hybride, de vérifier les traces d'exécution des règles, puis de passer en mode actif.
Source: opennet.ru
