Prometheus Alertmanager obsługuje powiadomienia e-mail o alertach wygenerowanych przez system monitoringu.
Rola Alertmanagera w systemie Prometheus
Prometheus Alertmanager jest komponentem odpowiedzialnym za obsługę powiadomień generowanych przez reguły alertów Prometheusa. Sam Prometheus ocenia wyrażenia zapisane w regułach i tworzy aktywne alerty, natomiast Alertmanager przyjmuje te zdarzenia przez interfejs HTTP i decyduje, w jaki sposób oraz do jakich odbiorców zostaną przekazane. Dzięki temu logika monitoringu metryk pozostaje oddzielona od konfiguracji kanałów powiadomień. Alert może dotyczyć niedostępności usługi, przekroczenia poziomu użycia procesora, braku miejsca na dysku albo opóźnienia odpowiedzi, a Alertmanager może obsłużyć go według wspólnych zasad.
Alertmanager przechowuje stan obsługiwanych alertów, rozpoznaje ich etykiety i korzysta z konfiguracji tras oraz odbiorców. W typowym wdrożeniu Prometheus wysyła alerty do endpointu Alertmanagera wskazanego w sekcji alerting. Alertmanager może działać jako pojedyncza instancja albo w grupie współpracujących instancji. W środowisku z kilkoma instancjami mechanizm gossip służy do wymiany informacji o alertach, wyciszeniach i powiadomieniach, co ogranicza ryzyko wielokrotnego wysłania tego samego komunikatu.
Etykiety, trasy i grupowanie komunikatów
Podstawą decyzji Alertmanagera są etykiety alertu, takie jak alertname, instance, job, severity lub etykiety opisujące środowisko. Konfiguracja route określa, do którego odbiorcy trafi alert. Można na przykład rozdzielić alerty według wartości severity, zespołu odpowiedzialnego za usługę albo środowiska produkcyjnego i testowego. Trasy są oceniane hierarchicznie, a parametr continue określa, czy po dopasowaniu jednej trasy Alertmanager ma kontynuować sprawdzanie kolejnych tras na tym samym poziomie.
Mechanizm group_by pozwala łączyć podobne alerty w jedną wiadomość. Grupowanie według alertname i cluster może ograniczyć liczbę e-maili, gdy wiele instancji zgłasza ten sam problem. Parametry group_wait, group_interval i repeat_interval sterują odpowiednio opóźnieniem pierwszego powiadomienia, minimalnym odstępem między aktualizacjami grupy oraz czasem ponownego przypomnienia o nadal aktywnym alercie. Zbyt krótkie interwały mogą powodować zalew skrzynki, a zbyt długie opóźniać reakcję na awarię.
Alertmanager rozróżnia alerty aktywne i rozwiązane. Gdy Prometheus przestaje spełniać warunek reguły, wysyłany jest stan resolved, o ile odbiorca ma włączone wysyłanie informacji o rozwiązaniu. Mechanizmy silences i inhibition służą do ograniczania szumu. Silence czasowo wycisza alerty pasujące do określonych matcherów, natomiast inhibition pozwala wstrzymać alerty zależne od innego, nadrzędnego problemu, na przykład ukryć alarmy usług działających na hoście, który został oznaczony jako niedostępny.
Powiadomienia e-mail i konfiguracja SMTP
Do wysyłania wiadomości e-mail Alertmanager używa odbiornika typu email_configs. Konfiguracja może zawierać adres nadawcy from, adres serwera SMTP w polu smarthost, listę odbiorców to oraz opcjonalne pola headers, html i text. Uwierzytelnianie może korzystać z nazwy użytkownika i hasła, a opcja require_tls określa, czy połączenie z serwerem pocztowym musi zostać zabezpieczone TLS. Wartość smarthost zawiera nazwę hosta i port, na przykład zapis odpowiadający usłudze SMTP wystawionej na porcie 587.
Przykładowa struktura odbiorcy wygląda następująco: receivers: zawiera nazwany odbiornik, a w nim sekcję email_configs: z ustawieniami serwera i adresu docelowego. Sam odbiornik nie wysyła jednak żadnej wiadomości, jeśli nie zostanie wskazany w odpowiedniej trasie. Dlatego przy diagnozowaniu braku e-maili trzeba sprawdzić jednocześnie dopasowanie etykiet do matchers, nazwę odbiorcy przypisaną w receiver, poprawność konfiguracji YAML oraz dostępność serwera SMTP z systemu, na którym działa Alertmanager.
Wiadomość może korzystać ze zmiennych szablonów, takich jak {{ .Status }}, {{ .CommonLabels }} i {{ .Alerts }}. Szablon powinien rozróżniać alert aktywny od rozwiązania oraz przedstawiać etykiety i adnotacje dostarczone przez regułę Prometheusa. Błąd uwierzytelniania SMTP, odrzucony certyfikat TLS, niedostępny DNS albo blokada połączenia wychodzącego mogą uniemożliwić wysyłkę mimo prawidłowo działającego samego alertu. Alertmanager zapisuje informacje o takich problemach w logach, dlatego analiza powinna obejmować zarówno stan alertu w interfejsie, jak i komunikaty dotyczące powiadomień.
Kontrola działania i diagnostyka przepływu alertu
Sprawdzanie problemu należy rozpocząć od potwierdzenia, że reguła alertowa jest załadowana i że Prometheus faktycznie ocenia ją jako aktywną. Następnie trzeba zweryfikować, czy Prometheus ma poprawnie wskazany adres Alertmanagera oraz czy endpoint jest osiągalny. Po stronie Alertmanagera istotne są aktywne alerty, dopasowane etykiety, stan wyciszeń i wynik routingu. Alert może nie wysłać wiadomości dlatego, że jest wyciszony, został objęty inhibition, należy do już wysłanej grupy albo nie minął jeszcze czas określony przez group_wait lub repeat_interval.
Plik konfiguracyjny można sprawdzać narzędziem amtool check-config, dostępnym w dystrybucji narzędzi Alertmanagera. Polecenie wykrywa błędy składni i problemy ze strukturą konfiguracji, ale nie potwierdza, że serwer SMTP zaakceptuje połączenie ani że wybrana trasa otrzyma konkretny alert. Po zmianie konfiguracji konieczne jest przeładowanie jej w uruchomionym procesie, zgodnie ze sposobem wdrożenia. W praktyce warto skorelować czas utworzenia alertu, wpisy w logach Prometheusa oraz wpisy Alertmanagera dotyczące grupowania i wysyłki.
Jeżeli wiadomość dociera, lecz zawiera niepełne dane, przyczyną zwykle jest niepoprawny szablon albo brak oczekiwanej etykiety w regule. Jeżeli Alertmanager pokazuje alert, ale nie ma śladu próby wysyłki, należy analizować routing, grupowanie, silence i inhibition. Jeżeli log wskazuje próbę połączenia SMTP zakończoną błędem, dalsza diagnostyka powinna obejmować rozwiązywanie nazwy hosta, port, negocjację TLS i dane uwierzytelniające. Taki podział pozwala odróżnić błąd reguły monitoringu od problemu z dostarczeniem powiadomienia.
