IncidentRelay vs. Grafana OnCall

IncidentRelay vs Grafana OnCall: zachować własny hosting czy przejść do Cloud IRM?

Pierwsza decyzja nie dotyczy pola wyboru funkcji. Zależy to od tego, czy Twój zespół chce sam obsługiwać system przywoławczy. Oddziel zarchiwizowany Grafana OnCall OSS od aktywnie rozwijanego Grafana Cloud IRM przed porównaniem któregokolwiek z IncidentRelay.

Porównanie dokonane przez zespół IncidentRelay. Dokumentacja sprawdzona w dniu ; IncidentRelay zakres: v2.3.1. Jest to ocena oparta na dokumentacji, a nie test porównawczy wydajności lub obietnica parytetu funkcji.

Szybka decyzja · Możliwości · Limity migracji · Pilotażowa lista kontrolna

Trzy opcje, a nie dwie

Oceń IncidentRelay, kiedy wymagany jest samodzielny hosting, a Twój zespół będzie mógł posiadać uaktualnienia, kopie zapasowe i dostarczanie powiadomień. Oceń Grafana Cloud IRM, kiedy usługa zarządzana i reakcja na incydenty wraz z Grafana obserwowalnością w chmurze mają większe znaczenie niż samodzielna obsługa backendu na żądanie.

Utrzymanie Grafana OnCall OSS to decyzja konserwacyjna. Grafana zarchiwizowała ją 24 marca 2026 r. Istniejące instalacje nie zostaną po prostu wyłączone, ale zakończyła się obsługa Cloud Connection, w tym mobilna funkcja push OSS i zależne dostarczanie SMS-ów/phone. Nie jest to twierdzenie, że każda ścieżka powiadomień jest uszkodzona: Grafana dokumentuje alternatywy, takie jak własna konfiguracja Twilio. Audytuj ścieżki dostawy, z których faktycznie korzystasz. Zapoznaj się z oficjalnymi informacjami dotyczącymi archiwizacji i połączenia z chmurą.

Co się zmieni, gdy wybierzesz IncidentRelay?

Decyzja IncidentRelay wersja 2.3.1 Grafana Cloud IRM
Model operacyjny Własny hosting; Twój zespół kontroluje wdrażanie i utrzymuje usługę. Zarządzane dyżurami i reagowaniem na incydenty w chmurze Grafana.
Harmonogramy i alerty Warstwy rotacji, zastąpienia, zasady eskalacji i diagnostyka stanu na wezwanie. Rotacje, przesunięcia, zastąpienia, grupowanie alertów, kierowanie i eskalacja.
Przepływ pracy w przypadku awarii Grupy alertów technicznych i oddzielne incydenty operacyjne; zobacz granicę poniżej. Zgłaszanie incydentów, koordynacja reakcji, harmonogramy i przegląd po incydencie.
Konfiguracja powiadomień Konfigurujesz czat, SMTP lub dostawców usług głosowych; przeglądarka/PWA push jest włączone dla każdego użytkownika. Usługi powiadomień zarządzane w chmurze i aplikacja mobilna Grafana.
Kontekst śledztwa Zachowaj istniejące narzędzia monitorujące i wysyłaj ich alerty do podczerwieni za pomocą obsługiwanych integracji. Reakcja na incydenty wraz z metrykami, dziennikami i śladami w chmurze Grafana.

Powyższe możliwości chmury są zgodne z Grafana omówieniem usługi IRM. Sprawdź aktualne warunki planu i zakres dostaw dla swojej organizacji; porównanie to nie zakłada równych uprawnień handlowych.

Dwie granice warte przetestowania

W IR 2.3 AlertGroup posiada potwierdzenie techniczne, rozwiązanie i eskalację. Oddzielny incydent ma operacyjny przepływ pracy, priorytet i cesjonariusza oraz może łączyć kilka grup alertów. W tej wersji osoby reagujące i zainteresowane strony nadal będą objęte zakresem AlertGroup. Nie zakładaj identycznego modelu współpracy. Zobacz Zarządzanie incydentami.

Samodzielne hostowanie IR nie powoduje, że dostarczanie zewnętrzne jest hostowane samodzielnie. Usługi czatu, przekaźniki SMTP i dostawcy usług głosowych pozostają zależnościami. Przeglądarka/PWA push nie jest natywną aplikacją mobilną Grafana. Sprawdź wymagania dotyczące kanału i konfigurację push w przeglądarce na urządzeniach, które mają Twoi respondenci.

Migracja z Grafana OnCall OSS

W przewodniku migracji IR do wersji 2.3.1 opisano publiczny importer API. Domyślnie działa w trybie próbnym i zapisuje plan i raport, zanim zdecydujesz się zastosować zmiany. Jest to narzędzie do migracji OSS, a nie twierdzenie o automatycznej migracji Grafana Cloud IRM.

  • Obsługiwane: użytkownicy i członkostwa, zespoły, obsługiwane kalendarze/web harmonogramy i zmiany, zastąpienia, podstawowe łańcuchy eskalacji, integracje i ich trasy domyślne.
  • Przegląd ręczny: zewnętrzne harmonogramy iCal, powtarzanie co miesiąc, ograniczenia między północami, jednoczesne zmiany lub powiadomienia dla wielu użytkowników oraz dowolne trasowanie wyrażeń regularnych Jinja2 lub całego ładunku.
  • Wyłączone podczas importu: trasy warunkowe inne niż domyślne. Dopasowanie całego ładunku Grafana nie jest równoważne dopasowywaniu etykiet znormalizowanych w podczerwieni. Przepisz i przetestuj elementy dopasowujące przed włączeniem tych tras.
  • Nieprzeniesione: historia alertów i zamaskowane dane uwierzytelniające, takie jak wychodzące klucze tajne webhooka. Skonfiguruj kanały powiadomień i sekrety osobno.

Zachowaj state.json na potrzeby powtarzalnego importu i chroń route-secrets.json, który zawiera nowe adresy URL i tokeny pobierania. Nie umieszczaj żadnego pliku w publicznym repozytorium.

Przydatny pilot przed zmianą webhooków produkcyjnych

  1. Zinwentaryzuj każdą bieżącą ścieżkę powiadomień, a następnie uruchom importera w trybie próbnym tylko z istniejącymi użytkownikami. Rozwiązuj nieoczekiwane ostrzeżenia; nie akceptuj stratnej konwersji harmonogramu tylko po to, aby uzyskać zielony raport.
  2. Porównaj pełny cykl rotacji, granice stref czasowych i planowane zastąpienie. Użyj funkcji On-Call Health, aby wyszukać luki w harmonogramie i brakującą konfigurację dostawy.
  3. Powtórz oczyszczone przykłady: alert produkcyjny, duplikat, rozwiązane zdarzenie i alert, który nie powinien powiadamiać. Sprawdź wybrany zespół, usługę i cel eskalacji.
  4. Pozwól, aby alert testowy pozostał niezatwierdzony, aby zweryfikować eskalację kopii zapasowej. Następnie potwierdź kolejny i sprawdź, czy przywoływanie się zatrzyma. Potwierdź faktyczną dostawę na urządzeniach reagujących, a nie tylko odpowiedź o powodzeniu HTTP.
  5. Zmień jedną integrację o niskim ryzyku i obserwuj cykl dyżurów. Zachowaj dostęp do poprzedniego punktu końcowego i konfiguracji w celu przywrócenia; unikaj stronicowania obiektów odpowiadających obu systemów podczas testów w tle.

Czy musisz wymienić pulpity nawigacyjne Grafana?

Nie. Przeniesienie obsługi dyżurów to decyzja odrębna od przeniesienia monitoringu. Grafana Alerting może wysyłać alerty do: IncidentRelay; pulpity nawigacyjne mogą pozostać tam, gdzie są. Zacznij od wdrożenia testowego i jednego przepływu alertów.

Grafana OnCall i Grafana Cloud IRM to produkty firmy Grafana Labs. Firma IncidentRelay nie jest powiązana z laboratorium Grafana.