Erste stabile Version von IncidentRelay, einem System zur Organisation von Bereitschaftsdiensten und Routing von Benachrichtigungen

Nach fünf Monaten Entwicklung wurde die Version 1.1 des Projekts IncidentRelay veröffentlicht, das ein offenes System zur Organisation von Bereitschaften, zur Routenführung von Benachrichtigungen und zur Unterstützung von Vorfällen bereitstellt, das auf einem eigenen Server (Self-Hosted) läuft. IncidentRelay 1.1 wird als erste stabile Version ausgezeichnet (die Version 1.0 hatte den Status einer Beta-Version). Das Projekt richtet sich an SRE-, DevOps- und Infrastrukturteams, die eine lokal bereitzustellende Alternative zu SaaS-Diensten für das Management von Bereitschaften (On-Call Management), die Anwendung von Eskalationsrichtlinien und die Reaktion auf Vorfälle benötigen. Der Code des Projekts ist in Python geschrieben und wird unter der MIT-Lizenz vertrieben.

IncidentRelay empfängt Ereignisse von Überwachungssystemen, ordnet sie einem Dienst, einem Team und einer Rotation zu und sendet dann Benachrichtigungen an die zuständigen Bereitschaftsdienste oder Teams. Im System sind Bereitschaftszeiten, Rotation, Übersteuerungen von Schichten, Bestätigungen des Eingangs eines Vorfalls, Status-ACK/Resolve, Erinnerungen, Eskalationen, vorübergehende Vertretungen von Bereitschaftsdiensten, die Festlegung von Zeitfenstern für geplante Arbeiten und die Unterdrückung von lauten Alarmen implementiert.

Der Hauptvorteil des Projekts ist die vollständige Kontrolle über die Infrastruktur und die Logik der Routenführung. IncidentRelay wird in seiner eigenen Umgebung bereitgestellt, arbeitet mit seiner eigenen Datenbank und ermöglicht eine eindeutige Trennung der eingehenden Routen, Teams, Rotation und Zustellungskanäle. Eingehende Tokens gehören den Routen und nicht den Kanälen, was es einfacher macht, zu verstehen, welche externe Quelle das Recht hat, Ereignisse an ein bestimmtes Team zu senden.

In IncidentRelay wird der Empfang von Ereignissen aus Prometheus Alertmanager, Grafana Alerting, Zabbix, Sentry, LibreNMS, RMON, AWS SNS/CloudWatch und beliebigen Webhooks unterstützt. Für den Versand von Benachrichtigungen sind die Kanäle Mattermost, Slack, Telegram, Discord, Microsoft Teams, E-Mail, Webhooks, Browser/PWA Push und Anbieter für Sprachaufrufe vorgesehen. In Mattermost und Telegram können die Benachrichtigungen Aktionen zum Bestätigen und Lösen des Problems enthalten, was es ermöglicht, einen Vorfall zu bearbeiten, ohne zu einer separaten Schnittstelle wechseln zu müssen.

Das Projekt kann über Docker Compose, RPM-Paket für Red Hat-ähnliche Distributionen, manuell über systemd und auch in Kubernetes mit einem Helm-Chart gestartet werden. Für kleine Installationen kann SQLite verwendet werden, für produktive Systeme und höhere Lasten wird PostgreSQL empfohlen.

In der neuen Version wurden folgende Änderungen vorgeschlagen:

• Es wurden mehrstufige On-Call-Rotationen mit zeitlichen Einschränkungen, Prioritäten der Ebenen und Berücksichtigung von temporären Vertretungen hinzugefügt;
• Ein Dienstkalender, CalDAV- und ICS-Abonnements für externe Kalender sind verfügbar;
• Es wurden Eskalationsrichtlinien für Vorfälle mit mehrstufigen Anpassungsoptionen implementiert;
• Es wurden Warnungsgruppen, Ereignisgruppen, verzögerte Benachrichtigungen und manuelle Zusammenführungen verwandter Warnungen hinzugefügt;
• Fenster für geplante Wartungsarbeiten und "stille" Warnungen sind verfügbar;
• Die Möglichkeit, Kommentare zu Warnungen hinzuzufügen, wurde implementiert;
• Es wurden Prioritäten für Vorfälle (P1-P5) und eine automatische Anhebung der Priorität basierend auf der Wichtigkeit hinzugefügt;
• Ein Servicekatalog, Abhängigkeiten der Dienste, SLI/SLO, die Historie der Auswirkungen auf die Systemleistung (Service Impact History) und Geschäftsdienste (Business Services) wurden implementiert;
• Explain Trace zur Analyse der Weiterleitung: warum eine Warnung ins Team gelangt ist oder nicht, gruppiert, unterdrückt oder in einen bestimmten Kanal gesendet wurde, ist verfügbar;
• Überprüfungen (Heartbeats/dead-man-switch) für Watchdog, Backup, ETL und andere Aufgaben, bei denen das Fehlen eines erwarteten Signals ein Problem darstellt, wurden hinzugefügt.

Quelle: opennet.ru