Generator alertów Prometheus

Generator alertów Prometheus

Prometheus zbiera metryki, a reguły alertowe decydują, kiedy wysłać ostrzeżenie. Ten generator tworzy poprawną składniowo regułę YAML na podstawie wyrażenia PromQL.

Struktura reguły

Przykładowe wyrażenia

• up == 0 — cel niedostępny.
• rate(http_requests_total{status=~"5.."}[5m]) > 0.05 — zbyt dużo błędów 5xx.
• node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.1 — mało wolnej pamięci.
• rate(node_cpu_seconds_total{mode="idle"}[5m]) < 0.1 — wysokie obciążenie CPU.

Jak działa generator alertów Prometheus

Generator zamienia wartości wpisane w formularzu na gotową regułę w formacie YAML. Każda reguła jest elementem listy wewnątrz grupy: pole alert nadaje nazwę, expr przechowuje wyrażenie PromQL, for określa długość okna tolerancji, labels.severity wagę alertu, a annotations tekst czytelny dla człowieka. W YAML o strukturze decydują wcięcia, dlatego generator pilnuje, aby klucze jednego alertu były zagnieżdżone na tym samym poziomie, a wartości tekstowe zawierające nawiasy klamrowe, przecinki lub dwukropki znalazły się w cudzysłowie.

Prometheus ocenia wyrażenie w każdym cyklu ewaluacji. Jeśli zapytanie zwróci niepusty wektor, czyli istnieje szereg czasowy spełniający warunek, alert przechodzi w stan pending. Pozostaje w nim tak długo, jak długo warunek jest spełniony, a po upływie czasu z pola for zmienia stan na firing i dopiero wtedy trafia do Alertmanagera. Gdy wyrażenie przestanie zwracać wyniki, alert wraca do stanu resolved. Pole for działa więc jak filtr: warunek musi być prawdziwy nieprzerwanie, a nie tylko w jednym punkcie pomiarowym.

Progi zapisuje się jako ułamki, nie jako procenty. Wartość 0.05 to 5%, 0.1 to 10%, a 0 oznacza dokładne zero, na przykład w wyrażeniu up == 0, gdzie niedostępny cel przyjmuje wartość 0. Funkcja rate() liczy średnią zmianę licznika na sekundę w podanym oknie, więc okno 5m to 300 sekund. Jeżeli licznik wzrósł o 200 w ciągu 300 sekund, rate() zwróci około 0.667 na sekundę i taki wynik porównujesz z progiem.

Przykład: alert na błędy 5xx krok po kroku

1. Cel: uruchomić alert, gdy odsetek odpowiedzi z kodem 5xx przekroczy 5%.
2. Wybierz licznik http_requests_total i zawęź błędy etykietą: status=~"5..".
3. Zapisz wyrażenie: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.05. Okno 5m odpowiada 300 sekundom.
4. W oknie 5 minut przyjęto 200 żądań, z czego 12 zakończyło się kodem 5xx. Udział błędów wynosi 12 / 200 = 0.06, czyli 6%.
5. 6% > 5%, więc warunek jest spełniony. Alert wchodzi w stan pending i pozostaje w nim, dopóki wyrażenie nadal zwraca wynik.
6. Ustaw for na 5m, severity na critical i dopisz podsumowanie. Po 5 minutach nieprzerwanego spełniania warunku alert przejdzie w stan firing i zostanie wysłany do Alertmanagera.

Pola reguły alertowej — ściągawka

Jak używać reguł w praktyce

• Zawsze ustawiaj for — bez tego alert zadziała przy pierwszym spełnieniu warunku, więc pojedynczy skok metryki wygeneruje powiadomienie i szum w kanale alertów.
• Pamiętaj, że progi to ułamki — 0.05 oznacza 5%, a 0.1 oznacza 10%. Wpisanie 5 zamiast 0.05 daje zupełnie inny, praktycznie nieosiągalny warunek.
• Nazywaj alerty opisowo — nazwa trafia do etykiety alertname i do tytułu powiadomienia, dlatego HighErrorRate jest czytelniejsze niż Alert1.
• Trzymaj reguły w osobnym pliku — wskaż go w prometheus.yml w sekcji rule_files, a po każdej zmianie przeładuj konfigurację, żeby nowe reguły zaczęły obowiązywać.
• Testuj wyrażenie przed zapisem — wklej expr do konsoli PromQL i sprawdź, czy zwraca serie czasowe oraz czy wartości realnie przekraczają próg.

Ograniczenia i czynniki zaburzające

• Nie sprawdza poprawności PromQL — generator pilnuje składni YAML, ale nie zweryfikuje, czy zapytanie jest sensowne ani czy użyte metryki i etykiety istnieją w twojej instancji.
• Nie zna twoich danych — nazwy liczników, etykiet i typowe zakresy wartości musisz podać sam; narzędzie nie podpowie, jaki próg jest właściwy dla twojej skali ruchu.
• Nie uwzględnia interwału scrapowania ani ewaluacji — rzeczywiste opóźnienie alertu to czas zbierania danych, długość okna w rate() oraz wartość for; zależą one od konfiguracji serwera, a nie od wygenerowanego pliku.
• Nie ocenia kosztu zapytania — rozbudowane agregacje po wielu szeregach czasowych obciążają Prometheusa i mogą wydłużyć cykl ewaluacji, czego wynik generatora nie sygnalizuje.

Najczęstsze pytania