{"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\/da\/blog\/news\/incidentrelay-2-0-release-on-call-scheduling-and-alert-routing-system","title":{"rendered":"Udgivelsen af IncidentRelay 2.0, et system til organisering af vagtplanl\u00e6gning og ruteopdeling af alarmer","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Udgivelsen af projektet IncidentRelay 2.0, der udvikler et \u00e5bent system til organisering af vagter, routing af meddelelser og h\u00e5ndtering af h\u00e6ndelser, der implementeres p\u00e5 en selv-hosted server. Projektet er rettet mod SRE, DevOps og infrastrukturteams, der har brug for et lokalt alternativ til cloud-baserede vagtstyringsplatforme. Koden er skrevet i Python og distribueres under MIT-licensen. <\/p>\n
IncidentRelay modtager h\u00e6ndelser fra Prometheus Alertmanager, Grafana Alerting, Zabbix, Sentry, LibreNMS, RMON, AWS SNS\/CloudWatch, Datadog, Uptime Kuma og vilk\u00e5rlige webhook-behandlere. Efter normalisering forbindes h\u00e6ndelsen med tjenesten, holdet og rotationen, og der anvendes routingregler og eskaleringspolitikker, hvorefter meddelelsen sendes til den aktuelle vagt. Levering underst\u00f8tter Mattermost, Slack, Telegram, Discord, Microsoft Teams, email, webhook, browser\/PWA push og udbydere af telefonopkald. <\/p>\n
Den st\u00f8rste nyhed i version 2.0 er Event Orchestration-mekanismen, der giver et separat lag til behandling af h\u00e6ndelser mellem de indg\u00e5ende integrationer og livscyklussen for advarsler. De vigtigste \u00e6ndringer: <\/p>\n
\n
Der er tilf\u00f8jet en visuel editor til orkestreringsregler. Regler kan anvendes globalt eller til en bestemt tjeneste, samles i indlejrede betingelsesgrupper og \u00e6ndre prioriteter, vigtighedsniveauer, etiketter, hold, ruter, grupperingsmetoder, meddelelses- og eskaleringspolitikker i r\u00e6kkef\u00f8lge;\n
Der er implementeret handlinger til nedtoning, forkastelse og pause af behandling af h\u00e6ndelser, udtr\u00e6kning af v\u00e6rdier ved hj\u00e6lp af regul\u00e6re udtryk og JSON Path, opdeling af strenge, oprettelse af variabler og transformation af v\u00e6rdier;\n
Orkestreringskonfigurationen er opdelt i redigerbare kladder og uforanderlige publicerede versioner. Der underst\u00f8ttes konfigurationskontrol, offentligg\u00f8relse, tilbagevenden til en tidligere version og tilf\u00f8jelse af kommentarer til \u00e6ndringer;\n
Der er forudset tilstande for disabled, shadow og active. I shadow-tilstand gemmes resultaterne af regeludf\u00f8relse til analyse, men p\u00e5virker ikke den reelle routing. For overgangsperioden er tilstandene legacy, hybrid og orchestration tilg\u00e6ngelige;\n
Der er tilf\u00f8jet simulerings- og genafspilningsv\u00e6rkt\u00f8jer. De giver mulighed for at teste regler p\u00e5 et normaliseret begivenhed eller den oprindelige payload for integration uden at generere en faktisk alert. For analyse af resultaterne tilbydes udf\u00f8relsessporing, Explain-data og metrics i shadow mode;\n
Der er implementeret genanvendelige webhook-handlinger, der udf\u00f8res asynkront efter behandling af begivenheden. Overskrifter opbevares krypteret, hemmeligheder skjules i API'en og logfilerne, og adgang til private netv\u00e6rk er som standard forbudt. Timeout, genfors\u00f8g og en liste over tilladte interne adresser kan konfigureres;\n
Integration med Uptime Kuma er tilf\u00f8jet, som modtager standard webhook-beskeder om tilstanden af monitorer. Der er implementeret normalisering af tilstande UP og DOWN, bestemmelse af betydning, behandling af tags og en ny type indkommende rute uptime_kuma;\n
For silences og planlagte vedligeholdelsesvinduer er der tilf\u00f8jet parametrene apply_to_existing og reactivate_on_end. Den f\u00f8rste g\u00f8r det muligt at anvende undertrykkelse p\u00e5 allerede \u00e5bne alarmer, mens den anden bestemmer, om behandlingen af dem skal genoptages efter afslutningen af undertrykkelsesperioden. Underretninger, p\u00e5mindelser og eskalationsk\u00e6der bliver suspenderet og genoprettet;\n
Der er indf\u00f8rt separate rettigheder til l\u00e6sning og \u00e6ndring af grupper, teams, brugere, ruter, kanaler, tjenester, rotationer, politikker, vedligeholdelsesvinduer, heartbeat-kontroller, SSO og orkestreringer for personlige API-tokens. De gamle aggregaterettigheder resources:read, resources:write og * er bevaret for bagudkompatibilitet;\n
Der er tilf\u00f8jet et auditlog-interface med filtrering og paginering. Loggen registrerer operationer med orkestreringer, webhook-handlinger, silences og vedligeholdelsesvinduer, mens fortrolige v\u00e6rdier fjernes fra de viste data;\n
Den webbaserede gr\u00e6nseflade har f\u00e5et en m\u00f8rk tema og brugerdefinerede indstillinger for sprog og tema. Fransk lokalisering er tilf\u00f8jet, overs\u00e6ttelserne for orkestrerings- og serviceafsnit er udvidet, og redigeringen af SSO gruppebindingsregler er blevet rettet;\n
Ydelsen af heartbeat-kontroller er forbedret: gentagelse af begivenheder om forfald er udelukket, genoprettelse af signal lukker korrekt alarmen og sender en meddelelse om, at problemet er l\u00f8st, og visningen af tidsstempler er blevet ensartet;\n
Dokumentationen til implementering i Kubernetes ved hj\u00e6lp af Helm er blevet forberedt. En separat Slack Socket Mode-h\u00e5ndtering er tilf\u00f8jet i Helm-chartet, hvilket er n\u00f8dvendigt for at aktivere interaktive knapper til bekr\u00e6ftelse og afslutning af h\u00e6ndelser;\n
Beskyttelsen af udg\u00e5ende HTTP-anmodninger, regul\u00e6re udtryk og fortrolige data er blevet styrket; central behandling af UTC og tidszoner er blevet implementeret, beregningerne af rotationsplaner er revideret, og d\u00e6kningen med automatiserede tests er blevet udvidet. <\/ul>\n
Det anbefales at tage en sikkerhedskopi af databasen f\u00f8r opdatering. De n\u00f8dvendige skem\u00e6ndringer udf\u00f8res af IncidentRelay's standard migrationsmekanisme. For en gradvis implementering anbefaler udviklerne f\u00f8rst at bruge shadow- og hybridtilstande, kontrollere sporene af regeludf\u00f8relser og f\u00f8rst derefter skifte orkestreringen til aktiv tilstand. \n Kilde: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"