Netdata SMTP Alert Integration

Integracja alertów SMTP w Netdata pozwala temu systemowi monitoringu wysyłać powiadomienia o awariach pocztą.

Rola SMTP w mechanizmie alertów Netdata

Netdata jest systemem monitoringu, który zbiera metryki dotyczące między innymi obciążenia procesora, pamięci operacyjnej, przestrzeni dyskowej, interfejsów sieciowych oraz usług działających na monitorowanym hoście. Na podstawie tych danych moduł Health sprawdza warunki alarmowe. Reguła alarmowa może określać próg ostrzegawczy, próg krytyczny, czas utrzymywania się odchylenia oraz sposób powiadomienia. Integracja SMTP pozwala przekazać takie powiadomienie do serwera poczty elektronicznej, aby informacja o problemie trafiła do wskazanych odbiorców.

SMTP nie odpowiada za wykrywanie awarii. Jego rolą jest transport wiadomości wygenerowanej przez mechanizm alertów. Netdata najpierw ocenia stan metryki i zmianę statusu alarmu, a dopiero potem wywołuje skonfigurowany kanał pocztowy. Wiadomość może informować o przejściu alarmu do stanu warning albo critical, o jego powrocie do stanu clear oraz o innych zdarzeniach obsługiwanych przez daną wersję i konfigurację Netdata. Dzięki temu poczta jest kanałem dostarczenia zdarzenia, a nie źródłem danych monitoringu.

Przepływ wiadomości od reguły Health do skrzynki

Typowy przepływ rozpoczyna się od odczytu metryki przez agenta Netdata. Moduł Health porównuje bieżącą wartość z warunkami zapisanymi w definicji alarmu. Jeżeli stan spełnia warunek i upłynie wymagany czas, Netdata zmienia status alarmu oraz uruchamia powiadomienie. Następnie komponent odpowiedzialny za alert pocztowy przygotowuje nadawcę, odbiorców, temat i treść wiadomości, po czym przekazuje ją do lokalnego programu wysyłkowego albo bezpośrednio do wskazanego serwera SMTP, zależnie od sposobu skonfigurowanego w danym środowisku.

W starszych i częściowo zmodyfikowanych instalacjach konfiguracja powiadomień jest związana ze skryptem health_alarm_notify.sh. W tym obszarze spotyka się ustawienia takie jak SEND_EMAIL, adres nadawcy oraz domyślni odbiorcy. Lokalizacja pliku konfiguracyjnego zależy od instalacji, ale często jest to /etc/netdata/health_alarm_notify.conf. W nowszych wydaniach szczegóły dostępnych opcji mogą się różnić, dlatego nazwy parametrów należy sprawdzić w dokumentacji i plikach dostarczonych z konkretną wersją Netdata. Samo wpisanie adresu odbiorcy nie gwarantuje wysyłki, jeżeli host nie ma działającego klienta pocztowego lub poprawnej trasy do serwera SMTP.

Uwierzytelnianie, TLS i typowe przyczyny braku alertu

Serwer SMTP może wymagać uwierzytelniania, szyfrowania połączenia oraz określonego portu. W praktyce spotyka się połączenia zabezpieczone TLS, połączenia rozpoczynane bez szyfrowania i podnoszone do TLS przez mechanizm STARTTLS, a także lokalne przekazanie wiadomości do agenta pocztowego. Netdata musi korzystać z metody obsługiwanej przez użyty program wysyłkowy i serwer. Błąd certyfikatu, niezgodna nazwa hosta, odrzucone dane logowania, blokada portu wychodzącego albo nieprawidłowy adres nadawcy mogą uniemożliwić dostarczenie wiadomości mimo prawidłowo działającego monitoringu.

Diagnostyka powinna rozdzielić trzy etapy: wykrycie alarmu, uruchomienie kanału e-mail i przyjęcie wiadomości przez serwer pocztowy. Najpierw należy potwierdzić, że reguła Health rzeczywiście przechodzi w stan alarmowy i że powiadomienia e-mail są włączone. Następnie trzeba sprawdzić logi Netdata oraz komunikaty programu SMTP, zwracając uwagę na kod odpowiedzi serwera. Na końcu warto zweryfikować foldery spam i reguły filtrowania. Wiadomość może zostać przyjęta przez serwer SMTP, ale odrzucona później przez filtr antyspamowy, politykę domeny nadawcy lub ograniczenia konta.

Bezpieczna weryfikacja konfiguracji Netdata

Przy sprawdzaniu integracji należy porównać konfigurację z wersją uruchomionego Netdata, ponieważ nazwy opcji i obsługiwane metody wysyłki nie są niezależne od wydania. Trzeba również ustalić, czy agent korzysta z lokalnego sendmail, narzędzia pośredniczącego, czy z osobnego klienta SMTP. Pomocne jest wykonanie kontrolowanego testu alarmu oraz obserwowanie logów w tym samym czasie. Test powinien obejmować zarówno pojawienie się wiadomości, jak i późniejsze powiadomienie o powrocie metryki do prawidłowego stanu.

Jeżeli alerty nie są wysyłane, nie należy od razu zmieniać progów monitoringu. Najpierw warto sprawdzić składnię pliku konfiguracyjnego, prawa dostępu do plików, dostępność programu wysyłkowego, rozwiązywanie nazwy serwera SMTP, połączenie sieciowe oraz zgodność ustawień TLS. Hasła i tokeny używane przez klienta pocztowego powinny być przechowywane zgodnie z mechanizmem przewidzianym dla danego systemu, a po zmianie konfiguracji należy potwierdzić, że proces Netdata odczytał nowe ustawienia. Diagnostyka i naprawa problemów z działaniem Netdata wymaga więc analizy jednocześnie reguł Health, konfiguracji agenta, klienta pocztowego i odpowiedzi serwera SMTP.