Sprawdzone przykłady dla IncidentRelay v2.3.1, sprawdzone . Poniższe nazwy, identyfikatory i czasy mają charakter ilustracyjny; Sprawdź je we wdrożeniu testowym przed użyciem poświadczeń produkcyjnych.
Przykład biznesowy · Konfiguracja · Przykład praktyczny · Kontrola akceptacji · Ograniczenia i tryby awarii
Przykład biznesowy: trzy systemy klienckie, jeden głośny czat wsparcia
Przykładowy scenariusz, a nie studium przypadku klienta. Poniższe dane to sugestie dotyczące pilotażu, a nie zmierzone oszczędności lub stwierdzenie, że IR obejmuje każdy panel raportowania.
Sytuacja i ryzyko. Dostawca usług obsługuje trzech klientów, każdy z alertami dotyczącymi aplikacji i infrastruktury. Wszystko ląduje na jednym czacie. Inżynierowie przekazują wiadomości innym zespołom, podczas gdy powtarzające się alerty zamazują oryginalny raport. Ryzykiem biznesowym jest opóźniona własność i możliwe do uniknięcia wysiłki w zakresie wsparcia, nawet jeśli monitorowanie szybko wykryje awarię.
Przepływ pracy w podczerwieni. Przypisz każdą usługę klienta do odpowiedniego zespołu i użyj zamierzonego tokena trasy dla każdego nadawcy. Dopasuj etykiety środowiska i usługi, wybierz cel dyżurów i grupuj powtórzenia tylko w zamierzonych granicach własności. Przed rozszerzeniem wzorca przeprowadź pilotaż usługi rozliczeń produkcyjnych jednego klienta, korzystając z poniższego modułu dopasowującego.
Korzyść operacyjna do sprawdzenia. Zastąp rutynowe przekazywanie wiadomości jawnym routingiem. Przechowuj pierwszą odpowiedź z zespołem, który może podjąć działania, zachowując jednocześnie osobne alerty podrzędne, gdy kilku hostów zgłosi ten sam problem.
Co mierzyć. Liczba alertów przypisanych ponownie po podjęciu pierwszej decyzji o routingu, grup bez właściciela i powiadomień według podstawowego błędu dla każdego klienta. Przejrzyj także odrzucone lub niedopasowane zdarzenia testowe: mniejsza liczba stron nie będzie sukcesem, jeśli awaria klienta stanie się niewidoczna.
Granica. Dopasowanie etykiet nie oznacza izolacji danych klienta. Osobno przejrzyj uprawnienia dostępu, poświadczenia i granice wdrożenia. Niespójne etykiety lub zbyt szerokie grupowanie mogą w dalszym ciągu wysyłać pracę do niewłaściwego zespołu lub łączyć niepowiązane objawy; zweryfikuj te przypadki przed przyjęciem innego klienta.
Oddzielne spożycie, własność i dostawa
Usługa rozliczeń produkcyjnych i kopia testowa nie powinny przez przypadek budzić tych samych osób. W przypadku pierwszego pilotażu utwórz trasę webhooka dla zespołu rozliczeniowego produkcji, wybierz jego domyślną usługę i rotację lub zasady, a następnie dołącz kanały. Jego token spożycia wybiera trasę; Same pasujące etykiety nie uwierzytelniają nadawcy ani nie wybierają dowolnej trasy.
Dopasowujący wąską trasę i jawny klucz grupujący
Wklej to do edytora dopasowującego trasę. Jest to obiekt dopasowujący, a nie przychodząca treść webhooka. Wszystkie warunki używają semantyki ORAZ. Wymaganie etykiet produkcyjnych i usługowych sprawia, że inscenizacja i wydarzenia nieoznakowane są poza tą trasą.
{
"source": "webhook",
"labels": {
"environment": "production",
"service": "billing-api"
}
}W tym przykładzie ustaw pole group_by trasy na:
["alertname", "severity", "labels.cluster"]Dwa hosty zgłaszające ten sam alert w tym samym klastrze mogą następnie współdzielić grupę AlertGroup, zachowując oddzielne tożsamości podrzędne. W przypadku ogólnego webhooka użyj stabilnych odcisków palców, takich jak billing:node-1:health i billing:node-2:health. Dołącz oczekiwane etykiety dotyczące niepowodzeń i odzyskiwania i nigdy nie używaj nowej sygnatury czasowej jako tożsamości każdej ponownej próby.
Deduplikacja i grupowanie to co innego: ten sam odcisk palca aktualizuje dziecko; różne odciski palców z tym samym kluczem grupy tworzą osobne dzieci w jednej grupie. Trasa, zespół, źródło i usługa również grupują zakres. Dodaj instance do pól grupowania tylko wtedy, gdy każdy host powinien stanowić osobną grupę.
Kiedy jeden nadawca tak naprawdę obsługuje kilka zespołów
Użyj globalnej orkiestracji, gdy należy wybrać własność spośród treści wydarzenia. W Konstruktorze zacznij od warunków labels.environment equals production i labels.service equals billing-api, a następnie wybierz prawidłowy zespół, trasę i obiekty usług z tej samej grupy. Nie kopiuj numerycznych identyfikatorów obiektów pomiędzy instalacjami.
Sprawdź i symuluj zarówno dopasowania, jak i niedopasowania, opublikuj, a następnie użyj shadow ze zgodnością z hybrid. Przed przejściem na active przejrzyj rzeczywiste wykonania. Shadow rejestruje decyzje bez zmiany zachowań produkcyjnych; Symulator nie zapewnia kompleksowej dostawy.
Użyj małej macierzy testów routingu
| Wejście | Oczekiwany wynik dla tego przykładu |
|---|---|
| Zdarzenie rozliczeniowe produkcji | Matcher przechodzi; wybrana usługa, cesjonariusz i kanały odpowiadają planowanej własności. |
| Etykieta usługi tymczasowej lub brakująca | Matcher nie przechodzi. Potwierdź zamierzoną alternatywną ścieżkę nadawcy; ten przykład nie tworzy trasy typu catch-all. |
| Duplikat odcisku palca | To samo dziecko jest aktualizowane. Inny odcisk palca hosta tworzy drugie dziecko w tej samej grupie, gdy etykiety grupowania są zgodne. |
| Powrót do zdrowia tylko dla jednego z dwójki dzieci | To dziecko postanawia; grupa kontynuuje strzelanie, dopóki wszystkie strzelające dzieci nie wyzdrowieją. Powrót do zdrowia sierot nie tworzy nowej grupy. |
Unikaj zasad, które po cichu usuwają dowody
Pusty element dopasowujący pasuje do wszystkiego. Etykieta o nazwie severity nie jest automatycznie tym samym polem, co znormalizowana ważność zdarzenia; użyj udokumentowanej ścieżki pola i sprawdź rzeczywiste znormalizowane zdarzenie. Nie wymagaj status=firing na ścieżce wlotowej, która również musi akceptować odzyskiwanie.
active + legacy nie stosuje decyzji dotyczących aranżacji. W hybrid nieprawidłowe kombinacje elementów mogą powrócić do starszej ścieżki; zamiast tego tryb autorytatywny orchestration blokuje przetwarzanie w przypadku niepowodzeń oceny lub sprawdzania poprawności jednostki. Wybierz zachowanie w przypadku awarii celowo.
Zacznij bez ogólnych reguł drop lub suppress. Pomijanie i grupowanie może zmniejszyć liczbę powiadomień, ale nie sprawia, że zły sygnał monitorowania jest użyteczny. Zachowaj przetestowaną poprzednią wersję i przejrzyj nieoczekiwane niezgodności przed rozszerzeniem wdrożenia.