Nagios tips & tricks

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.

  1. Nagios na osobnym serwerze tak, by nie zależał od środowiska, które monitoruje
  2. 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

  3. Nie monitoruj tylko z wewnątrz, wykorzystaj 'satelity'
  4. 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).

  5. Ogólne ustawienia w szablonach (template), szczególne w host / service
  6. 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).

  7. Twórz konfigurację jeszcze bardziej czytelną
  8. 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.

  9. Grupuj podobne hosty / usługi
  10. 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).

  11. Nie używaj znaków specjalnych w nazwach
  12. 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.

  13. Sprawdź konfigurację wszystkich składników zanim zaczniesz pracę z Nagios
  14. 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?

  15. Nie dręcz się zbytnio
  16. 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.

  17. Relacje vs. zależności
  18. 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.

  19. Usługi mogą zależeć od usług na innych hostach
  20. 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.

  21. Zależności usług mogą być czasowe (dependency_period)
  22. 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.

  23. Własne dyrektywy dla host / service
  24. 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$.

  25. Bezpieczeństwo: hasła przekazywane w komendach są widoczne
  26. 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$.

  27. Bezpieczeństwo: nie uruchamiaj z prawami root
  28. Jeśli jakiś plugin wymaga zwiększonych uprawnień, użyj sudo zamiast uruchamiać Nagios z prawami administratora.

  29. Bezpieczeństwo: katalog z wynikami
  30. 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.

  31. Bezpieczeństwo: uwierzytelnianie CGI
  32. 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.

  33. Bezpieczeństwo: pełne ścieżki w nazwach komend
  34. 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.

  35. Bezpieczeństwo: zabezpieczony dostęp do agentów
  36. 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.

  37. Testy aktywne (active checks) vs. pasywne (passive)
  38. 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.

  39. Jeśli uda się naprawić problem, zawsze zostaniemy o tym powiadomieni
  40. Jeśli dostaliśmy komunikat [d]own, niezależnie od schematu czasowego po naprawie usterki dostaniemy [r]ecovery.

  41. Częste zmiany stanu
  42. 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ć.

  43. Jak informować
  44. 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.

  45. Poprawianie czytelności raz jeszcze
  46. * (wszystko) i ! (negacja) skraca zapisy. Jeśli chcesz, możesz również użyć wyrażeń regularnych (use_regexp_matching).

  47. Planowane wyłączenie usług
  48. 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.

  49. Monitorowanie klastrów
  50. 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ą.

  51. Połączenie z innym oprogramowaniem
  52. Dzięki NDOUtils konfigurację Nagios możemy przechowywać w bazie MySQL. NDOUtils jest niezbędne przy wielu dodatkach.

  53. Właściwe powiadamianie
  54. 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).

  55. Nagios to nie wszystko
  56. 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: