IncidentRelay vs Grafana OnCall

IncidentRelay vs Grafana OnCall: mantenere il self-hosting o passare a Cloud IRM?

La prima decisione non è una casella di controllo della funzionalità. Dipende se il tuo team vuole gestire il sistema di cercapersone stesso. Separare l'OSS Grafana OnCall archiviato dall'OSS Grafana Cloud IRM sviluppato attivamente prima di confrontarlo con IncidentRelay.

Confronto da parte del team IncidentRelay. Documentazione rivista il ; ambito IncidentRelay: v2.3.1. Questa è una valutazione basata sulla documentazione, non un benchmark delle prestazioni o una promessa di parità di funzionalità.

Decisione rapida · Funzionalità · Limiti di migrazione · Elenco di controllo pilota

Tre opzioni, non due

Valuta IncidentRelay quando l'hosting autonomo è un requisito e il tuo team può gestire aggiornamenti, backup e recapito delle notifiche. Valuta Grafana Cloud IRM quando un servizio gestito e la risposta agli incidenti insieme a Grafana l'osservabilità del cloud sono più importanti della gestione autonoma del backend di chiamata.

Mantenere Grafana OnCall OSS è una decisione di manutenzione. Grafana l'ha archiviata il 24 marzo 2026. Le installazioni esistenti non vengono semplicemente disattivate, ma il supporto di Cloud Connection è terminato, incluso il push mobile OSS e l'invio di SMS dipendenti/phone. Ciò non significa che ogni percorso di notifica sia interrotto: Grafana documenta alternative come la tua configurazione Twilio. Controlla i percorsi di consegna effettivamente utilizzati. Consulta l'avviso ufficiale sull'archiviazione e sulla connessione cloud.

Cosa cambia quando scegli IncidentRelay?

Decisione IncidentRelay v2.3.1 Grafana Cloud IRM
Modello operativo Ospitato autonomamente; il tuo team controlla la distribuzione e mantiene il servizio. Gestione delle chiamate e della risposta agli incidenti all'interno di Grafana Cloud.
Orari e avvisi Livelli di rotazione, sostituzioni, criteri di escalation e diagnostica dell'integrità su chiamata. Rotazioni, spostamenti, sostituzioni, raggruppamento di avvisi, instradamento ed escalation.
Flusso di lavoro incisivo Gruppi di allerta tecnici e incidenti operativi separati; vedi il confine qui sotto. Dichiarazione dell'incidente, coordinamento della risposta, tempistiche e revisione post-incidente.
Configurazione della notifica Configura la chat, SMTP o i provider vocali; browser/PWA push è abilitato per utente. Servizi di notifica gestiti dal cloud e app mobile Grafana.
Contesto di indagine Mantieni gli strumenti di monitoraggio esistenti e invia i relativi avvisi all'IR tramite le integrazioni supportate. Risposta agli incidenti insieme a Grafana parametri, log e tracce Cloud.

Le funzionalità cloud sopra riportate seguono la Grafana panoramica IRM. Verifica i termini attuali del piano e la copertura della consegna per la tua organizzazione; questo confronto non presuppone pari diritti commerciali.

Due confini che vale la pena testare

In IR 2.3, un AlertGroup possiede il riconoscimento tecnico, la risoluzione e l'escalation. Un incidente separato possiede un flusso di lavoro operativo, una priorità e un assegnatario e può collegare diversi AlertGroup. I risponditori e le parti interessate rimangono nell'ambito di AlertGroup in questa versione. Non dare per scontato un modello di collaborazione identico. Consulta Gestione degli incidenti.

L'IR self-hosting non effettua la consegna esterna self-hosted. I servizi di chat, i relè SMTP e i fornitori di servizi vocali rimangono dipendenze. Il browser/PWA push non è l'app mobile nativa di Grafana. Controlla i requisiti del canale e la configurazione push del browser sui dispositivi trasportati dai tuoi risponditori.

Migrazione da Grafana OnCall OSS

La guida alla migrazione IR v2.3.1 descrive un importatore pubblico API. Per impostazione predefinita viene eseguito in modalità di prova e scrive un piano e un report prima di scegliere di applicare le modifiche. È uno strumento di migrazione OSS, non una richiesta di migrazione automatica di Grafana Cloud IRM.

  • Supportati: utenti e abbonamenti, team, calendari e turni supportati/web, sostituzioni, catene di escalation di base, integrazioni e relativi percorsi predefiniti.
  • Revisione manuale: pianificazioni iCal esterne, ricorrenza mensile, restrizioni oltre la mezzanotte, turni o notifiche multiutente simultanei e Jinja2 arbitrario o routing regex dell'intero payload.
  • Disabilitato all'importazione: percorsi condizionali non predefiniti. Grafana la corrispondenza dell'intero carico utile non è equivalente alla corrispondenza dell'etichetta normalizzata IR. Riscrivi e testa i matcher prima di abilitare questi percorsi.
  • Non trasferito: cronologia avvisi e credenziali mascherate come i segreti webhook in uscita. Configura separatamente i canali di notifica e i segreti.

Mantieni state.json per importazioni ripetibili e proteggi route-secrets.json, che contiene i nuovi URL e token di immissione. Non inserire nessuno dei due file in un repository pubblico.

Un progetto pilota utile, prima di modificare i webhook di produzione

  1. Inventaria ogni percorso di notifica corrente, quindi esegui l'importatore in modalità di prova solo con gli utenti esistenti. Risolvere avvisi imprevisti; non accettare una conversione di pianificazione con perdite solo per ottenere un rapporto verde.
  2. Confronta un ciclo di rotazione completo, i limiti del fuso orario e una sostituzione pianificata. Utilizza On-call Health per cercare lacune nella pianificazione e configurazione di consegna mancante.
  3. Riproduci esempi ripuliti: un avviso di produzione, un duplicato, un evento risolto e un avviso che non dovrebbe notificare. Controlla il team selezionato, il servizio e l'obiettivo dell'escalation.
  4. Lascia che un avviso di prova non venga riconosciuto per verificare l'escalation del backup. Quindi riconoscerne un altro e verificare che il paging si interrompa. Conferma la consegna effettiva sui dispositivi dei risponditori, non solo una risposta positiva HTTP.
  5. Cambia un'integrazione a basso rischio e osserva un ciclo di reperibilità. Mantenere l'endpoint e la configurazione precedenti disponibili per il rollback; evitare di effettuare il paging dei risponditori di entrambi i sistemi durante il test shadow.

Devi sostituire Grafana dashboard?

No. Lo spostamento dell'assistenza di guardia è una decisione separata dallo spostamento del monitoraggio. Grafana Alerting può inviare avvisi a IncidentRelay; i dashboard possono rimanere dove sono. Inizia con un'implementazione di prova e un flusso di avvisi.

Grafana OnCall e Grafana Cloud IRM sono prodotti Grafana Labs. IncidentRelay non è affiliato con Grafana Labs.