L’analisi degli alert mostra gli alert più rumorosi, i tassi di conferma, MTTA e MTTR, le tendenze del ciclo di vita e i gruppi di alert irrisolti più vecchi.
Le metriche Prometheus espongono latenza delle richieste, ricezione degli alert, code di notifica e stato dei worker, con autenticazione facoltativa tramite token bearer e supporto ServiceMonitor in Helm.
La configurazione supporta valori sovrascritti tramite variabili d’ambiente, file di segreti montati e riferimenti Helm a Secrets o ConfigMaps esistenti.
Le tracce di esecuzione dell’orchestrazione mostrano le regole corrispondenti, le modifiche agli eventi e le decisioni proposte rispetto ai risultati effettivi del ciclo di vita.
I dettagli degli alert mostrano la politica di priorità attuale e l’origine dell’instradamento delle notifiche; durante il collegamento a un incidente è possibile cercare i gruppi di alert per titolo o ID.
Le immagini Docker ora supportano linux/arm64 oltre a linux/amd64.
Gli incidenti ora hanno un proprio spazio di lavoro, ciclo di vita, priorità e responsabile operativo, con collegamento dei gruppi di alert e cronologia delle attività.
Modifica incompatibile dell’API: le operazioni sui gruppi tecnici di alert passano a /api/alert-groups; /api/incidents gestisce ora solo gli incidenti operativi.
L’integrazione Cloud.ru Cloud Eye riceve notifiche SMN firmate di allarme e ripristino con conferma automatica della sottoscrizione.
I canali Feishu / Lark recapitano notifiche testuali tramite webhook di bot personalizzati, con firma facoltativa delle richieste.
La dashboard della panoramica mostra tendenze degli alert, stato dei servizi, attività dei team, reperibili attuali e attività recenti.
Le politiche di notifica introducono filtri per priorità, gravità, sorgente e attributi del servizio, mantenendo i riferimenti ai canali disabilitati.
Sono migliorati i dettagli degli alert sui dispositivi mobili e la navigazione dalle notifiche push del browser; i webhook Grafana accettano campi facoltativi impostati su null.
La sospensione degli alert può mettere temporaneamente in pausa notifiche, promemoria, aggiornamenti ed escalation per un gruppo di alert attivo senza nasconderne lo stato tecnico o l’impatto sul servizio.
I responder possono sospendere e riattivare gli alert dall’interfaccia web, dalle notifiche push del browser, da Slack, Telegram e Mattermost, con scadenza automatica, ripresa della consegna e registrazioni complete nella timeline e nell’audit.
Un’integrazione nativa con Azure Monitor accetta webhook Common Alert Schema, associa gli eventi Fired e Resolved, normalizza le priorità Sev0-Sev4 ed espone i metadati Azure per il routing.
La cronologia degli eventi degli alert figli in ingresso può essere archiviata globalmente in modalità completa, solo iniziale o disabilitata, mentre Event Orchestration può sovrascrivere la modalità per gli eventi corrispondenti senza rimuovere le voci operative della timeline.
I provider OIDC e SAML possono mappare gli attributi di identità sugli ID utente di Slack, Telegram e Mattermost, semplificando il provisioning delle azioni interattive tramite SSO.
L’eliminazione e la ricreazione delle risorse sono più sicure: il routing dipendente e le attività dello scheduler vengono disabilitati in modo coerente mentre i record storici restano disponibili.
L’interfaccia aggiunge localizzazioni complete in spagnolo e cinese semplificato.
I deployment Helm supportano CA personalizzate e una configurazione HTTP in uscita più sicura verso reti private, con correzioni per valori numerici e percorsi statici dietro reverse proxy.
Le policy di conservazione configurabili possono rimuovere automaticamente la vecchia cronologia degli avvisi risolti, gli Explain Trace e le tracce di esecuzione di Event Orchestration in batch limitati dello scheduler.
Event Orchestration può impostare tracce di elaborazione complete, compatte o disabilitate per ogni evento corrispondente, con buffering limitato e stato compatto o troncato visibile.
La conferma di un incidente correlato ora annulla notifiche, promemoria ed escalation obsolete; gli eventi figli con priorità uguale o inferiore restano confermati, mentre quelli con priorità superiore possono riaprire il gruppo.
Un’integrazione nativa con New Relic riceve le notifiche di problemi di Alerts Workflow e instrada gli eventi del ciclo di vita normalizzati tramite i token di ingresso standard di IncidentRelay.
Un’integrazione nativa con Nagios Core e Nagios XI associa problemi di host e servizi, ripristini e conferme, ignorando downtime, flapping e notifiche personalizzate.
Il chart Helm viene ora pubblicato su GHCR come artefatto OCI, con valori predefiniti più sicuri e controlli migliorati per deployment compatibili con SQLite.
Il tema scuro è più coerente nelle viste principali e il simulatore di Orchestration presenta i risultati in un formato più chiaro e intuitivo.
Event Orchestration aggiunge regole versionate globali e per servizio che possono normalizzare, arricchire, instradare, raggruppare e deduplicare gli eventi in ingresso prima che il ciclo di vita degli avvisi ne completi l'elaborazione.
Le regole possono selezionare team, route, servizi e policy, cambiare priorità e gravità, sopprimere le notifiche, ritardare o scartare gli eventi e accodare webhook asincroni sicuri.
Un builder visuale e un editor JSON sono affiancati da validazione, simulazione, replay, esecuzione shadow, tracce, metriche e flussi immutabili di pubblicazione e rollback per rilasci più sicuri.
L'integrazione nativa con Uptime Kuma trasforma le variazioni di stato dei monitor in avvisi instradati e li risolve automaticamente quando i monitor tornano operativi.
I silenziamenti e le finestre di manutenzione possono ora essere applicati retroattivamente agli avvisi non risolti; gli avvisi interessati possono essere riattivati al termine della soppressione, mantenendo coerente lo stato di escalation e notifiche.
L'interfaccia aggiunge un tema scuro, preferenze UI salvate, una vista del registro di audit e la localizzazione francese completa.
I token API personali ottengono ambiti granulari, mentre la limitazione dei tentativi di accesso, le richieste HTTP in uscita più sicure e una validazione più rigorosa rafforzano il perimetro di sicurezza.
Il chart Helm incluso offre un percorso supportato per distribuire l'app web e i worker in background su Kubernetes.
Le migrazioni PostgreSQL risolvono ora tabelle, colonne e indici nello schema selezionato dal percorso di ricerca attivo, correggendo gli aggiornamenti che usano uno schema non pubblico.
Le migrazioni precedenti e i controlli dello schema usano utilità condivise consapevoli dello schema, evitando il ripiego non sicuro sullo schema pubblico.
Gli aggiornamenti e i rollback delle migrazioni mantengono ora le modifiche allo schema e le registrazioni della migrazione nella stessa transazione, riducendo il rischio di migrazioni applicate solo in parte.
I nuovi test delle migrazioni coprono schemi PostgreSQL personalizzati, relazioni mancanti, ricerca degli indici, proxy del database e il comportamento degli altri database.
IncidentRelay ora include il supporto alla localizzazione UI con cataloghi in inglese, russo e tedesco per workflow di alert, servizi, route, rotazioni, profilo e amministrazione.
Gli strumenti di migrazione per Grafana OnCall e PagerDuty aiutano i team a spostare i dati di reperibilita esistenti in IncidentRelay.
Le integrazioni webhook compatibili con PagerDuty Events API v2 e Datadog ampliano le fonti di alert supportate.
Il supporto a Slack Socket Mode abilita le interazioni delle app Slack senza esporre un endpoint Slack pubblico in ingresso.
I segreti di configurazione dei canali sono mascherati in modo piu coerente nelle risposte API e UI.
Official IncidentRelay immagini dei container sono ora pubblicate su GitHub Container Registry, e Docker Compose utilizza l'immagine di rilascio versione per impostazione predefinita.
Il grafico Helm ora spedisce come versione 1.1.0 e utilizza l'immagine ufficiale IncidentRelay per le distribuzioni Kubernetes.
I record di audit, gli errori di validazione e le risposte di prontezza ora redatti segreti ed evitare di esporre i dettagli sensibili di input o database.
Le azioni ripetute di riconoscimento e risoluzione sono idempotent, prevenendo gli eventi duplicati di timeline, le notifiche e gli aggiornamenti di impatto.
I link di servizio e le cartelle di esecuzione ora convalidano gli URL esterni prima di rendere i link attuabili.
Heartbeats ora supporta il monitoraggio multi-instance per lavori o agenti che attraversano molti produttori.
Auto-scoperta può imparare nuove istanze battito cardiaco da pings di successo, mentre la modalità statica può far rispettare una lista di produttore prevista.
Ogni istanza battito cardiaco in ritardo può creare il proprio avviso instradato con etichette di istanza e comportamento auto-risolve indipendente.
Lo stato di istanza Heartbeat è esposto nell'interfaccia utente e API, inclusi la lista e la disabilitazione dei produttori obsoleti.
I battiti cardiaci aggiungono il monitoraggio degli interruttori per cani da guardia, backup, lavori ETL, spedizionieri di log e altri sistemi in cui il silenzio è la modalità di fallimento.
Le modalità di intervallazione e di completamento programmato possono creare normali avvisi instradati IncidentRelay quando si prevede che i pings smettono di arrivare.
Gli avvisi Heartbeat utilizzano il percorso esistente, l'escalation, la notifica, la manutenzione e il servizio-impact pipeline, con l'opzione di auto-risolvere quando i pings ritornano.
I servizi aziendali e l'impatto di Service Catalog ora gestire lo stato, la priorità, la gravità e i pesi di dipendenza più granulari.
Business Services modella le capacità di customer-facing composte da uno o più servizi tecnici.
Lo stato calcolato utilizza la salute dei componenti efficace, l'impatto della dipendenza, la criticità dei componenti e i pesi di impatto configurabili.
Gli overrides dello stato manuale possono descrivere l'impatto del cliente e, facoltativamente, scadono automaticamente.
I dettagli del Business Service includono componenti, impatto degli incidenti attivi e cronologia dello stato, con gestione completa dell'interfaccia utente e API.
La correlazione dipendenze-consapevole collega i gruppi di avviso attivi collegati tra dipendenze di servizio.
Possibili cause, sintomi e impatto a valle includono un punteggio di fiducia, profondità di dipendenza e spiegazione.
La correlazione appare nelle liste di avviso, nei dettagli, nei termini e nel contesto di notifica, pur rimanendo consultivi: gli avvisi non vengono fusi, soppressi o risolti automaticamente.
Impostazioni di per-dipendenza e ritardi di propagazione controllano tempistiche di correlazione e rumore.
La cronologia degli impatti di servizio memorizza istantanee puntuali o manuali dei servizi interessati, impatto di avviso, impatto di dipendenza, cause di root e raggio di esplosione.
I grafici storici mostrano le tendenze e le ragioni di impatto del servizio interessato, mentre le classifiche identificano i servizi che sono ripetutamente colpiti.
L'analisi dell'affidabilità del servizio combina la salute attuale SLI/SLO con i dati di impatto storico per le recensioni operative e le indagini sugli incidenti.
La gestione del contesto di servizio fornisce ora flussi di lavoro di commutazione e modifica più chiari per link, runbook e dipendenze.
I servizi possono definire SLIs e SLO per la latenza di riconoscimento, la latenza di risoluzione, la disponibilità basata sugli incidenti e i conteggi di incidenti.
Le valutazioni di rotolamento classificano gli obiettivi come soddisfatti, a rischio, violati o senza dati e calcolano i bilanci di errore di disponibilità.
SLOs supporta la gravità e gli ambiti prioritari, le finestre configurabili, gli incidenti aperti e l'esclusione opzionale della finestra di manutenzione.
Dati di servizio, analisi aggregata e timeline di servizio espongono le misure e le modifiche di configurazione attuali.
I criteri di notifica del servizio selezionano i canali di consegna condivisi tramite regole ordinate in base a matcher di avviso e tipi di eventi, con modalità di consegna combinate, solo per route, servizio-policy.
Le Criteri di priorità assegnano automaticamente P1-P5 utilizzando regole di matcher ordinate, di default del team o di override di servizio, modalità di aggiornamento configurabili e priorità di origine o di failback.
Reusable Matcher Presets e un editor condiviso portano coerente JSON validazione, formattazione e suggerimenti da avvisi recenti a percorsi, regole di servizio, silenzi, politiche e runbook di servizio.
I risponditori possono ripristinare una priorità incidente assegnata manualmente alla gestione automatica, mentre Alert Explain Trace mostra come la priorità è stata selezionata e applicata.
Email, Slack, Mattermost, Telegram e le notifiche push del browser possono collegarsi direttamente all'evento sorgente originale, con un migliore Sentry event e il rilevamento del progetto.
On-call Health aggiunge indicatori di disponibilità a Rotazioni e Team, evidenziando configurazioni sane, avvertenti e critiche prima che si verifichi un incidente.
La diagnostica dettagliata rileva gli strati di rotazione vuoti o disabilitati, i membri inattivi, le lacune di programma, gli obiettivi di assegnazione non risolti e i problemi di consegna di notifica.
I dettagli della salute includono i conteggi dei problemi, la finestra del tempo controllato e le raccomandazioni attuabili per la riparazione di ogni squadra o rotazione interessata.
Nuova sintesi e dettaglio API endpoints espongono codici di emissione leggibili dalla macchina stabili per l'automazione, il monitoraggio e la diagnostica esterna.
Alert Explain Trace registra il modo in cui vengono elaborati gli avvisi in arrivo, inclusi la corrispondenza dei percorsi, il raggruppamento, le decisioni di manutenzione e silenzio, la pianificazione delle notifiche e i percorsi di elaborazione interrotti.
L'integrazione ingerisce le risposte ora includono un trace_id, facendo fallimenti di routing, incidenti soppressi e avvisi risolti orfani più facile da indagare dall'interfaccia utente o API.
La pagina Alerts include una vista Spiegare e link profondi per aprire tracce direttamente da trace_id parametri di query.
Gli avvisi API ora convalidano le query dell'elenco attraverso uno schema dedicato, migliorando filtri multi-valore, impaginazione, smistamento e comportamento di query assegnato a me.
LibreNMS API Gli avvisi di trasporto possono ora essere ricevuti attraverso un endpoint di integrazione dedicato librenms con stato normalizzato, gravità, etichette, deduplicazione e gestione del recupero.
Gli utenti possono impostare una preferenza del fuso orario del profilo, migliorare l'avviso e il rendering del calendario per i team distribuiti.
Il Centro di Notifica espone le richieste di risposta in sospeso e le azioni di incidente affrontate dall'utente attraverso un API dedicato.
La documentazione di Servizi API copre ora l'inventario, le regole di corrispondenza, i link, i runbook, le dipendenze, gli endpoint di impatto e analisi in un unico riferimento dedicato.
La pagina Alerts può preservare lo stato del filtro e include un filtro assegnato a me per un triage personale più veloce.
Un grafico Helm è ora disponibile per le implementazioni Kubernetes, tra cui web, scheduler e Telegram componenti del lavoratore, resi segreti di configurazione, sonde, ingresso, account di servizio e valori di persistenza.
I servizi possono definire gli stakeholder predefiniti che vengono copiati in nuovi incidenti, in modo che i proprietari e gli osservatori possano ricevere notifiche create, priorità, stato e risolte.
Le richieste di risposta incidente ora alimentano un centro di notifica in cui gli utenti mirati possono vedere richieste in sospeso e accettare o rifiutare dal flusso di lavoro incidente.
Le API di Incident e Service coprono ora i rispondenti, gli stakeholder, le priorità, i servizi e il proprietario dei servizi/defaultgestione degli stakeholder.
Le priorità incidenti ora utilizzano un P1 Critical coerente attraverso la scala informativa P5 attraverso i dettagli di avviso e le opinioni operative.
La pagina Alerts supporta il filtraggio e la selezione delle priorità, mentre il cruscotto mostra i distintivi prioritari e un riepilogo della distribuzione prioritaria.
La gravità dell'avviso in arrivo può assegnare o aumentare automaticamente la priorità degli incidenti senza sovrascrivere una priorità selezionata manualmente o abbassare una priorità automatica esistente.
Email, Mattermost, Telegram e le notifiche push del browser includono ora la priorità degli incidenti e le modifiche prioritarie manuali possono notificare agli stakeholder iscritti via e-mail.
La sincronizzazione CalDAV di sola lettura espone gli orari di squadra accessibili per Apple Calendar, Thunderbird, DAVx5 e altri client compatibili.
I feed di abbonamento ICS tokenizzati consentono ai team di aggiungere gli orari di chiamata su Outlook, Google Calendar e altri client di calendario, con i controlli per rigenerare o revocare gli URL di feed.
Una nuova integrazione firmata Sentry riceve avvisi di rilascio, avvisi metrici ed emette eventi del ciclo di vita, con segreti di livello di rotta, deduplicazione e gestione automatica della risoluzione.
La configurazione del percorso fornisce ora URL webhook specifici di origine, dettagli token e esempi curl pronti alla copia.
Gli endpoint per la salute e la prontezza supportano le sonde Kubernetes e i controlli del bilanciatore del carico.
Service Impact v2 mostra lo stato di servizio effettivo attuale, cause radice, percorsi di dipendenza e raggio di esplosione a valle.
Service Analytics v2 combina incidenti raggruppati, volume di allarme grezzo, metriche di rumore e deduplicazione, contatori di manutenzione e dati di risposta-tempo.
L'esperienza dei Servizi include ora viste più ricche di impatto e analisi con grafici e sintesi operative più chiare.
I controlli di selezione degli utenti in team, gruppi, rotazioni e flussi di lavoro di escalation hanno etichette più chiare e aggiornamenti dinamici.
Manutenzione Windows può mirare a gruppi, team, servizi o percorsi e sopprimere le notifiche, sopprimere nuovi incidenti, creare incidenti di manutenzione o escalation di pausa.
I programmi di manutenzione supportano i fusi orari, gli stati efficaci e le regole RFC5545 ricorrenti.
I risponditori possono creare, modificare ed eliminare i commenti di indagine direttamente sui gruppi di avviso, con le azioni riflesse nella timeline di avviso.
I dettagli degli avvisi ora includono controlli di gestione degli incidenti per priorità, richieste del risponditore e preferenze di notifica delle parti interessate.
I responsabili del gruppo possono gestire gli utenti del team all'interno del loro ambito di accesso.
I segnali di monitoraggio correlati possono ora essere raccolti in gruppi di avviso utilizzando i campi configurabili di route group_by.
Gli operatori possono riconoscere, risolvere e unire manualmente i gruppi di allerta mantenendo i propri avvisi individuali.
Le notifiche dei gruppi di avvisi supportano l'invio in batch ritardato e gli intervalli di aggiornamento, riducendo il rumore derivante da incidenti di breve durata o in rapida espansione.
I membri dello strato di rotazione ora hanno periodi di inizio e fine, preservando i programmi storici e sostenendo i cambiamenti futuri di appartenenza.
Le query di gruppo allerta supportano filtri multi-valore per visualizzazioni di incidenti più flessibili e richieste API.
Gli amministratori possono creare o aggiornare gli amministratori IncidentRelay da un gruppo utente Slack con il nuovo comando sync-slack-admins.
Le notifiche push del browser/PWA sono ora disponibili per gli utenti assegnati dai loro dispositivi di profilo.
Le notifiche push del browser possono includere azioni di breve durata ACK e Risolve.
Le regole di notifica del profilo consentono agli utenti di definire la consegna del follow-up tramite la spinta del browser, l'email o la chiamata vocale.
La consegna di notifica ora gestisce i controlli di consegna saltati e il comportamento di spinta del browser più affidabile.
Gli avvisi e le tabelle in stile amministratore ora utilizzano filtri riutilizzabili e aiutanti di impaginazione per set di dati più grandi.
Lo stato on-call è ora visibile nella barra superiore e l'esperienza del profilo, così gli utenti possono vedere i turni attuali e prossimi più velocemente.
Le impostazioni del profilo includono ora lo stato di chiamata e le preferenze di notifica per gli aggiornamenti e-mail di programmazione a turni.
Le notifiche via email possono avvertire gli utenti circa i prossimi periodi di chiamata nel rispetto delle preferenze e delle regole di deduplica.
Le ricerche di rotazione ora rappresentano gli strati, i sovrascritti e la partecipazione per utente durante il calcolo delle finestre on-call specifiche dell'utente.
Le viste di calendario e di rotazione sono state raffinate intorno alle ricerche di programma a tempo e più chiaro contesto on-call.
La gestione dei servizi ora modella i sistemi colpiti con proprietari, criticità, ambienti, metadati e percorsi di risposta di default.
Le regole del Service match possono mappare gli avvisi in arrivo ai servizi di default, etichette, annotazioni e campi di carico.
Le dipendenze di servizio e i metadati di impatto mostrano ora come i servizi a monte influiscono sui sistemi correlati e sugli avvisi aperti.
I runbook forniti dall'integrazione possono essere attaccati dai carichi di pagamento all'avviso e mostrati prima dei runbook di livello di servizio.
I Servizi UI e API espongono l'inventario dei servizi, le regole di corrispondenza, le dipendenze e il contesto di impatto per i flussi di lavoro operativi.
Le rotazioni ora supportano i programmi di registrazione con priorità, restrizioni attive del tempo, membri per strato e regole di timezone-aware handoff.
Il calendario ora rende il programma finale da strati e sovrascritture, in modo che le squadre possono controllare l'utente attivo su chiamata per ogni segmento di tempo.
Il filtraggio del calendario ora supporta la selezione di una specifica rotazione quando un team ha più programmi.
Le API Rotation ora espongono gli endpoint di restrizione di livello, di livello e di livello per l'automazione e le integrazioni.
Gli intervalli di promemoria della rotazione possono ora essere impostati a 0 per disabilitare i promemoria ripetuti per gli avvisi assegnati attraverso quella rotazione.
L'escalation basata sul reminder ora rispetta i promemoria disabilitati invece di tornare a un intervallo di promemoria globale.
Il filtro di gravità della pagina degli avvisi include ora gravità di avviso e di informazioni per triage piÃ1 preciso.
Le vite personali API token sono ora bloccate a 365 giorni, consentendo comunque di gettoni non esplosivi con 0 giorni.
La consegna di notifica ora utilizza notificanti dedicati per e-mail, Mattermost, Telegram e canali di chiamata vocale.
Mattermost Le notifiche Bot API possono creare e aggiornare messaggi di avviso con messaggi di stato-consapevoli e pulsanti di azione.
Le notifiche delle chiamate vocali ora utilizzano il provider vocale configurato con testo di avviso parlato, supporto di callback e mappatura dell'azione DTMF.
La documentazione dei canali API ora include i tipi di canale supportati, gli schemi di endpoint del modello di e-mail predefinito e dei canali più chiari.
La pagina dei silenzi può filtrare da schede di sintesi e includere facoltativamente la storia scaduta superiore a 30 giorni.
Docker e la documentazione sistemata ora usano il nome di servizio unificato incidentrelay invece di incidentrelay-web.
Team e liste di gruppo ora si concentrano sui record attivi, riducendo il disordine nell'amministrazione quotidiana.
La convalida è più coerente tra i moduli API, quindi i valori non validi vengono catturati prima e segnalati più prevedibilmente.
I campi dei numeri di telefono sono più facili da riempire correttamente grazie a una più rigorosa validazione, normalizzazione e feedback di frontend immediato.
I messaggi di stato di accesso e forma ora danno un feedback più chiaro durante i flussi di configurazione e amministrazione comuni.
Gli avvisi ora dispongono di pagine dei dettagli condivisibili, che semplificano l'invio di un collegamento diretto all'incidente ai membri del team.
Il progresso dell'escalation è visibile direttamente sugli avvisi, aiutando i rispondenti a capire fino a che punto un incidente è aumentato.
Lo stato di allarme è più facile da monitorare attraverso i dati più chiari risolti e di livello di escalation nel API.
Telegram Le notifiche possono rimandare all'avviso relativo e mostrare i pulsanti di azione giusti per lo stato corrente.
Il supporto Telegram include messaggi ricchi, azioni interattive, pulsanti in linea e modalità polling.
I canali di notifica possono utilizzare i filtri di gravità con la gestione della gravità normalizzata per un instradamento più prevedibile.
Gli overrides on-call sono più facili da gestire con un comportamento modale riutilizzabile, più veloce cache dello stato e del calendario-consapevole.
Le schermate di amministrazione, profilo, calendario, rotazione e avvisi sono state riprogettate per operazioni quotidiane più chiare.