{"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\/de\/blog\/news\/incidentrelay-2-0-release-on-call-scheduling-and-alert-routing-system","title":{"rendered":"Ver\u00f6ffentlichung von IncidentRelay 2.0, einem System zur Organisation von Schichten und zur Routen von Benachrichtigungen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Die Ver\u00f6ffentlichung von IncidentRelay 2.0 wurde bekannt gegeben, einem Open-Source-System zur Organisation von Bereitschaften, zur Routenplanung von Benachrichtigungen und zur Begleitung von Vorf\u00e4llen, das auf einem eigenen Server (self-hosted) betrieben werden kann. Das Projekt richtet sich an SRE-, DevOps- und Infrastruktur-Teams, die eine lokale Alternative zu cloudbasierten Bereitschaftsplattformen ben\u00f6tigen. Der Code ist in Python geschrieben und steht unter der MIT-Lizenz. <\/p>\n
IncidentRelay verarbeitet Ereignisse aus Prometheus Alertmanager, Grafana Alerting, Zabbix, Sentry, LibreNMS, RMON, AWS SNS\/CloudWatch, Datadog, Uptime Kuma und beliebigen Webhook-Handlern. Nach der Normalisierung wird das Ereignis mit dem Dienst, dem Team und der Rotation verkn\u00fcpft, Routing-Regeln und Eskalationsrichtlinien werden angewendet, bevor die Benachrichtigung an den aktuellen Bereitschaftsdienst gesendet wird. Die Lieferung erfolgt \u00fcber Mattermost, Slack, Telegram, Discord, Microsoft Teams, E-Mail, Webhook, Browser\/PWA Push und Voice Call-Anbieter. <\/p>\n
Die Hauptneuheit der Version 2.0 ist der Mechanismus zur Ereignis-Orchestrierung, der eine separate Verarbeitungsschicht zwischen eingehenden Integrationen und dem Lebenszyklus von Alerts bereitstellt. Die wesentlichen \u00c4nderungen sind: <\/p>\n
\n
Ein visueller Editor f\u00fcr Orchestrierungsregeln wurde hinzugef\u00fcgt. Regeln k\u00f6nnen global oder f\u00fcr einen einzelnen Dienst angewendet, in verschachtelte Bedingungen gruppiert und nacheinander hinsichtlich Priorit\u00e4t, Wichtigkeit, Labels, Team, Route, Gruppierungsweise sowie Benachrichtigungs- und Eskalationsrichtlinien ge\u00e4ndert werden;\n
Aktionen zum Unterdr\u00fccken, Verwerfen und Anhalten der Ereignisverarbeitung wurden implementiert, einschlie\u00dflich der Extraktion von Werten mittels regul\u00e4rer Ausdr\u00fccke und JSON Path, der Trennung von Strings, der Erstellung von Variablen und der Umwandlung von Werten;\n
Die Konfiguration der Orchestrierung ist in bearbeitbare Entw\u00fcrfe und unver\u00e4nderliche ver\u00f6ffentlichte Versionen unterteilt. Unterst\u00fctzung f\u00fcr Konfigurationspr\u00fcfung, Ver\u00f6ffentlichung, Rollback auf die vorherige Version und Hinzuf\u00fcgen von Kommentaren zu \u00c4nderungen wird geboten;\n
Es gibt die Modi disabled, shadow und active. Im shadow-Modus werden die Ergebnisse der Regelverarbeitung zur Analyse gespeichert, beeinflussen jedoch nicht das tats\u00e4chliche Routing. F\u00fcr die \u00dcbergangszeit sind die Kompatibilit\u00e4tsmodi legacy, hybrid und orchestration verf\u00fcgbar;\n
Es wurden Mittel zur Simulation und Wiederholung von Ereignissen hinzugef\u00fcgt. Diese erm\u00f6glichen die \u00dcberpr\u00fcfung der Regeln bei einem normalisierten Ereignis oder einem urspr\u00fcnglichen Payload der Integration, ohne einen echten Alarm zu erzeugen. F\u00fcr die Analyse der Ergebnisse stehen Ausf\u00fchrungs-Tracebacks, Explain-Daten und Metriken des Schattenmodus zur Verf\u00fcgung;\n
Es wurden wiederverwendbare Webhook-Aktionen implementiert, die asynchron nach der Verarbeitung eines Ereignisses ausgef\u00fchrt werden. Die Header werden verschl\u00fcsselt gespeichert, Geheimnisse werden in der API und in Protokollen verborgen, und der Zugriff auf private Netzwerke ist standardm\u00e4\u00dfig verboten. Timeout-Werte, Wiederholungen und eine Liste zul\u00e4ssiger interner Adressen k\u00f6nnen konfiguriert werden;\n
Die Integration mit Uptime Kuma wurde hinzugef\u00fcgt, die standardm\u00e4\u00dfige Webhook-Nachrichten \u00fcber den Status von Monitoren akzeptiert. Die Normalisierung der Zust\u00e4nde UP und DOWN, die Bestimmung der Wichtigkeit, das Handling von Tags und ein neuer Typ des eingehenden Pfades uptime_kuma wurden realisiert;\n
F\u00fcr Silenzen und geplante Wartungsfenster wurden die Parameter apply_to_existing und reactivate_on_end hinzugef\u00fcgt. Der erste erm\u00f6glicht die Anwendung von Suppressionen auf bereits offene Alarme, w\u00e4hrend der zweite festlegt, ob deren Verarbeitung nach dem Ende der Suppressionsperiode fortgesetzt werden soll. Benachrichtigungen, Erinnerungen und Eskalationsketten werden pausiert und wiederhergestellt;\n
F\u00fcr pers\u00f6nliche API-Token wurden separate Berechtigungen zum Lesen und \u00c4ndern von Gruppen, Teams, Benutzern, Routen, Kan\u00e4len, Diensten, Rotationen, Richtlinien, Wartungsfenstern, Heartbeat-Checks, SSO und Orchestrierungen eingef\u00fchrt. Alte aggregierte Berechtigungen resources:read, resources:write und * wurden zur R\u00fcckw\u00e4rtskompatibilit\u00e4t beibehalten;\n
Eine Schnittstelle f\u00fcr das Audit-Log mit Filterung und paginierter Ausgabe wurde hinzugef\u00fcgt. Im Log werden Operationen mit Orchestrierungen, Webhook-Aktionen, Silenzen und geplanten Wartungsfenstern erfasst, wobei vertrauliche Werte aus den angezeigten Daten entfernt werden;\n
Im Web-Interface gibt es jetzt ein dunkles Thema und benutzerdefinierte Einstellungen f\u00fcr Sprache und Layout. Die franz\u00f6sische Lokalisierung wurde hinzugef\u00fcgt, die \u00dcbersetzungen der Abschnitte Orchestrierung und Wartung wurden erweitert, und die Bearbeitung von SSO-Gruppenzuordnungsregeln wurde korrigiert;\n
Die Leistung von Heartbeat-Checks wurde verbessert: Es wird verhindert, dass Ereignisse \u00fcberf\u00e4llig wiederholt erstellt werden, das Wiederherstellen des Signals schlie\u00dft den Alarm korrekt und sendet eine Benachrichtigung \u00fcber die L\u00f6sung des Problems, das Format der Zeitstempel wurde vereinheitlicht;\n
Dokumentation zur Bereitstellung in Kubernetes mit Helm wurde vorbereitet. Im Helm-Chart wurde ein separater Handler f\u00fcr den Slack Socket Mode hinzugef\u00fcgt, der f\u00fcr die Funktionalit\u00e4t interaktiver Best\u00e4tigungs- und Schlie\u00dfbuttons von Vorf\u00e4llen erforderlich ist;\n
Der Schutz ausgehender HTTP-Anfragen, regul\u00e4rer Ausdr\u00fccke und vertraulicher Daten wurde verst\u00e4rkt, die Verarbeitung von UTC und Zeitzonen wurde zentralisiert, die Berechnungen f\u00fcr die Zeitpl\u00e4ne der Rotationen wurden \u00fcberarbeitet und die Abdeckung mit automatisierten Tests erweitert. <\/ul>\n
Vor dem Update wird empfohlen, eine Sicherung der Datenbank zu erstellen. Die erforderlichen \u00c4nderungen am Schema werden \u00fcber den Standard-Migrationsmechanismus von IncidentRelay durchgef\u00fchrt. F\u00fcr die schrittweise Einf\u00fchrung von Event Orchestration empfehlen die Entwickler zun\u00e4chst die Verwendung der Modi Shadow und Hybrid, die Ausf\u00fchrungstraces von Regeln zu \u00fcberpr\u00fcfen und erst danach die Orchestration auf den aktiven Modus umzustellen. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"