Alerty, które pomagają: od sygnału do działania

Zacznij od objawu, który wymaga reakcji

Dokumentacja Prometheusa zaleca alarmowanie o objawach problemów odczuwanych przez użytkowników oraz unikanie powiadomień, po których nie ma nic do zrobienia. Przy każdej istniejącej regule zapisz więc jedno zdanie: co zrobi osoba, która dostanie ten alarm? Jeśli odpowiedź brzmi wyłącznie „popatrzy na wykres”, reguła wymaga dopracowania.

Wysokie użycie procesora może być normalnym skutkiem zaplanowanego przetwarzania. Brak zakończenia tego przetwarzania przed momentem, w którym potrzebny jest wynik, ma już konkretny skutek. Próg techniczny nadal bywa przydatny, ale trzeba umieć powiązać go z ograniczeniem lub ryzykiem dla usługi.

Daj odbiorcy kontekst w samej wiadomości

Powiadomienie powinno wskazywać usługę, środowisko, zauważony objaw i moment jego wystąpienia. Dodaj link do odpowiedniego widoku oraz krótkiej instrukcji sprawdzenia. Odbiorca nie powinien zgadywać, czy alarm dotyczy produkcji, testów, czy systemu wycofanego z użycia.

Przykładowy opis może brzmieć: „Przetwarzanie plików nie zakończyło się w oczekiwanym oknie. Sprawdź ostatnie wykonanie i kolejkę zadań”. To ilustracja konstrukcji komunikatu. Faktyczne kryterium i instrukcję trzeba uzgodnić z osobą odpowiedzialną za daną usługę, uwzględniając jej zwykły harmonogram.

Ogranicz powtarzanie tej samej informacji

Alertmanager potrafi grupować podobne alarmy i kierować je do właściwych odbiorców. Pomaga to wtedy, gdy jeden problem powoduje serię powiązanych objawów. Zamiast osobnej wiadomości dla każdego elementu można otrzymać wspólne powiadomienie z informacją o zakresie zdarzenia.

Ustal również, jak traktować krótkie zaburzenia oraz planowane prace. Wybrane alarmy można czasowo wyciszać, z określonym końcem i uzasadnieniem. Grupowanie i wyciszenie zmieniają sposób powiadamiania; nie naprawiają przyczyny. Osoba prowadząca prace nadal powinna sprawdzić, czy po ich zakończeniu usługa i monitoring wróciły do zwykłego działania.

Oddziel awarię usługi od braku pomiaru

W regułach zarządzanych przez Grafanę stan No Data oznacza poprawnie wykonane zapytanie bez punktów danych. Error oznacza problem z wykonaniem zapytania. To różne informacje i mogą wymagać innych czynności niż przekroczenie progu przez badaną usługę.

Sprawdź, jakie zachowanie wybrano dla obu przypadków oraz do kogo trafiają powiadomienia. Zachowanie ostatniego stanu może ograniczyć chwilowe zmiany komunikatów, ale samo nie wyjaśnia dłuższej utraty pomiarów. Dla ważnego systemu ustal osobno, po czym rozpoznasz, że nie masz już aktualnej informacji o jego stanie.

Przetestuj drogę od reguły do człowieka

Test przycisku wysyłania wiadomości potwierdza tylko część mechanizmu. Zaplanuj kontrolowane zdarzenie, które uruchomi regułę, przejdzie przez routing i dotrze do uzgodnionego odbiorcy. Uprzedź zespół o ćwiczeniu i sprawdź także komunikat o ustąpieniu problemu. Prometheus zaleca kontrolę działania samej infrastruktury monitoringu.

Hipotetyczny scenariusz: testowa usługa przestaje odpowiadać, reguła się aktywuje, lecz powiadomienie trafia na nieużywaną skrzynkę. Wykres jest poprawny, a reakcja nie następuje. Wynik ćwiczenia powinien obejmować naprawę odbiorcy i powtórzenie całej próby.

Po rzeczywistym zdarzeniu oceń, czy komunikat pomógł znaleźć problem. Usuń nieaktualne odsyłacze, dopisz brakujący krok i rozdziel alarmy wymagające pilnej reakcji od spraw możliwych do zaplanowania. Przy zmianie właściciela usługi aktualizuj również odbiorców jej powiadomień.