Od paru lat Nagios pomaga mi administrować środowiskiem, które się mi powierza. I robi to całkiem nieźle! Poniżej kilka moich spostrzeżeń i wskazówek dla wszystkich, którzy chcą użyć Nagios lub już go używają.
Słowem wyjaśnienia - wdrażałem go raczej w małych i średnich środowiskach, więc tylko z takowymi mam doświadczenie.
- Nagios na osobnym serwerze tak, by nie zależał od środowiska, które monitoruje
- Nie monitoruj tylko z wewnątrz, wykorzystaj 'satelity'
- Ogólne ustawienia w szablonach (
template), szczególne w host / service - Twórz konfigurację jeszcze bardziej czytelną
- Grupuj podobne hosty / usługi
- Nie używaj znaków specjalnych w nazwach
- Sprawdź konfigurację wszystkich składników zanim zaczniesz pracę z Nagios
- Nie dręcz się zbytnio
- Relacje vs. zależności
- Usługi mogą zależeć od usług na innych hostach
- Zależności usług mogą być czasowe (
dependency_period) - Własne dyrektywy dla
host / service - Bezpieczeństwo: hasła przekazywane w komendach są widoczne
- Bezpieczeństwo: nie uruchamiaj z prawami root
- 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
To dość oczywiste, ale w czasach popularności wirtualizacji instalujemy system monitoringu gdzieś, gdzie da się go jeszcze upchnąć przydzielając minimum zasobów. System radzi sobie świetnie, bo wiele nie wymaga, ale czasami na wyniki jego testów mają wpływ inne maszyny wirtualne pracujące równolegle na tym samym hypervisor'ze (I/O, sieć). Warto to wziąć pod uwagę instalując system
Fakt, że serwer HTTP działa nie wystarcza, by spać spokojnie. Ważne jest też, by był dostępny dla klientów. Monitorowanie wewnątrz LAN / DMZ ma sens, ale jego uzupełnieniem powinno być monitorowanie z poza własnej sieci (tanie dodatkowe łącze od innego ISP, instalacja w oddziale firmy, VPS lub wzajemne sprawdzanie z zaprzyjaźnionym Sysadminem).
Dla czytelności starajmy się części wspólne konfiguracji zawierać w szablonach. Natomiast szczególne dyrektywy umieszczajmy w blokach odpowiedzialnych za usługi i hosty. Jeśli to możliwe, stosuj wykluczenia (np. exclude w schematach czasowych).
Przyporządkowanie np. hosta do grupy można zrobić na dwa sposoby - w definicji hosta (hostgroups) lub w definicji grupy (hosts). Pierwszy sposób zwiększy ilość linii w konfiguracji, ale pozwala jednoznacznie określić który host należy do której grupy. Dziś monitorujesz kilka składników, pomyśl co będzie jak będziesz monitorował kilkaset.
Jeśli na wielu maszynach sprawdzana jest ta sama usługa (chociażby najprostsze check_ping) wygodniej do definicji service dodać całą grupę (hostgroup_name), niż n hostów (host_name).
To działa, ale mogą być problemy. Nagios dokonuje powiązań właśnie po nazwach. Jeśli chcesz opisać usługę jako "Serwer WWW (dla klientów)" - użyj aliasów.
Sprawdź konfigurację po poprzednim administratorze, ale zajrzyj też do domyślnych ustawień. Widziałeś zapis "Linux admins hate to be woken up, so we only notify during the day" w szablonie linux-server?
Jeśli znasz swoją sieć, wyłącz komunikaty [u]nreachable. Każdy serwer za wyłączonym przełącznikiem jest nieosiągalny. Pamiętaj jednak, że naprawa takiego przełącznika ma wyższy priorytet.
Nagios umożliwia definiowanie relacji (parent/child relationship) i zależności (dependencies). Te pierwsze mają jedynie wpływ na powiadomienia [d]own i [u]nreachable (ale w dużym środowisku i tak nie poprawiają czytelności mapy). Drugie to zaawansowane podejście do monitoringu umożliwiające określanie warunków dla których ma wystąpić powiadomienie w przypadku gdy host / usługa zależy od innych czynników.
To daje nam możliwość dokładnego odwzorowania środowiska. Np. serwer POP3 na serwerze A uwierzytelnia użytkowników korzystając z danych w bazie SQL zainstalowanej na serwerze B.
Ta opcja najbardziej przydatna jest w okienkach backupowych. np. poprawne wykonanie kopii zależy od dostępności macierzy A, napędu taśmowego N i przełączników X oraz Y. Ale tylko w weekend.
Jeśli chcemy użyć dyrektyw specyficznych dla konkretnej usługi lub hosta, a nie są one zdefiniowane (jak adres IP), możemy je dodawać samodzielnie ustawiając jako _zmienna, a używając dalej po podaniu $_HOSTZMIENNA$.
Jeśli podamy jako własną dyrektywę nazwę użytkownika i hasło do sprawdzania usługi, pamiętajmy, że jest to wyświetlane w interfejsie web, a co za tym idzie, może być dostępne dla osób niepowołanych. Zamiast tego skorzystajmy z możliwości zdefiniowania makra (macro) w pliku resource.cfg. Do dyspozycji mamy 32 zapisy $USERn$.
Jeśli jakiś plugin wymaga zwiększonych uprawnień, użyj sudo zamiast uruchamiać Nagios z prawami administratora.
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ę!
Oryginał tego wpisu znajdziecie na moim prywatnym blogu: