Alerty i eskalacja
Ułożysz alert wskazujący wpływ na użytkownika i procedurę potwierdzenia oraz eskalacji.
1. Krótka teoria
Dobry alert mówi, że trzeba podjąć działanie, a nie tylko że pojedyncza liczba drgnęła. Alert oparty na symptomie, na przykład wysoki odsetek błędów orders-api, pokazuje wpływ na użytkownika. Alert oparty na przyczynie, na przykład mało miejsca na dysku app-db, pomaga zdiagnozować źródło; oba są przydatne, lecz nie muszą wysyłać dwóch identycznych powiadomień. Próg określa wartość wyzwalającą, a czas trwania warunku odróżnia trwały problem od pojedynczego skoku. Zbyt krótki czas powoduje flapping, czyli częste przełączanie stanu alertu. Zbyt wiele nieistotnych powiadomień prowadzi do alert fatigue i pomijania ważnych sygnałów. Poziom severity powinien odpowiadać rzeczywistemu wpływowi i wymaganej szybkości reakcji. Routing kieruje alert do właściwego zespołu, acknowledgement potwierdza, że ktoś go przejął, a eskalacja przekazuje go dalej, gdy nie ma odpowiedzi. Zły alert brzmi „CPU > 60% przez chwilę” bez kontekstu. Lepszy brzmi „ponad 5% żądań kończy się 5xx przez 10 minut” z usługą, oknem, dashboardem i runbookiem. Warto sprawdzić także niską liczbę żądań, bo procent przy małej próbie bywa mylący.
2. Przykłady komend
curl --fail --max-time 2 http://127.0.0.1:8000/health
Potwierdza, czy alarmowana instancja odpowiada.
$ curl --fail --max-time 2 http://127.0.0.1:8000/health
journalctl -u orders-api --since '10 minutes ago' -p warning --no-pager
Sprawdza zdarzenia w oknie alertu.
$ journalctl -u orders-api --since '10 minutes ago' -p warning --no-pager
date --iso-8601=seconds
Zapisuje czas przyjęcia alertu.
$ date --iso-8601=seconds
df -h /var
Sprawdza, czy alarm o miejscu ma potwierdzenie na hoście.
$ df -h /var
cat monitoring/alerts.yml
Pokazuje ćwiczeniową regułę z progiem, minimalnym ruchem i czasem trwania.
groups:
- name: orders-api
rules:
- alert: OrdersApiHighErrorRate
expr: (sum(rate(http_requests_total{service="orders-api",status=~"5.."}[5m])) / clamp_min(sum(rate(http_requests_total{service="orders-api"}[5m])), 0.001) > 0.05) and (sum(rate(http_requests_total{service="orders-api"}[5m])) > 1)
for: 10m
labels:
severity: warning
systemctl status orders-api --no-pager
Zestawia alert z aktualnym stanem procesu.
$ systemctl status orders-api --no-pager3. Zadanie praktyczne
orders-api dwa alerty: symptom „ponad 5% odpowiedzi 5xx przez 10 minut przy wystarczającym ruchu” oraz przyczynę „mało miejsca na dysku bazy”. Dla każdego podaj próg, okno, severity, odbiorcę, pierwszy test i odnośnik do runbooka. Zapisz, kiedy operator potwierdza alert i po jakim czasie bez reakcji następuje eskalacja. Wyjaśnij, dlaczego pojedynczy skok CPU nie powinien budzić dyżurnego.
4. Typowe błędy
- Wywoływanie alarmu z jednego chwilowego skoku bez czasu trwania.
- Wysyłanie wielu powiadomień o tym samym objawie do różnych osób bez koordynacji.
- Nadawanie najwyższej severity każdemu ostrzeżeniu zasobowemu.
- Brak właściciela alertu, runbooka i zasad eskalacji.
- Interpretowanie wysokiego procentu błędów bez liczby żądań.
5. Podsumowanie
Alert powinien wskazywać wpływ, czas trwania, właściciela i działanie. Progi i okna ograniczają flapping, a jasne severity, potwierdzenie i eskalacja chronią dyżur przed chaosem i zmęczeniem alertami.