Alerty w Grafanie i Prometheusie – jak automatycznie wykrywać awarie i problemy z wydajnością?

Wprowadzenie: czym jest alertowanie w stacku Grafana + Prometheus i jakie problemy rozwiązuje?

Dashboard pokaże rosnące opóźnienia aplikacji — pod warunkiem, że ktoś właśnie na niego patrzy. Alertowanie pozwala wykryć taki problem bez ciągłego obserwowania wykresów. System automatycznie sprawdza zdefiniowane warunki i sygnalizuje sytuacje wymagające uwagi: od niedostępnej usługi po stopniowe pogarszanie się jej wydajności. Celem nie jest jednak informowanie o każdej zmianie metryki, lecz wskazanie, kiedy potrzebna jest reakcja.

W stacku Grafana + Prometheus podstawą takiego monitoringu są metryki, czyli liczbowe pomiary stanu infrastruktury i aplikacji zbierane w czasie. Mogą opisywać między innymi liczbę błędów, czas obsługi żądań, zużycie pamięci czy zajętość dysku. Alertowanie nadaje tym pomiarom znaczenie operacyjne: pozwala rozpoznać, że obserwowana sytuacja spełnia warunki uznane za niepożądane, na przykład opóźnienia pozostają zbyt wysokie przez określony czas.

Prometheus i Grafana pełnią uzupełniające się, ale nie identyczne funkcje. Prometheus zbiera i przechowuje metryki oraz umożliwia ocenę reguł alertowych opartych na tych danych. Grafana służy przede wszystkim do ich wizualizacji, a dzięki Grafana Alerting pozwala również definiować alerty na podstawie obsługiwanych źródeł danych — nie tylko Prometheusa. Alertowanie nie musi więc być związane z konkretnym wykresem ani ograniczać się do jednego sposobu konfiguracji.

W praktyce automatyczne wykrywanie problemów pomaga w trzech obszarach:

• Awarie i utrata dostępności — skraca czas między wystąpieniem problemu a jego zauważeniem przez zespół, bez czekania na zgłoszenia użytkowników.
• Degradacja wydajności — pozwala wychwycić sytuację, w której usługa nadal działa, ale odpowiada coraz wolniej, częściej zwraca błędy lub nie nadąża z przetwarzaniem zadań.
• Wyczerpywanie zasobów — pomaga dostrzec narastające zagrożenia, takie jak malejąca ilość wolnego miejsca na dysku, zanim doprowadzą do przerwy w działaniu.

Warto przy tym odróżnić wykrycie objawu od ustalenia przyczyny. Alert o wysokich opóźnieniach wskazuje, że jakość działania usługi się pogorszyła, ale sam nie rozstrzyga, czy odpowiada za to baza danych, sieć czy ostatnie wdrożenie. Jest sygnałem do diagnostyki, nie jej zamiennikiem. Dobrze zaprojektowane alertowanie ogranicza potrzebę ręcznej kontroli i przyspiesza reakcję, lecz jego skuteczność zależy od tego, czy monitorowane metryki rzeczywiście odzwierciedlają stan usług i problemy odczuwane przez użytkowników.

Architektura i przepływ danych: gdzie powstaje alert i jak trafia do odbiorcy?

W stacku Grafana + Prometheus trzeba rozdzielić trzy zadania: zbieranie metryk, ocenę warunków alarmowych i dostarczanie powiadomień. Alert powstaje w komponencie, który wykonuje regułę alertową — może to być Prometheus albo Grafana Alerting. Alertmanager obsługuje natomiast przekazane mu alerty i decyduje o wysyłce powiadomień. Sam nie odpytuje metryk ani nie sprawdza, czy infrastruktura przekroczyła zadany próg.

W Cognity często słyszymy pytania, jak w praktyce rozdzielić odpowiedzialność tych komponentów — odpowiadamy na nie także na blogu.

Prometheus: od zebrania metryk do aktywacji alertu

Prometheus cyklicznie pobiera metryki z monitorowanych aplikacji oraz eksporterów, czyli komponentów udostępniających dane o systemach i usługach. Ten proces, nazywany scrapingiem, zasila bazę szeregów czasowych. Niezależnie od harmonogramu pobierania danych Prometheus wykonuje skonfigurowane reguły alertowe, oparte na zapytaniach PromQL.

Jeśli wynik zapytania spełnia warunek reguły, powstaje instancja alertu dla konkretnego zestawu etykiet — na przykład wskazującego usługę lub host. Gdy reguła wymaga utrzymania się problemu przez określony czas, alert najpierw przechodzi w stan pending. Dopiero po spełnieniu tego wymagania osiąga stan firing i jest przekazywany do skonfigurowanego Alertmanagera. Bez takiego okresu oczekiwania może stać się aktywny już przy pierwszej ocenie wykrywającej problem.

Alertmanager: od aktywnego alertu do powiadomienia

Alertmanager otrzymuje informacje o alercie, w tym jego etykiety, adnotacje i dane o czasie aktywności. Na tej podstawie stosuje konfigurację routingu oraz zasady obsługi powiadomień. Może łączyć powiązane alerty w jedną wiadomość, ograniczać duplikaty i wstrzymywać wysyłkę zgodnie z obowiązującymi wyciszeniami.

Typowy przepływ wygląda więc następująco: aplikacja lub eksporter → Prometheus → reguła alertowa → Alertmanager → kanał powiadomień. Odbiorcą może być skrzynka e-mail, kanał Slacka lub system obsługi incydentów. Grafana nie musi uczestniczyć w tej ścieżce: jej niedostępność nie zatrzymuje oceny reguł przez Prometheusa ani wysyłki przez działającego Alertmanagera.

Grafana Alerting: alternatywne miejsce wykonywania reguł

W przypadku reguł zarządzanych przez Grafanę to jej mechanizm alertowania cyklicznie odpytuje źródła danych, wykonuje skonfigurowane wyrażenia i ocenia warunek alarmowy. Prometheus może wówczas dostarczać metryki, ale stan alertu wyznacza Grafana, a nie silnik reguł Prometheusa. Takie reguły działają po stronie serwera — nie wymagają otwartego dashboardu ani zalogowanego użytkownika.

W standardowej ścieżce alert trafia następnie do wbudowanego w Grafanę Alertmanagera. Polityki powiadomień kierują go do odpowiednich punktów kontaktowych, które określają sposób dostarczenia wiadomości. Przepływ ma wtedy postać: Prometheus jako źródło metryk → reguła Grafana Alerting → obsługa powiadomień w Grafanie → kanał powiadomień. Grafana umożliwia również korzystanie z innych obsługiwanych źródeł danych.

Samo wyświetlanie reguły w interfejsie Grafany nie oznacza jednak, że jest ona tam wykonywana. Reguły zarządzane po stronie źródła danych pozostają oceniane przez właściwy system. Przy analizowaniu awarii alertowania najważniejsze jest więc ustalenie dwóch rzeczy: który komponent ocenia regułę i który odpowiada za wysyłkę. Aktywny alert oraz dostarczone powiadomienie to dwa odrębne etapy tego samego procesu.

Prometheus Alertmanager vs Grafana Alerting — różnice i wybór podejścia

To porównanie dotyczy w praktyce dwóch podejść: reguł ocenianych przez Prometheusa z powiadomieniami obsługiwanymi przez Alertmanagera oraz reguł zarządzanych i ocenianych przez Grafana Alerting. Sam Alertmanager nie odpytuje metryk ani nie sprawdza warunków alarmowych — przyjmuje już utworzone alerty i zarządza ich dalszą obsługą. Grafana Alerting obejmuje również definiowanie i ocenę reguł. Rozróżnienie ma znaczenie przy wyborze miejsca, w którym będzie działać logika wykrywania problemów.

Najważniejsze różnice

Kiedy wybrać Prometheusa z Alertmanagerem?

To mocny wybór, gdy podstawą monitoringu są metryki w Prometheusie, a reguły alertów traktujecie jak kod. Zespół może wersjonować zmiany, poddawać je przeglądowi i wdrażać razem z konfiguracją infrastruktury. Takie podejście dobrze odpowiada potrzebom zespołów platformowych i SRE, które znają PromQL i chcą utrzymać alertowanie niezależnie od warstwy wizualizacji.

Przykładowo: jeśli Grafana służy głównie do prezentowania stanu klastra i usług, jej awaria nie powinna pozbawiać zespołu informacji o problemach tych usług. Reguły działające w Prometheusie z osobnym Alertmanagerem pozwalają zachować tę niezależność. Nie oznacza to jednak automatycznej odporności całego rozwiązania — sam Prometheus i Alertmanager również wymagają odpowiedniego utrzymania.

Ograniczeniem jest większy nacisk na konfigurację i znajomość PromQL. Jeśli potrzebne są warunki wykorzystujące także dane spoza Prometheusa, trzeba zapewnić ich dostępność w odpowiedniej postaci albo zastosować dodatkowy mechanizm oceny reguł. Alertmanager nie rozwiązuje tego problemu, ponieważ nie analizuje danych źródłowych.

Kiedy wybrać Grafana Alerting?

Grafana Alerting sprawdza się, gdy zespół potrzebuje wspólnego miejsca do zarządzania alertami z różnych obsługiwanych źródeł danych. Przykładem jest środowisko, w którym metryki znajdują się w Prometheusie, a logi w Lokim. Reguły zarządzane przez Grafanę mogą wykorzystywać zapytania do tych źródeł, a w uzasadnionych przypadkach łączyć ich wyniki w jednym warunku.

Zaletą jest wygodna praca w interfejsie: łatwiej podejrzeć wyniki zapytań i sprawdzić, dlaczego warunek został spełniony. Nie oznacza to rezygnacji z automatyzacji — konfigurację można również utrzymywać jako kod. Podejście to bywa szczególnie użyteczne, gdy reguły współtworzą zespoły aplikacyjne korzystające na co dzień z Grafany.

Kosztem jest włączenie komponentów alertujących Grafany do krytycznej ścieżki wykrywania awarii. Reguły korzystające z wielu źródeł wprowadzają też więcej zależności: problem z dostępem do jednego z nich może uniemożliwić prawidłową ocenę warunku.

Wybór oprzyj przede wszystkim na źródłach danych, sposobie utrzymania konfiguracji i wymaganej niezależności alertowania. Dla monitoringu opartego głównie na metrykach oraz pracy w modelu GitOps naturalnym punktem wyjścia jest Prometheus z Alertmanagerem. Przy wielu źródłach danych i potrzebie wspólnego interfejsu zarządzania przewagę może mieć Grafana Alerting. Sama obecność dashboardów w Grafanie nie jest powodem, by przenosić do niej ocenę wszystkich reguł.

Jak połączyć Grafana Alerting z Prometheusem i Alertmanagerem?

Oba podejścia mogą działać równolegle, pod warunkiem że jasno rozdzielisz odpowiedzialność za reguły i wysyłkę powiadomień. Reguły dotyczące infrastruktury i usług mogą pozostać w Prometheusie, a Grafana Alerting może obsługiwać przypadki wymagające korzystania z innych źródeł danych. Nie trzeba przenosić wszystkich alertów do jednego narzędzia — warto natomiast ujednolicić ich etykiety, miejsce dostarczania powiadomień i sposób zarządzania konfiguracją. W Cognity omawiamy integrację tych narzędzi zarówno od strony technicznej, jak i praktycznej – zgodnie z realiami pracy uczestników szkoleń.

Podłącz źródło metryk i osobno skonfiguruj przekazywanie alertów

Dodanie Prometheusa jako źródła danych w Grafanie pozwala wykorzystać jego metryki w regułach zarządzanych przez Grafana Alerting. Nie oznacza jednak automatycznego przekazywania tych alertów do zewnętrznego Alertmanagera. To osobna integracja: Alertmanager należy dodać jako odpowiednie źródło danych i włączyć wysyłanie do niego alertów zarządzanych przez Grafanę. Nazwy i dostępność ustawień zależą od wersji oraz sposobu wdrożenia Grafany.

W takim układzie Prometheus nadal ocenia własne reguły i wysyła ich wyniki do Alertmanagera, natomiast Grafana ocenia swoje reguły i przekazuje do niego własne alerty. Wspólny Alertmanager staje się punktem obsługi powiadomień z obu systemów. Przed uruchomieniem integracji sprawdź łączność z jego API, ustawienia TLS, ewentualne uwierzytelnianie oraz uprawnienia sieciowe po stronie Grafany.

Samo wyświetlanie zewnętrznego Alertmanagera w interfejsie Grafany nie oznacza też, że całą jego konfigurację można tam edytować. W przypadku Prometheus Alertmanager konfigurację odbiorców i routingu utrzymuje się po jego stronie; możliwości zarządzania przez Grafanę zależą od rodzaju podłączonej implementacji.

Ustal wspólny kontrakt etykiet

Alerty z obu źródeł powinny opisywać usługę i jej otoczenie w ten sam sposób. Ustal wspólne znaczenie etykiet, takich jak service, team, environment i severity, oraz dopuszczalne wartości. Jeżeli jeden system używa environment="production", a drugi env="prod", wspólna polityka powiadomień nie potraktuje ich automatycznie jako tego samego środowiska.

Etykiety powinny zawierać stabilne informacje potrzebne do identyfikacji i obsługi alertu. Bieżącą wartość metryki, opis problemu czy odnośnik do dashboardu umieszczaj w adnotacjach. Zwróć również uwagę na etykiety dodawane przez Grafanę, np. związane z folderem reguły. Podobny opis i identyczna nazwa alertu nie gwarantują deduplikacji — znaczenie ma cały zestaw etykiet. Dlatego jednego warunku awarii nie warto stale oceniać niezależnie w obu systemach.

Wspólne kanały bez podwójnej wysyłki

Najbardziej przejrzysty wariant to utrzymywanie docelowych integracji powiadomień w jednym Alertmanagerze. Alternatywnie można pozostawić osobne ścieżki wysyłki w Grafanie i Alertmanagerze, kierujące do tych samych kanałów, ale wtedy konfigurację odbiorców trzeba utrzymywać w dwóch miejscach.

Przy centralizacji sprawdź, czy Grafana nie wysyła równolegle własnych powiadomień dla alertów przekazywanych do zewnętrznego Alertmanagera. Samo włączenie przekazywania nie powinno być traktowane jako wyłączenie dotychczasowej ścieżki. Test integracji ma potwierdzić nie tylko dostarczenie alertu, lecz także brak niezamierzonych duplikatów.

Przechowuj konfigurację w kontrolowanym źródle

Reguły Prometheusa, konfigurację Alertmanagera oraz zasoby Grafana Alerting warto wersjonować w repozytorium Git. Dla Grafany można wykorzystać obsługiwany provisioning, API lub Terraform — zależnie od środowiska. Każdy zasób powinien mieć jedno źródło prawdy: ręczna edycja tej samej reguły w interfejsie i równoległe zarządzanie nią z kodu prowadzą do rozbieżności lub nadpisywania zmian.

Wspólnie przeglądaj zmiany etykiet i konfiguracji odbiorców, ponieważ modyfikacja reguły może zmienić adresata powiadomienia. Sekrety integracji przechowuj poza repozytorium. Przy migracji między narzędziami najpierw sprawdź nową regułę bez powiadamiania produkcyjnych odbiorców, a następnie przełącz odpowiedzialność za wysyłkę i wyłącz poprzednią regułę.

Przykładowe reguły alertów: CPU, niedostępne targety, opóźnienia i dostępność SLO

Dobra reguła alertu opisuje konkretny problem, a nie tylko przekroczenie przypadkowej wartości. Wysokie wykorzystanie CPU nie zawsze oznacza przeciążenie, nieudany scrape nie dowodzi awarii aplikacji, a wzrost liczby błędów należy oceniać względem całego ruchu. Poniższe zapytania PromQL pozwalają rozróżnić te sytuacje. Podane progi są punktem wyjścia do strojenia, nie uniwersalną konfiguracją produkcyjną.

Przykłady zakładają metryki z node_exportera oraz instrumentację HTTP opartą na klasycznym histogramie. Nazwy metryk aplikacyjnych i etykiet trzeba dopasować do własnego środowiska; selektor job="api" oznacza tutaj monitorowane API. Parametr for wskazany przy przykładach określa, jak długo warunek musi pozostawać spełniony przed przejściem alertu w stan firing.

CPU saturation: wykrywaj oczekiwanie na procesor, nie tylko jego zajętość

Wykorzystanie CPU powyżej 90% może być normalne dla zadań obliczeniowych. O saturacji lepiej świadczy sytuacja, w której zadania czekają na dostęp do procesora. Na Linuksie z obsługą PSI, przy włączonym kolektorze pressure w node_exporterze, można wykorzystać licznik node_pressure_cpu_waiting_seconds_total:

rate(node_pressure_cpu_waiting_seconds_total[5m]) > 0.20

Warunek oznacza, że w pięciominutowym oknie przez ponad 20% czasu przynajmniej część zadań oczekiwała na CPU. Nie jest to procent wykorzystania procesora. Propozycja początkowa: severity="warning", próg 20%, for: 10m. Taki alert wskazuje presję na zasoby hosta; nie identyfikuje jeszcze procesu ani kontenera odpowiedzialnego za problem.

Jeżeli metryka PSI nie jest dostępna, reguła nie zastępuje jej automatycznie pomiarem zajętości CPU — zwróci pusty wynik. Przed wdrożeniem sprawdź obecność metryki oraz typowy poziom presji dla danego rodzaju obciążenia.

Target down i brak scrape: odróżnij nieudany odczyt od zniknięcia serii

Prometheus zapisuje up=1 po udanym pobraniu metryk i up=0, gdy scrape się nie powiedzie. Podstawowy warunek dla monitorowanego API wygląda następująco:

up{job="api"} == 0

Propozycja początkowa: severity="warning", for: 2m przy interwale scrape rzędu 15–30 sekund. Reguła zachowuje etykiety targetu, w tym zwykle instance, dzięki czemu wskazuje konkretny niedostępny endpoint metryk. Przyczyną może być awaria procesu, ale również timeout, problem sieciowy lub błąd uwierzytelniania. Niedostępność endpointu metryk nie musi oznaczać niedostępności samej usługi.

Innego warunku wymaga sytuacja, w której serie całkowicie zniknęły, na przykład po zmianie konfiguracji wykrywania usług:

absent_over_time(up{job="api"}[5m])

To zapytanie wykrywa brak jakichkolwiek próbek pasujących do selektora przez pięć minut. Można rozpocząć od for: 1m. Nie wykryje jednak zniknięcia pojedynczej instancji, jeśli inne instancje tego samego joba nadal dostarczają próbki. Do takiej kontroli potrzebna jest informacja o oczekiwanym zestawie targetów lub selektor jednoznacznie wskazujący wymagany target.

Wysokie opóźnienia: percentyl zamiast średniej

Średni czas odpowiedzi może wyglądać poprawnie nawet wtedy, gdy część użytkowników doświadcza wielosekundowych opóźnień. Dla klasycznego histogramu http_request_duration_seconds można obliczyć p95, czyli oszacowanie czasu, którego nie przekracza 95% żądań:

(
  histogram_quantile(
    0.95,
    sum by (job, le) (
      rate(http_request_duration_seconds_bucket{job="api"}[5m])
    )
  ) > 0.5
)
and on (job)
(
  sum by (job) (
    rate(http_request_duration_seconds_count{job="api"}[5m])
  ) >= 1
)

Propozycja początkowa: p95 powyżej 500 ms, for: 10m, severity="warning". Drugi warunek wymaga średnio co najmniej jednego żądania na sekundę, ograniczając alerty oparte na bardzo małej próbie. Dla usług o niewielkim ruchu potrzebne będzie dłuższe okno lub inny minimalny wolumen.

Zapytanie agreguje ruch wszystkich instancji danego joba. Jeżeli endpointy mają różne wymagania czasowe, oceniaj je oddzielnie, używając etykiety z szablonem trasy, a nie surowego URL. Dokładność p95 zależy również od granic bucketów — powinny obejmować okolice progu 500 ms.

Niska dostępność: tempo zużywania budżetu błędów SLO

Załóżmy SLO dostępności wynoszące 99,9%, w którym błędem jest odpowiedź HTTP 5xx. Dopuszczalny udział błędów wynosi wtedy 0,1%. Udział przekraczający 1% oznacza ponad dziesięciokrotnie szybsze zużywanie budżetu błędów niż tempo odpowiadające temu celowi.

(
  (
    sum by (job) (
      increase(http_requests_total{job="api", code=~"5.."}[1h])
    )
    or on (job)
    (
      0 * sum by (job) (
        increase(http_requests_total{job="api"}[1h])
      )
    )
  )
  /
  sum by (job) (
    increase(http_requests_total{job="api"}[1h])
  ) > 0.01
)
and on (job)
(
  sum by (job) (
    increase(http_requests_total{job="api"}[1h])
  ) >= 1000
)

Propozycja początkowa: ponad 1% błędów w godzinę przy co najmniej 1000 żądań, for: 5m. Fragment z or on (job) przyjmuje zero błędów, gdy istnieje licznik ruchu, ale nie ma serii dla kodów 5xx. Nie zamienia całkowitego braku telemetrii w poprawny wynik.

To uproszczony alert na podwyższone zużycie budżetu, a nie dowód naruszenia SLO w całym okresie rozliczeniowym. Jeśli usługa wymaga natychmiastowej reakcji na takie tempo, uzasadniona może być etykieta severity="critical". Trzeba też pamiętać, że licznik po stronie aplikacji nie obejmuje żądań, które do niej nie dotarły; definicja dostępności może wymagać pomiaru na ingressie lub zewnętrznego testu.

Etykiety, które warto dołączyć do reguł

Do przykładów warto dodać stabilne etykiety: severity, team, service i environment, zgodne z rzeczywistym podziałem odpowiedzialności. Zachowaj również etykiety identyfikujące źródło problemu, takie jak job i — dla alertów hostowych — instance. Jeśli jedno zapytanie obejmuje wiele klastrów lub środowisk, uwzględnij ich etykiety zarówno w agregacjach sum by (...), jak i dopasowaniach on (...), aby nie połączyć niezależnych usług.

Bieżącą wartość pomiaru, opis objawu i odnośnik do instrukcji postępowania umieszczaj w adnotacjach, nie w etykietach. Zmieniająca się wartość w etykiecie zmienia tożsamość alertu i może uniemożliwić utrzymanie warunku przez wymagany czas for.

6. Routing powiadomień: Slack, e-mail, PagerDuty i kontrola szumu alertowego

Wykrycie problemu nie wystarczy — powiadomienie musi trafić do zespołu, który może zareagować, i do kanału odpowiadającego pilności zdarzenia. Routing pozwala kierować alerty na podstawie etykiet, takich jak team, service, environment czy severity. Dzięki temu awaria usługi produkcyjnej może uruchomić dyżur, a ostrzeżenie ze środowiska testowego trafić wyłącznie na kanał techniczny.

Dobór kanału: Slack, e-mail czy PagerDuty?

W Alertmanagerze odbiorców definiuje się jako receivers, a reguły kierowania powiadomień w drzewie route. W Grafana Alerting analogiczną rolę pełnią contact points oraz notification policies. Jeden odbiorca lub punkt kontaktowy może obejmować kilka integracji, ale wysyłanie każdego alertu wszystkimi kanałami zwykle tylko zwiększa szum.

Każde drzewo routingu powinno mieć odbiorcę domyślnego, aby alert bez oczekiwanej etykiety nie pozostał bez obsługi. Trzeba też świadomie ustalić, czy po dopasowaniu jednej gałęzi mają być sprawdzane kolejne. Nakładające się reguły mogą celowo wysyłać powiadomienie do kilku miejsc, ale mogą również powodować niezamierzone duplikaty.

Grupowanie i deduplikacja: mniej wiadomości, pełniejszy kontekst

Grupowanie łączy powiązane alerty w jedno powiadomienie. Przykładowo zestaw etykiet cluster, service i alertname pozwala zebrać problemy wielu instancji tej samej usługi. Dodanie do grupowania etykiety instance rozdzieli je na osobne grupy — co przy rozległej awarii może oznaczać dziesiątki wiadomości.

Tempo wysyłki kontrolują trzy ustawienia:

• group_wait — czas oczekiwania przed pierwszym powiadomieniem dla nowej grupy; pozwala zebrać alerty pojawiające się niemal jednocześnie.
• group_interval — odstęp określający, jak często mogą być wysyłane powiadomienia o zmianach w istniejącej grupie.
• repeat_interval — odstęp przed ponownym przypomnieniem o nadal aktywnych alertach, jeśli grupa się nie zmieniła.

Deduplikacja ogranicza wielokrotne wysyłanie tej samej informacji, ale nie zastępuje grupowania ani nie wyklucza okresowych przypomnień. Nie należy zakładać, że niezależne ścieżki wysyłki z Grafany i Alertmanagera automatycznie usuną wzajemne duplikaty. Jeśli oba systemy zgłaszają ten sam problem, najlepiej wyznaczyć jedną odpowiedzialną ścieżkę powiadamiania.

Inhibicje: wyciszanie skutków znanej awarii

Inhibicja w Alertmanagerze blokuje powiadomienia o wybranych alertach, gdy aktywny jest inny alert spełniający określone warunki. Przykładowo alert o niedostępności klastra może tłumić powiadomienia o niedostępnych usługach w tym klastrze. Alerty zależne nadal istnieją — nie generują jedynie kolejnych zgłoszeń.

Warunek wspólnych etykiet, np. cluster i environment, musi ograniczać inhibicję do właściwego obszaru. Zbyt szerokie dopasowanie może ukryć niezależną awarię. Nie należy też utożsamiać inhibicji Alertmanagera z grupowaniem lub czasowym wyciszaniem w Grafanie: mechanizmy te rozwiązują różne problemy.

Silences i okna serwisowe: wyciszenie z określonym zakresem

Silence służy do doraźnego wyciszenia powiadomień dla alertów pasujących do wskazanych etykiet, w określonym przedziale czasu. Sprawdza się podczas jednorazowego wdrożenia lub obsługi już rozpoznanego incydentu. Warto podać autora, przyczynę oraz termin zakończenia, a dopasowanie zawęzić do konkretnej usługi i środowiska.

Powtarzalne prace, np. cotygodniowy restart infrastruktury, lepiej obsługiwać harmonogramem wyciszeń: przedziałami czasowymi przypisanymi do tras w Alertmanagerze lub mute timings przypisanymi do polityk powiadomień w Grafanie. Należy sprawdzić strefę czasową oraz zakres polityki, aby okno serwisowe nie obejmowało przypadkowo innych systemów.

Wyciszenie powiadomień nie wyłącza oceny reguł ani nie oznacza usunięcia awarii. Podczas prac alert może pozostawać aktywny i widoczny w interfejsie. Jeśli problem utrzyma się po zakończeniu wyciszenia, powiadomienia znów będą mogły zostać wysłane zgodnie z obowiązującym routingiem i ustawieniami czasowymi.

Dobre praktyki: alerty, które pomagają reagować, zamiast generować szum

Dobry alert powinien odpowiadać na trzy pytania: co jest zagrożone, jak pilna jest reakcja i kto powinien ją podjąć. Sama poprawność reguły w Prometheusie lub Grafanie nie wystarcza. Powiadomienie ma sens wtedy, gdy prowadzi do konkretnego działania: ograniczenia skutków awarii, przywrócenia usługi albo usunięcia problemu, zanim odczują go użytkownicy.

Severity określaj według skutków i pilności

Poziom ważności powinien wynikać z wpływu zdarzenia na usługę, a nie wyłącznie z wartości pojedynczej metryki. Wysokie wykorzystanie zasobów nie zawsze oznacza incydent, natomiast niedostępność kluczowej operacji może wymagać natychmiastowej reakcji nawet przy niskim obciążeniu infrastruktury.

• Critical: problem wymaga pilnej interwencji, ponieważ użytkownicy tracą dostęp do istotnej funkcji lub istnieje bezpośrednie ryzyko poważnego naruszenia celu niezawodności.
• Warning: potrzebne jest działanie, ale można je zaplanować bez natychmiastowego angażowania osoby dyżurującej.
• Info: zdarzenie dostarcza kontekstu; zwykle powinno być dostępne do analizy, a nie przerywać pracę zespołu.

To przykładowa konwencja, nie narzucony standard narzędzi. Najważniejsze, aby każdy poziom miał wspólnie uzgodnione znaczenie i oczekiwany czas reakcji. Alert wybudzający osobę dyżurującą musi uzasadniać działanie właśnie teraz.

Oprzyj pilne alerty na SLI i SLO

SLI opisuje mierzalną jakość usługi, na przykład udział poprawnie obsłużonych żądań albo odsetek odpowiedzi mieszczących się w oczekiwanym czasie. SLO określa docelowy poziom tej jakości w przyjętym okresie. Dzięki temu alertowanie można powiązać z doświadczeniem użytkownika, zamiast traktować każdą zmianę parametrów infrastruktury jako awarię.

Przydatnym sygnałem jest tempo zużywania budżetu błędów, czyli dopuszczalnego zakresu niespełnienia SLO. Szybkie zużycie wymaga innej reakcji niż niewielka, lecz długotrwała degradacja. Ocena w krótszych i dłuższych oknach pomaga odróżnić gwałtowny incydent od utrzymującego się problemu. Alerty infrastrukturalne nadal są potrzebne, szczególnie gdy ostrzegają z wyprzedzeniem, ale powinny wskazywać realne zagrożenie i możliwą interwencję.

Ograniczaj alert fatigue przez przegląd przydatności reguł

Zmęczenie alertami pojawia się, gdy zespół regularnie otrzymuje powiadomienia, które nie wymagają działania. Po incydentach i podczas okresowych przeglądów sprawdzaj, które alerty pomogły, które powielały ten sam problem, a które zostały zignorowane. Regułę stale uznawaną za nieistotną należy poprawić, przenieść do mniej pilnej kategorii albo usunąć — nie przyzwyczajać zespołu do jej ignorowania.

Oceniaj również czas utrzymywania się warunku przed uruchomieniem alertu. Powinien ograniczać reakcje na chwilowe wahania, ale nie opóźniać wykrycia rzeczywistej awarii. Nie istnieje jedna właściwa wartość dla wszystkich usług; punktem odniesienia są tolerancja na przerwę i czas potrzebny na interwencję.

Testuj regułę i całą ścieżkę powiadomienia

Test powinien obejmować zarówno sytuację, w której alert ma się uruchomić, jak i taką, w której powinien pozostać nieaktywny. Sprawdzaj krótkie skoki, utrzymującą się degradację, powrót do normy oraz brak danych. Brak metryk nie jest dowodem poprawnego działania usługi. W Grafana Alerting świadomie ustal zachowanie dla stanów No Data i Error, a w regułach Prometheusa uwzględnij możliwość zniknięcia oczekiwanych szeregów.

Testy jednostkowe reguł Prometheusa można wykonywać za pomocą promtool i włączać do procesu zatwierdzania zmian. Uzupełniaj je kontrolowanymi testami całej ścieżki: od spełnienia warunku po dotarcie powiadomienia do właściwego odbiorcy. Sam test wysyłki nie potwierdza poprawności reguły.

Zapewnij runbook i jednoznacznego właściciela

Każdy alert wymagający reakcji powinien prowadzić do krótkiego, aktualnego runbooka. Dokument powinien wyjaśniać znaczenie sygnału, wskazywać pierwsze kroki diagnostyczne, odpowiednie dashboardy, bezpieczne działania naprawcze oraz warunki eskalacji. Musi też pomagać potwierdzić, że usługa rzeczywiście wróciła do normy.

Przypisz alert do zespołu odpowiedzialnego za usługę i utrzymanie reguły. Właściciel powinien dbać o progi, dokumentację oraz aktualność ścieżki eskalacji. Alert bez właściciela i możliwej reakcji nie zapewnia skutecznej ochrony usługi — jedynie rejestruje problem, którego nikt nie zobowiązał się rozwiązać.

Checklista wdrożenia alertów w zespole: od definicji SLO po uruchomienie i strojenie

Wdrożenie alertowania nie kończy się na zapisaniu reguły ani na dostarczeniu testowej wiadomości. Jest gotowe wtedy, gdy zespół potrafi wykryć istotny problem, skierować powiadomienie do właściwej osoby i podjąć działanie w wymaganym czasie. Poniższa checklista pozwala przejść od założeń do kontrolowanego uruchomienia alertów w Grafanie i Prometheusie.

• Ustal zakres pilotażu i oczekiwany poziom niezawodności. Wybierz jedną usługę lub krytyczną ścieżkę użytkownika zamiast obejmować od razu całą infrastrukturę. Zapisz SLO, okres jego oceny oraz sposób pomiaru SLI. Uzgodnij, jakie pogorszenie jakości wymaga natychmiastowej reakcji, a jakie może poczekać na analizę w godzinach pracy.
• Potwierdź gotowość danych. Sprawdź, czy metryki rzeczywiście opisują wybraną usługę, obejmują jej istotne instancje i są dostępne z potrzebną częstotliwością. Zweryfikuj zachowanie pomiarów przy małym ruchu, restarcie i przerwie w zbieraniu danych. Warunkiem przejścia dalej powinno być rozróżnienie awarii usługi od braku informacji o jej stanie.
• Wskaż jedno miejsce zarządzania każdą regułą. Ustal, które alerty będą oceniane przez Prometheusa, a które przez Grafana Alerting. Reguły Prometheusa są naturalnym wyborem dla warunków opartych na jego metrykach; Grafana Alerting może służyć także do alertowania na podstawie innych obsługiwanych źródeł. Zapisz tę decyzję w konfiguracji lub dokumentacji wdrożenia, aby ten sam warunek nie został przypadkowo uruchomiony dwukrotnie.
• Przygotuj operacyjny odbiór alertów. Dla każdej reguły potwierdź z zespołem odbierającym powiadomienia odpowiedzialność, godziny obsługi i oczekiwaną pierwszą reakcję. Sprawdź dostęp odbiorców do potrzebnych dashboardów oraz instrukcji diagnostycznych. Samo przypisanie kanału komunikacji nie oznacza jeszcze, że ktoś przejmie obsługę zdarzenia.
• Przeprowadź odbiór całej ścieżki. W kontrolowanych warunkach sprawdź wykrycie problemu, dostarczenie powiadomienia i informację o ustąpieniu zdarzenia, jeśli jest przewidziana. Osobno zweryfikuj zachowanie przy niedostępności źródła danych. Zapisz wyniki i czas poszczególnych etapów — wiadomość testowa potwierdza jedynie fragment działania systemu.
• Uruchom pilotaż z ograniczonym zasięgiem. Nowe reguły najpierw kieruj do uzgodnionego kanału obserwacyjnego, jeśli pozwala na to ryzyko usługi. Nie zastępuj nimi od razu sprawdzonych zabezpieczeń. Wyznacz okres obserwacji obejmujący typowe obciążenie, wdrożenia i zadania cykliczne; dla usługi o zmiennym ruchu kilka spokojnych godzin nie jest miarodajnym sprawdzianem.
• Oceń przydatność, a nie tylko liczbę powiadomień. Przy każdym zdarzeniu odnotuj, czy wymagało działania, czy dotarło na czas i czy wskazało właściwy obszar diagnostyki. Porównaj alerty z rzeczywistymi incydentami, uwzględniając również problemy, których reguły nie wykryły. Na tej podstawie koryguj warunki i czas ich utrzymywania, zamiast wyłącznie podnosić progi w celu ograniczenia hałasu.
• Zatwierdź uruchomienie produkcyjne i termin przeglądu. Uzgodnij kryteria akceptacji, osobę zatwierdzającą oraz sposób wycofania wadliwej zmiany. Po uruchomieniu zaplanuj przegląd wyników, a dodatkową ocenę wykonuj po istotnym incydencie lub zmianie architektury. Każda korekta powinna mieć zapisany powód i podlegać ponownej weryfikacji.

Praktyczne kryterium gotowości: zespół potrafi wykazać, jaki problem wykrywa alert, kto go odbierze i jakie działanie podejmie. Jeśli którejś z tych odpowiedzi brakuje, reguła nie jest jeszcze gotowa do uruchomienia w trybie wymagającym natychmiastowej reakcji. W Cognity łączymy teorię z praktyką — dlatego zagadnienia wdrażania i weryfikacji alertów rozwijamy także w formie ćwiczeń na szkoleniach.

Grafana, Loki, Tempo i Prometheus – jak zbudować kompletny system obserwowalności (Observability)? 23 listopada 2026

Prometheus – co to jest i jak działa? Monitorowanie infrastruktury IT od podstaw 21 listopada 2026