IncidentRelay vs Grafana OnCall

IncidentRelay ou Grafana OnCall : conserver l'auto-hébergement ou passer à Cloud IRM ?

La première décision n’est pas une case à cocher de fonctionnalité. Il s’agit de savoir si votre équipe souhaite exploiter elle-même le système de radiomessagerie. Séparez les logiciels libres Grafana OnCall archivés des fichiers Grafana Cloud IRM activement développés avant de comparer l'un ou l'autre avec IncidentRelay.

Comparaison par l'équipe IncidentRelay. Documentation examinée le ; Portée IncidentRelay : v2.3.1. Il s'agit d'une évaluation basée sur la documentation, et non d'une référence de performances ou d'une promesse de parité des fonctionnalités.

Décision rapide · Capacités · Limites de migration · Liste de contrôle pilote

Trois options, pas deux

Évaluez IncidentRelay lorsque l'auto-hébergement est une exigence et que votre équipe peut s'approprier les mises à niveau, les sauvegardes et l'envoi des notifications. Évaluez Grafana Cloud IRM quand un service géré et une réponse aux incidents ainsi que Grafana l'observabilité du cloud sont plus importants que l'exploitation du backend d'astreinte vous-même.

Conserver Grafana OnCall OSS est une décision de maintenance. Grafana l'a archivé le 24 mars 2026. Les installations existantes ne sont pas simplement désactivées, mais la prise en charge de Cloud Connection a pris fin, y compris le push mobile OSS et la livraison de SMS/phone dépendante. Cela ne veut pas dire que chaque chemin de notification est interrompu : Grafana documente des alternatives telles que votre propre configuration Twilio. Auditez les chemins de livraison que vous utilisez réellement. Consultez l'avis d'archives officielles et de Cloud Connection.

Qu'est-ce qui change lorsque vous choisissez IncidentRelay ?

Décision IncidentRelay v2.3.1 Grafana Cloud IRM
Modèle opérationnel Auto-hébergé ; votre équipe contrôle le déploiement et maintient le service. Gérer les gardes et la réponse aux incidents dans Grafana Cloud.
Horaires et alertes Couches de rotation, remplacements, règles de remontée d'informations et diagnostics d'état d'astreinte. Rotations, équipes, remplacements, regroupement d'alertes, routage et escalade.
Flux de travail des incidents Groupes d'alertes techniques et incidents opérationnels distincts ; voir la limite ci-dessous. Déclaration d'incident, coordination de la réponse, délais et examen post-incident.
Configuration des notifications Vous configurez le chat, SMTP ou les fournisseurs de voix ; navigateur/PWA push est activé par utilisateur. Services de notification gérés dans le cloud et application mobile Grafana.
Contexte de l'enquête Conservez les outils de surveillance existants et envoyez leurs alertes à IR via les intégrations compatibles. Réponse aux incidents avec Grafana métriques, journaux et traces Cloud.

Les fonctionnalités cloud ci-dessus suivent la Grafana présentation de l'IRM. Vérifiez les conditions actuelles du plan et la couverture de livraison pour votre organisation ; cette comparaison ne suppose pas des droits commerciaux égaux.

Deux limites à tester

Dans IR 2.3, un AlertGroup possède l’accusé de réception technique, la résolution et l’escalade. Un incident distinct possède un flux de travail opérationnel, une priorité et un responsable, et peut relier plusieurs groupes d'alerte. Les intervenants et les parties prenantes restent limités à AlertGroup dans cette version. Ne présumez pas d’un modèle de collaboration identique. Consultez la section Gestion des incidents.

IR auto-hébergé ne rend pas la livraison externe auto-hébergée. Les services de chat, les relais SMTP et les fournisseurs de voix restent des dépendances. Le navigateur/PWA push n'est pas l'application mobile native Grafana. Vérifiez les exigences en matière de canaux et la configuration push du navigateur sur les appareils transportés par vos intervenants.

Migration depuis Grafana OnCall OSS

Le guide de migration IR v2.3.1 décrit un importateur public API. Il s'exécute en mode essai par défaut et rédige un plan et un rapport avant que vous choisissiez d'appliquer les modifications. Il s'agit d'un outil de migration OSS, et non d'une revendication de migration automatique Grafana Cloud IRM.

  • Supporté : utilisateurs et adhésions, équipes, calendriers et équipes de calendrier/web pris en charge, remplacements, chaînes de remontée d'informations de base, intégrations et leurs itinéraires par défaut.
  • Vérification manuelle : planifications iCal externes, récurrence mensuelle, restrictions entre minuit, équipes ou notifications multi-utilisateurs simultanées et routage arbitraire Jinja2 ou regex de charge utile entière.
  • Désactivé lors de l'importation : routes conditionnelles autres que celles par défaut. La correspondance de charge utile entière Grafana n'est pas équivalente à la correspondance d'étiquettes normalisées IR. Réécrivez et testez les matchers avant d'activer ces routes.
  • Non transféré : historique des alertes et informations d'identification masquées telles que les secrets des webhooks sortants. Configurez les canaux de notification et les secrets séparément.

Conservez state.json pour les importations répétables et protégez route-secrets.json, qui contient les nouvelles URL et jetons d'admission. Ne placez aucun des deux fichiers dans un référentiel public.

Un pilote utile, avant de changer de webhooks de production

  1. Inventoriez chaque chemin de notification actuel, puis exécutez l'importateur en mode essai avec les utilisateurs existants uniquement. Résoudre les avertissements inattendus ; n'acceptez pas une conversion d'horaire avec perte juste pour obtenir un rapport vert.
  2. Comparez un cycle de rotation complet, des limites de fuseau horaire et un remplacement planifié. Utilisez On-call Health pour rechercher les écarts de calendrier et les configurations de livraison manquantes.
  3. Rejouez des exemples épurés : une alerte de production, un doublon, un événement résolu et une alerte qui ne doit pas notifier. Vérifiez l'équipe, le service et la cible d'escalade sélectionnés.
  4. Laissez une alerte de test sans accusé de réception pour vérifier l’escalade des sauvegardes. Ensuite, accusez-en un autre et vérifiez que la recherche de personnes s'arrête. Confirmez la livraison réelle sur les appareils du répondeur, et pas seulement une réponse réussie de HTTP.
  5. Basculez vers une intégration à faible risque et observez un cycle d’astreinte. Conserver le point de terminaison et la configuration précédents disponibles pour la restauration ; évitez d'appeler les répondeurs des deux systèmes pendant les tests fantômes.

Devez-vous remplacer Grafana tableaux de bord ?

Non. Le déplacement de la gestion des astreintes est une décision distincte du déplacement de la surveillance. Grafana Alerting peut envoyer des alertes à IncidentRelay ; les tableaux de bord peuvent rester là où ils sont. Commencez par un déploiement test et un flux d'alerte.

Grafana OnCall et Grafana Cloud IRM sont des produits Grafana Labs. IncidentRelay n'est pas affilié à Grafana Labs.