To druga część spostrzeżeń podczas pracy z Nagios. Przejrzyj też pierwszą.
- Bezpieczeństwo: katalog z wynikami
- Bezpieczeństwo: uwierzytelnianie CGI
- Bezpieczeństwo: pełne ścieżki w nazwach komend
- Bezpieczeństwo: zabezpieczony dostęp do agentów
- Testy aktywne (
active checks) vs. pasywne (passive) - Jeśli uda się naprawić problem, zawsze zostaniemy o tym powiadomieni
- Częste zmiany stanu
- Jak informować
- Poprawianie czytelności raz jeszcze
- Planowane wyłączenie usług
- Monitorowanie klastrów
- Połączenie z innym oprogramowaniem
- Właściwe powiadamianie
- Nagios to nie wszystko
Katalog z wynikami testów nie powinien być dostępny dla nikogo poza użytkownikiem, z którego prawami uruchomiony jest Nagios. To są wrażliwe informacje tak jak konfiguracja całego systemu. Zadbaj o nie.
Dostęp do konfiguracji, wyników testów i struktury sieci dla napastnika, to spore ułatwienie w przygotowaniu ataku. Dostęp przez przeglądarkę to coś więcej niż ładne tabelki i wykresy.
Jeśli chcemy mieć pewność, że uruchamiamy właściwy skrypt / program przy wykonywaniu testów, podajmy w konfiguracji (commands.cfg) pełne ścieżki.
Jeśli na monitorowanych serwerach używamy agentów (NRPE, NSClient, SNMP), ograniczmy do nich dostęp. Komunikacja odbywa się z wykorzystaniem SSL (wyłączając SNMP), ale bez uwierzytelniania przy pomocy użytkownika i hasła.
Aktywny test wykonywany jest przez system Nagios + odpowiedni plugin. Test pasywny wykonuje zewnętrzny program, a swój wynik dostarcza do Nagios. W dużych środowiskach może to mieć wpływ na wydajność i zalecane jest sprawdzanie pasywne.
Jeśli dostaliśmy komunikat [d]own, niezależnie od schematu czasowego po naprawie usterki dostaniemy [r]ecovery.
Zmieniające się stany (state flapping) spowodowane są rzeczywistymi problemami monitorowanego środowiska lub błędną konfiguracją. Twórcy Nagios’a opracowali algorytm pomagający to wykrywać.
Dane wpisane w dyrektywach kontaktów, jak: email, pager, address[1-6], wykorzystywane są przez notification_command, więc to od nas zależy jak zostaną wykorzystane, ale podawajmy logiczne wartości, byśmy sami nie mieli problemów ze zorientowaniem się o co chodzi.
* (wszystko) i ! (negacja) skraca zapisy. Jeśli chcesz, możesz również użyć wyrażeń regularnych (use_regexp_matching).
Jeśli planujesz wyłączenie serwera np. na czas czyszczenia czy aktualizacji oprogramowania, zaplanuj to. System nie będzie rozsyłał zbędnych raportów. Jeśli np. Twój ISP informuje Cię o czasowym odłączeniu od sieci, które jest niezbędne do przeprowadzenia konserwacji i zapewnia Cię, że nie potrwa to dłużej jak godzinę, sprawdź go.
Nagios wspiera monitorowanie klastrów (poprzez wtyczkę check_cluster). Klastrów w rozumieniu wielu serwerów świadczących tą samą usługę, na które jest rozkładany ruch (np. DNS czy bramy pocztowe). Test ten to nic innego jak sprawdzenie wyników testów usług na poszczególnych serwerach składowych. Jako progi dla ostrzeżeń i alarmów ustawiamy ilość składowych, które nie działają.
Dzięki NDOUtils konfigurację Nagios możemy przechowywać w bazie MySQL. NDOUtils jest niezbędne przy wielu dodatkach.
Powiadamianie za pomocą poczty elektronicznej jest mało skuteczne. Zwłaszcza gdy awarii ulegnie serwer pocztowy lub ma zapchaną kolejkę. Nie zawsze jesteśmy też przy kliencie poczty, więc nie mamy możliwości odczytania wiadomości. Jeśli to możliwe, skorzystajmy z alternatywnego kanału komunikacji – np. SMS (pager chyba u nas jest mało popularny).
Wykorzystać też możemy dodatek do przeglądarki (np. Nagios checker), samodzielną mini-aplikację czy komunikator (np. gadu-gadu czy jabber).
Są ludzie, którzy narzekają na brak rozwoju Nagios lub prowadzenie prac w złym kierunku. Tacy ludzie robią odgałęzienia projektu (fork). Jednym z nich jest ICINGA. Ładniej wygląda, zapewnia kompatybilność konfiguracji i ma czytelniejszą mapę!
Tagi: Nagios
Można powiedzieć, że te porady uratowały mi życie. Czekam na kolejne artykuły z tej mini serii.
[...] wpisie Nagios tips & tricks wspomniałem o projekcie Icinga (fork Nagios). Próbowałem uruchomić to na Gentoo Linux (ze [...]