IncidentRelay vs Grafana OnCall

IncidentRelay frente a Grafana OnCall: ¿mantener el autohospedaje o pasar a Cloud IRM?

La primera decisión no es una casilla de verificación de función. Se trata de si su equipo quiere operar el sistema de localización por sí mismo. Separe el Grafana OnCall ​​OSS archivado del Grafana Cloud IRM desarrollado activamente antes de compararlo con IncidentRelay.

Comparación del equipo IncidentRelay. Documentación revisada el ; IncidentRelay alcance: v2.3.1. Esta es una evaluación basada en documentación, no un punto de referencia de rendimiento ni una promesa de paridad de funciones.

Decisión rápida · Capacidades · Límites de migración · Lista de verificación piloto

Tres opciones, no dos

Evalúa IncidentRelay cuándo el autohospedaje es un requisito y tu equipo puede poseer actualizaciones, copias de seguridad y entrega de notificaciones. Evalúe Grafana Cloud IRM cuándo un servicio gestionado y una respuesta a incidentes junto con Grafana la observabilidad de la nube son más importantes que operar el backend de guardia usted mismo.

Mantener Grafana OnCall OSS es una decisión de mantenimiento. Grafana lo archivó el 24 de marzo de 2026. Las instalaciones existentes no se apagan simplemente, sino que el soporte de Cloud Connection finalizó, incluido el envío móvil de OSS y la entrega de SMS dependiente/phone. Esto no es una afirmación de que todas las rutas de notificación estén rotas: Grafana documenta alternativas como su propia configuración de Twilio. Audite las rutas de entrega que realmente utiliza. Consulte el aviso oficial de archivo y conexión a la nube.

¿Qué cambia cuando eliges IncidentRelay?

Decisión IncidentRelay v2.3.1 Grafana Cloud IRM
Modelo operativo Autohospedado; su equipo controla la implementación y mantiene el servicio. Gestión de guardias y respuesta a incidentes dentro de Grafana Cloud.
Horarios y alertas Capas de rotación, anulaciones, políticas de escalamiento y diagnósticos de salud de guardia. Rotaciones, turnos, anulaciones, agrupación de alertas, enrutamiento y escalamiento.
Flujo de trabajo de incidentes Grupos de Alerta Técnica e Incidentes operativos separados; vea el límite a continuación. Declaración de incidente, coordinación de respuesta, cronogramas y revisión post-incidente.
Configuración de notificación Configuras proveedores de chat, SMTP o voz; navegador/PWA push está habilitado por usuario. Servicios de notificación administrados en la nube y la aplicación móvil Grafana.
Contexto de la investigación Mantenga las herramientas de supervisión existentes y envíe sus alertas a IR a través de integraciones compatibles. Respuesta a incidentes junto con Grafana métricas, registros y seguimientos de la nube.

Las capacidades de nube anteriores siguen la Grafana descripción general de IRM. Verificar los términos actuales del plan y la cobertura de entrega para su organización; esta comparación no supone derechos comerciales iguales.

Dos límites que vale la pena probar

En IR 2.3, un AlertGroup posee reconocimiento técnico, resolución y escalamiento. Un incidente separado posee un flujo de trabajo operativo, una prioridad y un asignado, y puede vincular varios grupos de alerta. En esta versión, los respondedores y las partes interesadas permanecen dentro del ámbito de AlertGroup. No asuma un modelo de colaboración idéntico. Consulte Gestión de incidentes.

El IR autohospedado no hace que la entrega externa sea autohospedada. Los servicios de chat, SMTP retransmisiones y proveedores de voz siguen siendo dependientes. El navegador/PWA push no es la aplicación móvil nativa Grafana. Verifique los requisitos del canal y la configuración de inserción del navegador en los dispositivos que tienen sus socorristas.

Migrar desde Grafana OnCall OSS

La guía de migración de IR v2.3.1 describe un importador público API. Se ejecuta en modo de prueba de forma predeterminada y escribe un plan y un informe antes de que decida aplicar cambios. Es una herramienta de migración OSS, no un reclamo de migración Grafana Cloud IRM automática.

  • Compatible: usuarios y membresías, equipos, horarios y turnos de calendario/web admitidos, anulaciones, cadenas de escalamiento básicas, integraciones y sus rutas predeterminadas.
  • Revisión manual: programaciones externas de iCal, recurrencia mensual, restricciones entre medianoche, turnos o notificaciones multiusuario simultáneos y Jinja2 arbitrario o enrutamiento de expresiones regulares de carga completa.
  • Inhabilitado al importar: rutas condicionales no predeterminadas. Grafana la coincidencia de toda la carga útil no es equivalente a la coincidencia de etiquetas normalizadas de IR. Vuelva a escribir y probar los emparejadores antes de habilitar estas rutas.
  • No transferido: historial de alertas y credenciales enmascaradas, como secretos de webhooks salientes. Configure los canales de notificación y los secretos por separado.

Mantenga state.json para importaciones repetibles y proteja route-secrets.json, que contiene las nuevas URL y tokens de entrada. No coloque ninguno de los archivos en un repositorio público.

Un piloto útil, antes de cambiar los webhooks de producción

  1. Haga un inventario de cada ruta de notificación actual y luego ejecute el importador en modo de prueba solo con usuarios existentes. Resolver advertencias inesperadas; no acepte una conversión de programación con pérdidas solo para obtener un informe ecológico.
  2. Compare un ciclo de rotación completo, límites de zona horaria y una anulación planificada. Utilice On-call Health para buscar lagunas en el cronograma y configuraciones de entrega faltantes.
  3. Reproduzca ejemplos desinfectados: una alerta de producción, un duplicado, un evento resuelto y una alerta que no debería notificar. Verifique el equipo seleccionado, el servicio y el objetivo de escalamiento.
  4. Deje que una alerta de prueba no se reconozca para verificar la escalada de la copia de seguridad. Luego reconozca otro y verifique que la paginación se detenga. Confirme la entrega real en los dispositivos de respuesta, no solo una respuesta exitosa HTTP.
  5. Cambie una integración de bajo riesgo y observe un ciclo de guardia. Mantenga el punto final y la configuración anteriores disponibles para revertirlos; Evite localizar a los respondedores de ambos sistemas durante las pruebas paralelas.

¿Tiene que reemplazar Grafana paneles?

No. El traslado del manejo de guardia es una decisión independiente del traslado del monitoreo. Grafana Alerting puede enviar alertas a IncidentRelay; Los paneles pueden permanecer donde están. Comience con una implementación de prueba y un flujo de alerta.

Grafana OnCall y Grafana Cloud IRM son productos de Grafana Labs. IncidentRelay no está afiliado a Grafana Labs.