La version 2.0 du projet IncidentRelay a été publiée, développant un système open source pour l'organisation des astreintes, le routage des alertes et le suivi des incidents, déployable sur un serveur local (auto-hébergé). Le projet est destiné aux équipes SRE, DevOps et infrastructures qui recherchent une alternative locale aux plateformes de gestion des astreintes basées sur le cloud. Le code est écrit en Python et distribué sous la licence MIT.
IncidentRelay reçoit des événements de Prometheus Alertmanager, Grafana Alerting, Zabbix, Sentry, LibreNMS, RMON, AWS SNS/CloudWatch, Datadog, Uptime Kuma et de n'importe quel gestionnaire de webhook. Après normalisation, l'événement est associé à un service, une équipe et une rotation, des règles de routage et des politiques d'escalade lui sont appliquées, puis la notification est envoyée à 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.
La principale nouveauté de la version 2.0 est le mécanisme d'orchestration des événements, fournissant une couche distincte de traitement des événements entre les intégrations entrantes et le cycle de vie de l'alerte. Les modifications principales :
- Ajout d'un éditeur visuel pour les règles d'orchestration. Les règles peuvent être appliquées globalement ou à un service spécifique, regroupées en groupes de conditions imbriqués et modifier successivement la priorité, le niveau d’importance, les étiquettes, l’équipe, le route, la méthode de regroupement, ainsi que les politiques de notification et d'escalade.
- Mise en place d'actions pour supprimer, ignorer et suspendre le traitement des événements, extraire des valeurs à l'aide d'expressions régulières et de JSON Path, décomposer des chaînes, créer des variables et transformer des valeurs.
- La configuration d'orchestration est divisée en brouillons éditables et versions publiées immuables. La vérification de la configuration, la publication, le retour à une version précédente et l'ajout de commentaires sur les modifications sont pris en charge.
- Les modes disabled, shadow et active sont prévus. En mode shadow, les résultats des règles sont enregistrés pour analyse, mais n'affectent pas le routage réel. Des modes de compatibilité legacy, hybrid et orchestration sont disponibles pour la période de transition.
- Des outils de simulation et de reproduction d'événements ont été ajoutés. Ils permettent de vérifier les règles sur un événement normalisé ou sur le payload d'origine de l'intégration sans créer d'alerte réelle. Pour l'analyse des résultats, une trace d'exécution, des données Explain et des métriques de mode shadow sont fournies;
- Des actions webhook réutilisables, exécutées de manière asynchrone après le traitement de l'événement, ont été mises en œuvre. Les en-têtes sont stockés sous forme chiffrée, les secrets sont masqués dans l'API et les journaux, et l'accès aux réseaux privés est par défaut interdit. Des délais d'attente, des tentatives de répétition et une liste des adresses internes autorisées peuvent être configurés;
- Une intégration avec Uptime Kuma a été ajoutée, acceptant les messages webhook standard sur l'état des moniteurs. La normalisation des états UP et DOWN, la détermination de l'importance, le traitement des étiquettes et un nouveau type de route d'entrée uptime_kuma ont été mis en œuvre;
- Pour les silences et les fenêtres de maintenance, les paramètres apply_to_existing et reactivate_on_end ont vu le jour. Le premier permet d'appliquer un silence aux alertes déjà ouvertes, et le second détermine s'il faut reprendre leur traitement après la fin de la période de silence. Les notifications, rappels et chaînes d'escalade sont suspendus et restaurés;
- Pour les jetons API personnels, des droits de lecture et de modification séparés pour les groupes, équipes, utilisateurs, routes, canaux, services, rotations, politiques, fenêtres de maintenance, vérifications heartbeat, SSO et orchestrations ont été introduits. Les anciens droits agrégés resources:read, resources:write et * sont conservés pour la compatibilité ascendante;
- Une interface de journal de contrôle a été ajoutée avec filtration et pagination. Le journal enregistre les opérations liées aux orchestrations, actions webhook, silences et fenêtres de maintenance, avec des valeurs sensibles effacées des données affichées;
- Une thématique sombre et des réglages personnalisés de langue et de présentation sont désormais disponibles dans l'interface web. La localisation française a été ajoutée, les traductions des sections d'orchestration et de maintenance ont été étendues, et l'édition des règles de correspondance des groupes SSO a été corrigée;
- Le fonctionnement des vérifications heartbeat a été amélioré : la recréation d'événements de dépassement a été évitée, la restauration du signal ferme correctement l'alerte et envoie une notification de résolution, et la présentation des horodatages a été unifiée;
- La documentation pour le déploiement dans Kubernetes à l'aide de Helm a été préparée. Un gestionnaire distinct pour Slack Socket Mode a été ajouté au chart Helm, nécessaire au fonctionnement des boutons interactifs de confirmation et de fermeture des incidents ;
- La protection des requêtes HTTP sortantes, des expressions régulières et des données sensibles a été renforcée, le traitement des UTC et des fuseaux horaires a été centralisé, les calculs des horaires de rotation ont été retravaillés et la couverture par des tests automatiques a été élargie.
Avant la mise à jour, il est recommandé de créer une sauvegarde de la base de données. Les modifications nécessaires à la structure sont effectuées par le mécanisme standard de migrations d'IncidentRelay. Pour une mise en œuvre progressive de l'orchestration des événements, les développeurs recommandent d'abord d'utiliser les modes shadow et hybrid, de vérifier les traces d'exécution des règles, et seulement après cela de basculer l'orchestration en mode actif.
Source : opennet.ru
