Projektowanie nowoczesnych systemów alertowych dla zespołów zajmujących się obserwowalnością

Alerting jest zbyt często opisywane jako funkcja monitoringu. Taki sposób przedstawiania jest wygodny, ale ukazuje prawdziwy problem.

Wartość nie obudzi nikogo w nocy. Wykres nie tworzy poczucia pilności. Panel nie przypisuje odpowiedzialności. Alerty robią wszystkie trzy rzeczy, jeśli system za nimi stojący jest dobrze zaprojektowany, a żadnej z nich, jeśli projekt jest słaby.

Celem, jaki sobie stawiamy, jest zdefiniowanie alertingu jako systemu złożonego z reguł, trasowania, kontekstu, kanałów, ludzi i pętli sprzężenia zwrotnego.

To ujęcie ma znaczenie, ponieważ nowoczesny alerting to już nie pojedynczy próg powiązany z pagerem. Prometheus oddziela reguły alertingu od Alertmanagera, gdzie obsługiwane są trasy, grupowanie, inhibicja, wyciszenia i odbiorniki. Ten podział jest użyteczny, ponieważ wykrywanie i dostarczanie to różne obszary zainteresowań. Reguły alertingu decydują, że coś jest nie tak. Zarządzanie alertami decyduje, kto powinien się martwić, jak często i przez który kanał.

Powiązane materiały:

• Platformy czatu jako interfejsy systemowe w nowoczesnych systemach
• Wzorce integracji Slacka dla alertów i przepływów pracy
• Wzorzec integracji Discorda dla alertów i pętli sterowania

Czym tak naprawdę jest alert

Alert to nie każdy sygnał, który wygląda interesująco.

Alert to sygnał wymagający działania.

Ta definicja wyklucza spore ilości telemetrii. Logi to zapisy. Metryki to pomiary. Trasy to ścieżki wykonania. Systemy obserwowalności zbierają te sygnały, aby ludzie i narzędzia mogli zrozumieć zachowanie. Alerting zaczyna się później, gdy jakiś warunek jest na tyle ważny, aby wywołać reakcję.

To jest granica, która utrzymuje zdrowie obserwowalności.

• Metryki odpowiadają na pytanie, co się zmieniło.
• Logi odpowiadają na pytanie, co się stało.
• Trasy odpowiadają na pytanie, gdzie czas i błędy się kumulowały.
• Alerty odpowiadają na pytanie, kto musi działać teraz.

Jeśli wszystko staje się alertem, nic nie jest alertem. Wynikiem nie jest pokrycie. Jest to zamieszanie.

Alerting jako system

Praktyczny cykl życia alertu wygląda tak:

sygnał -> reguła -> alert -> trasa -> kanał -> człowiek lub automatyka -> działanie -> feedback

Ten cykl jest bardziej użyteczny niż prosty diagram progowy, ponieważ odzwierciedla to, co robią rzeczywiste systemy.

Sygnał

Punktem startowym jest telemetria. W większości stosów oznacza to metryki, logi, trasy lub pochodne testy zdrowia. OpenTelemetry formalizuje metryki, logi i trasy jako osobne sygnały, co jest pomocne, ponieważ alerty powinny być wyprowadzane z odpowiedniego sygnału do danej zadania.

Reguła

Reguła zamienia surową telemetrię w warunek, który ma znaczenie. Może to być oparte na progu, na zmianie, na anomalii lub sterowane SLO.

Alert

Reguła tworzy zdarzenie alertu z etykietami, adnotacjami i kontekstem. To tutaj powinieneś jawnie określić poziom poważności, usługę, zespół i środowisko.

Trasa (Routing)

Trasa decyduje, gdzie alert trafi. W Alertmanager obejmuje to grupowanie, inhibicję, wyciszenia i odbiorniki powiadomień. To tutaj alerting staje się operacyjny, a nie tylko techniczny.

Kanał

Ten sam alert może należeć do różnych kanałów w zależności od pilności i odbiorcy.

• Pager do natychmiastowej reakcji
• Czat do koordynacji
• E-mail do podsumowań o niskiej pilności
• System ticketowy lub przepływu pracy do zaplanowanego działania następnego

Człowiek lub automatyka

Niektóre alerty wymagają ludzkiej oceny. Niektóre powinny wywoływać zautomatyzowane łatanie. Wiele wymaga obu.

Działanie

Celem alertingu nie jest widoczność. Jest to działanie. Działaniem może być restart, rollback, failover, śledzenie problemu lub po prostu potwierdzenie.

Feedback

Ostatnim krokiem jest ten najbardziej zaniedbany. Dobre zespoły przeglądają, które alerty były użyteczne, hałaśliwe, spóźnione, źle skierowane lub brakujące. Bez tej pętli alerting ulega degradacji.

Różnica między obserwowalnością a alertingiem

Alerting należy do wnętrza obserwowalności, ale nie powinien ją pochłaniać. Dla szerszego podłoża zobacz Obserwowalność: Przewodnik po monitoringu, metrykach, Prometheus i Grafana.

Obserwowalność pomaga ludziom eksplorować systemy. Alerting przerywa ludziom pracę. To rozróżnienie jest niezręczne, ale konieczne.

Użyteczny sposób myślenia o granicy:

• Obserwowalność to szerokość.
• Alerting to selektywność.

Chcesz bogatej telemetrii i selektywnego przerywania. Powszechnym trybem błędu jest odwrotność: cienka telemetria i agresywne alerty.

Dlatego alerting powinien być oparty na starannie wybranych objawach i wpływie na biznes, a nie na każdej metryce, która wygląda na nietypową. Przeciążony węzeł, wolna zależność lub podwyższona częstotliwość błędów mogą mieć znaczenie, ale tylko jeśli implikują wpływ lub wymagają interwencji.

Podstawowe zasady dobrego projektowania alertów

Możliwość działania (Actionability)

Każdy alert powinien jasno odpowiadać na jedno pytanie:

Co powinno się stać dalej?

Jeśli nie ma jasnego następnego kroku, alert prawdopodobnie należy umieścić w panelu, raporcie lub zapleczu problemów zamiast w kanale przerywania.

Możliwość działania zazwyczaj oznacza, że alert zawiera:

• co jest zepsute
• jak bardzo jest zepsute
• gdzie to się dzieje
• co sprawdzić dalej
• runbook lub link do kontekstu śledzenia problemu

Właścicielstwo (Ownership)

Alert bez właściciela to skarga, a nie mechanizm sterowania.

Każdy alert powinien mieć jasnego właściciela w momencie projektowania, a nie w trakcie incydentu. Właścicielstwo może być zespołem, rotacją lub grupą usług, ale musi być jawne.

Kontekst

Alert powinien skrócić czas do zrozumienia, a nie tylko czas do powiadomienia.

Użyteczny kontekst często obejmuje:

• nazwę usługi
• środowisko
• region lub klastr
• aktualną wartość i próg
• ostatni trend
• prawdopodobny promień rażenia
• powiązane panele lub trasy
• link do runbooka

Selektywność

Najlepszy alert to zwykle nie ten najwcześniejszy możliwy. To najwcześniejszy alert, któremu można ufać.

Dlatego długoterminowe alerty o wysokim sygnale często przewyższają chłonne, ale hałaśliwe progi.

Odporność na szum (Noise resistance)

Szum to nie tylko objętość. To również powtarzalność i niejednoznaczność.

Dobrze zaprojektowany system alertingu tłoczy zduplikowane objawy, gdy większa przyczyna źródłowa jest już znana, grupuje powiązane alerty i trasuje je przez najmniejszą rozsądną liczbę kanałów.

Taksonomia alertów, która naprawdę pomaga

Prosta taksonomia jest zwykle lepsza niż przebiegła.

Krytyczny (Critical)

Wymagana jest natychmiastowa reakcja człowieka. To teren pagera. Krytyczne alerty powinny być rzadkie, wyraźnie przypisane i ściśle powiązane z wpływem na użytkownika lub biznes.

Wysoki (High)

Pilne, ale niekoniecznie obudzenie kogoś teraz. Często należą do czatu zespołowego i kanałów incydentowych w godzinach pracy lub w workflow on-call, który zaczyna się od triage.

Informacyjny

Przydatny do świadomości, monitorowania trendów lub zaplanowanego działania następnego. Nie należą do tej samej ścieżki co pilne incydenty.

Powszechnym błędem jest wprowadzenie zbyt wielu poziomów poważności. W praktyce zespoły często działają lepiej z małym modelem, który mapuje się czysto na oczekiwania dotyczące reakcji i kanały.

Zmęczenie alertami to problem projektowy

Zmęczenie alertami jest często opisywane jako problem ludzi. Nie jest. To głównie problem systemów.

Ludzie stają się obojętni, gdy otrzymują zbyt wiele powiadomień, które nie mają znaczenia, powtarzają się lub brakuje im jasnego działania. Złe systemy alertingu tworzą złą ludzką zachowanie.

Typowe przyczyny:

• każdy objaw staje się alertem
• brak grupowania podczas dużych awarii
• brakujące reguły inhibicji
• zły właściciel
• kanały mieszane według pilności
• progi alertów odłączone od wpływu na użytkownika
• brak pętli przeglądu po incydentach

Nie naprawisz tego lepszą melodią dzwonka. Naprawisz to projektowaniem.

Strategie reguł, które mają znaczenie

Alerty oparte na progu

To najprostsze i wciąż użyteczne.

Przykłady:

• CPU powyżej utrzymywanego progu
• głębokość kolejki powyżej limitu, w tym głębokość kolejki dead-letter i wiek wiadomości
• częstotliwość błędów powyżej progu

Działają najlepiej, gdy:

• sygnał jest stabilny
• próg jest znaczący
• zespół rozumie zakres normalny

Działają słabo, gdy:

• baza jest bardzo zmienna
• metryka jest tylko słabo powiązana z wpływem

Alerty oparte na zmianie (Rate based)

Skupiają się na zmianie w czasie, a nie na wartości bezwzględnej.

Przykłady:

• częstotliwość błędów gwałtownie wzrosła w ciągu 10 minut
• wzrost zaległości przekroczył normalny trend

Są często lepsze niż statyczne progi dla dynamicznych systemów.

Alerty oparte na objawach (Symptom based)

Skupiają się na tym, czego doświadczają użytkownicy.

Przykłady:

• podwyższona latencja żądań na krawędzi
• wzrosły awarie checkoutu
• spadła skuteczność logowania

Ten styl jest zazwyczaj bardziej odporny, ponieważ jest zgodny z rzeczywistym zdrowiem usługi.

Alerty sterowane SLO (SLO based)

Alerting sterowany SLO jest jednym z najbardziej praktycznych sposobów redukcji szumu. Zamiast alertować o każdej złej minucie, skupia się na spalaniu budżetu błędów i utrzymywanym wpływie na użytkownika. Trudniej go zaprojektować niż próg, ale zwykle bardziej zgodny z rzeczywistością.

Subiektywne zdanie: wiele zespołów próbuje skoczyć prosto do alertingu SLO, zanim mają stabilne właścicielstwo usługi lub podstawową dyscyplinę trasowania. Ta sekwencja zwykle rozczarowuje. Silne podstawy biją modną matematykę.

Trasa (Routing) jest tam, gdzie alerting staje się rzeczywisty

Trasa to nie szczegół implementacyjny. To centrum operacyjnego alertingu.

Prometheus Alertmanager czyni to jawnym. Obsługuje grupowanie, deduplikację, trasowanie, wyciszenia i inhibicję przed dostarczaniem powiadomień do odbiorników takich jak e-mail, PagerDuty, OpsGenie i platformy czatu. To dokładnie ten właściwy podział. Wykrycie bez trasowania to surowy sygnał. Trasa zamienia sygnał w reakcję.

Praktyczny model trasowania może być oparty na:

• poważności
• właścicielstwie usługi
• środowisku
• porze dnia
• oknach konserwacji
• stanie incydentu
• promieniu rażenia

Grupowanie

Grupowanie łączy podobne alerty w mniejszą liczbę powiadomień. Ma to znaczenie podczas awarii kaskadowych, gdzie jeden problem źródłowy tworzy setki objawów.

Grupowanie nie chodzi o ukrywanie szczegółów. Chodzi o ochronę ludzkiej uwagi.

Inhibicja

Inhibicja tłoczy wtórne alerty, gdy wyższy poziom przyczyny źródłowej jest już aktywny.

Jeśli cały klastr jest nieosiągalny, odbiorca nie potrzebuje fali powiadomień specyficznych dla usług, które wszystkie pośrednio mówią to samo.

Wyciszenia (Silences)

Wyciszenia to tymczasowe wyciszenie z jasnym zakresem i granicami czasowymi. Są użyteczne podczas konserwacji, migracji i znanych incydentów.

Wyciszenie nie jest rozwiązaniem. To tymczasowa kontrola operacyjna.

Wybór odpowiedniego kanału alertu

Kanał powinien pasować do kształtu reakcji.

Systemy pagerowe

Pager jest dla reakcji pilnej. Jeśli alert musi obudzić kogoś, nie powinien zaczynać się w pokoju czatu.

Platformy czatu

Czat jest silny do współpracy, triage i przepływów z udziałem człowieka. To tutaj wzorce integracji Slacka dla alertów i przepływów pracy i wzorce integracji Discorda dla alertów i pętli sterowania stają się użytecznymi interfejsami systemowymi, a nie prostymi zlewniami wiadomości.

Użyj czatu, gdy:

• zespół potrzebuje wspólnego kontekstu
• reakcja jest współpracująca
• przycisk, polecenie lub reakcja mogą wywołać kontrolowane działanie
• pilność jest wysoka, ale niekoniecznie warta pagera

E-mail

E-mail jest z natury niskiej pilności. Jest w porządku do podsumowań, trendów i działań następczych. Jest słaby do reakcji na incydenty.

Panele

Panele są do eksploracji, nie do przerywania. Uzupełniają alerty. Nie zastępują ich.

Alerting z udziałem człowieka (Human in the loop)

Dobry alert nie zawsze kończy się potwierdzeniem. Czasem zaczyna przepływ pracy.

To tutaj platformy czatu stają się interesujące. Alert może wejść do Slacka lub Discorda z kontekstem i powierzchnią interakcji. Człowiek może potwierdzić, zatwierdzić, wyciszyć, eskalować lub wywołać bezpieczne działanie. Zamienia to alerting z rozgłoszeniowym w kontrolowaną interakcję.

Ten wzorzec należy do punktu przecięcia obserwowalności i wzorców integracji:

• obserwowalność decyduje, co jest warte pokazania
• wzorce integracji decydują, jak ludzie reagują przez narzędzia

Dlatego ta strona powinna odsyłać do artykułów o platformach czatu, a nie je absorbować.

Co należy zawrzeć w wiadomości alertu

Zaskakująco duża liczba problemów z alertingiem to problemy z projektowaniem wiadomości.

Użyteczna wiadomość alertu zazwyczaj zawiera:

• krótkie stwierdzenie problemu
• usługę i środowisko
• poważność
• objaw i wartość
• wpływ na użytkownika lub system
• pierwszy krok śledzenia
• link do runbooka lub panelu

Słaby alert mówi:

wykryto wysoką latencję

Silniejszy alert mówi:

latencja checkoutu p95 powyżej 1.8s przez 15m w prod-eu
wpływ: checkout użytkownika jest zdegradowany
następny krok: sprawdź zależność płatności upstream i panel budżetu błędów
runbook: [[siteurl]]/runbooks/checkout-latency

Ta różnica nie jest kosmetyczna. Jest operacyjna.

Antywzorce, które się powtarzają

Alertowanie na wszystkim, co można zmierzyć

To najszybsza droga do szumu. Obserwowalność kwitnie na szerokości. Alerting nie.

Mieszanie poziomów pilności w jednym kanale

Jeśli krytyczne strony, alerty informacyjne i luźna dyskusja dzielą tę samą ścieżkę, odbiorcy uczą się złego nawyku.

Brak właścicielstwa w etykietach lub trasowaniu

Alert dociera do człowieka, ale nie do właściwego człowieka.

Brak deduplikacji lub grupowania

Ten sam incydent produkuje dziesiątki powiadomień. Ludzie przestają ufać systemowi.

Alerty bez przeglądu feedbacku

System ciągle wysyła te same złe alerty, ponieważ nikt nie zamyka pętli projektowej.

Alerty, które wymagają czytania kodu, aby je zrozumieć

Osoba na dyżurze potrzebuje następnego kroku, nie układanki.

Praktyczny widok architektury

Minimalny, ale realistyczny model:

metryki logi trasy
        |
        v
   reguły wykrywania
        |
        v
   alert manager
   - grupowanie
   - deduplikacja
   - inhibicja
   - wyciszenia
   - trasowanie
        |
        v
odbiorcy i kanały
- pager
- czat
- e-mail
- przepływ pracy
        |
        v
człowiek lub automatyka
        |
        v
łatanie i przegląd

Ten model skaluje się, ponieważ oddziela obszary zainteresowań. Pasuje również do tego, jak budowane są rzeczywiste stosy alertingu.

Podsumowanie

Alerting to nie skutek uboczny monitoringu. To system reakcji zbudowany na wierzchu obserwowalności.

Silna wersja alertingu jest selektywna, trasa, kontekstowa i podlegająca przeglądowi. Skróca czas do działania bez zatapiania ludzkiej uwagi. Wykorzystuje grupowanie, inhibicję, wyciszenia i właściwy wybór kanału, aby zachować zaufanie. I traktuje platformy czatu jako interfejsy reakcji, a nie zamienniki strategii.