Na vijf maanden ontwikkeling is de release van het IncidentRelay-project 1.1 gepubliceerd, dat een open systeem ontwikkelt voor het organiseren van diensten, het routeren van meldingen en het beheren van incidenten, dat op een eigen server (zelf-gehost) kan worden uitgevoerd. IncidentRelay 1.1 wordt gemarkeerd als de eerste stabiele release (de 1.0-tak had de status van een bètaversie). Het project is gericht op SRE, DevOps en infrastructuurteams die een lokaal te implementeren alternatief voor SaaS-services voor on-call management, escalatiebeleid en incidentrespons nodig hebben. De code van het project is geschreven in Python en wordt verspreid onder de MIT-licentie.
IncidentRelay ontvangt gebeurtenissen van monitorsystemen, koppelt deze aan een service, team en rotatie, en levert vervolgens meldingen aan de verantwoordelijke oproepmedewerkers of teams. Het systeem ondersteunt dienstroosters, rotaties, overschrijving van diensten, bevestiging van de ontvangst van een incident, ACK/Resolve-statussen, herinneringen, escalaties, tijdelijke vervangingen van oproepmedewerkers, het bepalen van de tijd voor gepland onderhoud en het onderdrukken van ruisende waarschuwingen.
Het belangrijkste voordeel van het project is de volledige controle over de infrastructuur en de logica van de routering. IncidentRelay wordt geïmplementeerd in zijn eigen omgeving, werkt met een eigen database en maakt het mogelijk om inkomende routes, teams, rotaties en afleverkanalen duidelijk te scheiden. Inkomende tokens behoren tot routes en niet tot kanalen, waardoor het eenvoudiger is om te begrijpen welke externe bron toestemming heeft om gebeurtenissen naar een specifiek team te sturen.
IncidentRelay ondersteunt het ontvangen van gebeurtenissen van Prometheus Alertmanager, Grafana Alerting, Zabbix, Sentry, LibreNMS, RMON, AWS SNS/CloudWatch en willekeurige webhook-interfaces. Voor het verzenden van meldingen zijn kanalen zoals Mattermost, Slack, Telegram, Discord, Microsoft Teams, e-mail, webhooks, browser/PWA push en providers voor spraakoproepen beschikbaar. In Mattermost en Telegram kunnen meldingen acties bevatten voor bevestiging en probleemoplossing, zodat incidenten kunnen worden afgehandeld zonder over te schakelen naar een aparte interface.
Het project kan worden uitgevoerd via Docker Compose, een RPM-pakket voor Red Hat-achtige distributies, handmatig via systemd, en in Kubernetes met behulp van een Helm-chart. Voor kleinere installaties kan SQLite worden gebruikt; voor productiesystemen en hogere belasting wordt PostgreSQL aanbevolen.
De nieuwe versie biedt de volgende wijzigingen:
- Er zijn meerlaags on-call rotaties toegevoegd met tijdslimieten, prioriteiten van lagen en rekening houdend met tijdelijke vervangingen;
- Er is een aanwezigheidskalender, CalDAV en ICS-abonnementen voor externe agenda's toegevoegd;
- Incidenten escalatiebeleid met meerfasige ketens van niveaus is geïmplementeerd;
- Waarschuwingsgroepen, gebeurtenisgroepering, uitgestelde meldingen en handmatige samenvoeging van gerelateerde meldingen zijn toegevoegd;
- Er zijn vensters voor geplande werkzaamheden en 'stille' meldingen toegevoegd;
- De mogelijkheid om opmerkingen aan meldingen toe te voegen is toegevoegd;
- Er zijn prioriteiten voor incidenten (P1-P5) en automatische verhoging van prioriteiten op basis van belangrijkheid geïmplementeerd;
- Er is een servicecatalogus, afhankelijkheden van services, SLI/SLO, invloedsgeschiedenis op systeemoperaties (Service Impact History) en bedrijfsservices (Business Services) geïmplementeerd;
- Explain Trace is toegevoegd voor het analyseren van routering: waarom een melding is opgenomen of niet is opgenomen in het team, gegroepeerd, onderdrukt of naar een specifiek kanaal is verzonden;
- Er zijn controles (Heartbeats/dead-man-switch) toegevoegd voor watchdog, backup, ETL en andere taken waar het probleem ligt in het ontbreken van een verwachte signaal.
Bron: opennet.ru
