È stato pubblicato il rilascio del progetto IncidentRelay 2.0, che sviluppa un sistema aperto per l'organizzazione dei turni, la gestione delle notifiche e il supporto agli incidenti, da implementare su un server proprio (self-hosted). Il progetto è orientato a team SRE, DevOps e infrastrutturali che necessitano di un'alternativa locale alle piattaforme di gestione dei turni basate sul cloud. Il codice è scritto in Python e distribuito sotto licenza MIT.
IncidentRelay accetta eventi da Prometheus Alertmanager, Grafana Alerting, Zabbix, Sentry, LibreNMS, RMON, AWS SNS/CloudWatch, Datadog, Uptime Kuma e gestori webhook arbitrari. Dopo la normalizzazione, l'evento viene associato a un servizio, a un team e a una rotazione; vengono applicate regole di instradamento e politiche di escalation, dopodiché la notifica viene inviata al turno attuale. Per la consegna sono supportati Mattermost, Slack, Telegram, Discord, Microsoft Teams, email, webhook, browser/PWA push e fornitori di chiamate vocali.
La principale novità della versione 2.0 è il meccanismo di Event Orchestration, che fornisce uno strato separato di elaborazione degli eventi tra le integrazioni in ingresso e il ciclo di vita dell'allerta. Le modifiche principali includono:
- È stato aggiunto un editor visivo per le regole di orchestrazione. Le regole possono essere applicate globalmente o a un singolo servizio, essere raggruppate in condizioni annidate e modificare sequenzialmente la priorità, il livello di importanza, le etichette, il team, il percorso, il metodo di raggruppamento, le politiche di notifica e di escalation.
- Sono state implementate azioni per sopprimere, scartare e sospendere l'elaborazione degli eventi, estrarre valori utilizzando espressioni regolari e JSON Path, dividere stringhe, creare variabili e trasformare valori.
- La configurazione dell'orchestrazione è divisa in bozze modificabili e versioni pubblicate immutabili. Sono supportate verifica della configurazione, pubblicazione, ripristino a una versione precedente e aggiunta di commenti alle modifiche.
- Sono previsti i modalità disabilitato, shadow e attivo. In modalità shadow i risultati dell'esecuzione delle regole vengono salvati per l'analisi, ma non influenzano l'instradamento reale. Per il periodo di transizione sono disponibili le modalità di compatibilità legacy, hybrid e orchestration.
- Sono stati aggiunti strumenti di simulazione e riproduzione degli eventi. Questi permettono di testare le regole su un evento normalizzato o su un payload originale dell'integrazione senza generare un vero alert. Per analizzare i risultati sono forniti tracciamento dell'esecuzione, dati di spiegazione e metriche della modalità shadow;
- Sono state implementate azioni webhook riutilizzabili che vengono eseguite in modo asincrono dopo l'elaborazione dell'evento. Le intestazioni sono memorizzate in forma cifrata, i segreti sono nascosti nell'API e nei registri, e gli accessi alle reti private sono di default vietati. È possibile configurare timeout, tentativi di ripetizione e un elenco di indirizzi interni autorizzati;
- È stata aggiunta l'integrazione con Uptime Kuma, che riceve messaggi webhook standard sullo stato dei monitor. Sono state implementate la normalizzazione degli stati UP e DOWN, la determinazione dell'importanza, la gestione dei tag e un nuovo tipo di percorso in entrata uptime_kuma;
- Per le silenzi e le finestre di manutenzione sono stati introdotti i parametri apply_to_existing e reactivate_on_end. Il primo consente di applicare il silenziamento ad alert già aperti, mentre il secondo definisce se riprendere l'elaborazione dopo la fine del periodo di silenziamento. Le notifiche, i promemoria e le catene di escalation vengono sospesi e ripristinati;
- Per i token API personali sono stati introdotti diritti separati per la lettura e la modifica di gruppi, team, utenti, percorsi, canali, servizi, rotazioni, politiche, finestre di manutenzione, controlli heartbeat, SSO e orchestrazioni. I vecchi diritti aggregati resources:read, resources:write e * sono stati mantenuti per garantire la retrocompatibilità;
- È stata aggiunta un'interfaccia di registro audit con filtraggio e paginazione. Nel registro vengono tracciate le operazioni con orchestrazioni, azioni webhook, silenzi e finestre di manutenzione, mentre i valori riservati vengono rimossi dai dati visualizzati;
- Nel web interface è apparso un tema scuro e opzioni personalizzate per lingua e visualizzazione. È stata aggiunta la localizzazione in francese, ampliata la traduzione delle sezioni di orchestrazione e manutenzione, corretta l'editing delle regole di corrispondenza dei gruppi SSO;
- Migliorato il funzionamento dei controlli heartbeat: esclusa la ricreazione di eventi di timeout, il ripristino del segnale chiude correttamente l'alert e invia una notifica di risoluzione del problema, unificata la visualizzazione dei timestamp;
- È stata preparata la documentazione per il deployment in Kubernetes utilizzando Helm. È stato aggiunto un gestore separato per Slack Socket Mode nel chart di Helm, necessario per il funzionamento dei pulsanti interattivi di conferma e chiusura degli incidenti;
- Rafforzata la protezione delle richieste HTTP in uscita, delle espressioni regolari e dei dati riservati, centralizzata l'elaborazione di UTC e dei fusi orari, rielaborate le computazioni dei programmi di rotazione e ampliata la copertura con test automatici.
Prima dell'aggiornamento, si consiglia di creare un backup del database. Le modifiche necessarie allo schema vengono effettuate attraverso il meccanismo di migrazione standard di IncidentRelay. Per un'implementazione graduale dell'Event Orchestration, gli sviluppatori raccomandano di utilizzare inizialmente le modalità shadow e hybrid, verificare le tracce di esecuzione delle regole e solo dopo passare l'orchestrazione alla modalità attiva.
Fonte: opennet.ru
