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:

  • asq

    0. Zadbaj o to żeby twój system zarządzania konfiguracją system sam wykrywał i dodawał usługi i serwery do nagiosa (np. exported resources w puppet http://projects.puppetlabs.com/projects/1/wiki/Exported_Resources). Jeśli nie używasz jeszcze oprogramowania zarządzania konfiguracją przyklej w widocznym miejscu w pokoju adminów: "Jeśli coś nie jest monitorowane - NIE ISTNIEJE".

  • UHm, icinga wygląda naprawdę dobrze. I do tego ten mobile w zestawie!

  • bb

    Polecam nagiosql + nagios + nrpe

  • To są informacje o nagiosie, a nie zarządzaniu konfiguracją i wieszaniu plakatów w pokoju.

    Przydatny do nagiosa jest też http://exchange.nagios.org/directory/Addons/Frontends-%28GUIs-and-CLIs%29/Web-Interfaces/Nagios-Dashboard-%252D-PHP/visit

  • a_pache: co nie zmienia faktu, że wspomnienie o pupecie w ujęciu o nagiosa nie jest bezzasadne.

  • Zerknijcie Panowie na op5 Monitor. Jest to odpowiedź na niepewny rozwój aplikacji Nagios.org. op5 Monitor to Szwedzki pakiet oparty na nagiosie i na prawdę robi co trzeba. Połączyli wiele projektów opensource, samemu je rozwijając i dodając wsparcie. Teraz aplikacja wygląda super, wdraża się szybko i zawsze pod spodem działa pełny Linux więc nadal mamy to co lubimy - czyli pełną dowolność podczas tworzenia wtyczek ... op5 Monitor ma już swoje instalacje w Polsce.

  • @Artur: czy możesz uzasadnić, dlaczego rozwój Nagios'a jest niepewny? oraz jako sprzedawca usługi wdrożenia tego produktu, przedstawić kilka znaczących różnic? (chyba, że była to tylko reklama) ;p

  • A może ktoś z czytelników zna jakieś wygodne i darmowe narzędzie do automatycznego rysowania mapy sieci na podstawie danych odczytanych z przełączników za pomocą SNMP?
    3Com (chyba teraz HP) Network Supervisor robi coś takiego, ale jest płatny.

  • Patryk,
    Nagios Core to produkt community. Firma Nagios Enterprises z usa - której jestem partnerem, składa się z 2 osób. Nie robią oni wiele, poza skromnym marketingiem, co widać na ich www. Produkt komercyjny, fakt powstał, ale działa tragicznie, posiada bardzo słabą wydajność - co możesz sprawdzić sam pobierając demo. Ja na możliwość porozmawiania z nimi telefonicznie czekałem 2 tygodnie kręcąc codziennie. Oficjalne wsparcie dla Nagios XI można zakupić, ale w praktyce nie wykonuje tego Nagios ent, tylko Szwadzka firma op5 AB. To oni rozwijają w znacznej mierze nagiosa zarówno komercyjnego jak i jako community. Pracuje tam ~30 osób + grupa programistów i prawdziwie rozwijają produkt. Bazują oni na dobrym Nagios Core, którego wszyscy znamy, a resztę dodają sami albo integrują rzeczy z opensource - dając własne wsparcie.
    Jeżeli chodzi o różnice pomiędzy płatnym Nagios XI oraz op5 Monitor to przede wszystkim op5 Monitor działa tak wydajnie jakby był to sam nagios core. Dzisiejszy serwer 1 socket monitoruje sieć 300ip z obciążeniem ~ 1. Nagios XI monitoruje 5 hostów z obciążeniem 2-3 !!!! Idea obu aplikacji jest podobna i dalej różnią się takimi dodatkami jak ( na korzyść op5 Monitora )
    - dobre raportowanie, wykresy SLA, wysyłka na email + harmonogram
    - autoskanowanie sieci i wstępna konfiguracja hostów
    - GUI jest bardzo rozwinięte aby było szybciej - są opcje do akcji masowych, fajne filtry w polach edycji, klonowanie ustawień, propagowanie zmian itp. Najlepiej samemu odpalić sobie oba produkty i popatrzeć. Do op5 Monitora mogę dać dostęp do live demo, jak ktoś nie ma czasu na instalację.

  • Skoro produkt community to znaczy że cała masa ludzi nad nim pracuje http://www.nagios.org/about/team.

    Polecam osobiście OMD distro - 3 silniki: nagios, icinga, shinken , kilka gui, multichek, check_mk, multisite, monitoring rozproszony. Po dodaniu NagiosQL bardzo ułatwiona konfiguracja. Autoskanowanie sieci po SNMP za pomocą check_mk.
    dodatkowo raporty, SLA , wykresy, prezentacje Nagvis.

    Integracja z GLPI i innym oprogramowaniem.

    Co do monitoringu w internecie to bezpieczniejsze od NRPE, NSClient, SNMP jest check_by_ssh.

  • I really like reading a post that can make men and women think.

    Also, thanks for allowing me to comment!