Najlepsze praktyki serwera Nagios?

Prowadzę średniej wielkości serwer Nagios. Monitoruje około 40 serwerów z 180 usługami i rośnie z dnia na dzień.

Przeprowadziłem migrację ze starej konfiguracji Nagios, która została skonfigurowana w bardzo ezoteryczny sposób, zmuszając mnie do rekonfiguracji wszystkiego od zera.

Teraz, gdy serwer działa i działa na większość potrzebnych nam potrzeb , staram się uczynić go nieco bardziej skalowalnym; obecnie każdy host ma swój własny plik /etc/nagios/hosts/, a każdy host ma wszystkie swoje usługi w tym samym pliku. Nie jest to oczywiście optymalne, ale nie zaciemnia całej mojej konfiguracji do setek różnych plików.

Moje pytanie brzmi zatem: dla każdego doświadczonego administratora Nagios, jaki jest najlepszy sposób korzystania z grup hostów / grup serwisowych bez nadmiernego komplikowania konfiguracji?

Grupy hostów i szablony.

Szablony pozwalają definiować klasy dla hostów i usług, np. „Usługa normalna”, „usługa krytyczna”, „host o niskim priorytecie”. Służą również jako przydatny sposób podziału obowiązków, jeśli masz wiele zespołów o różnych obowiązkach, dzięki czemu możesz mieć szablon „hosta Linux” i szablon „hosta systemu Windows”, z których każdy określa odpowiednie dane kontaktowe.

Możesz używać wielu szablonów w jednym zasobie, dzięki czemu możesz tworzyć szablony odpowiednio prostopadłe. Na przykład możesz mieć

host foo {
    use windows-host,normal-priority-host
    ...
}

które pobierałyby dane kontaktowe (i eskalacje) dla zespołu Windows oraz stawki i progi odpytywania dla „normalnego” hosta.

Grupy hostów umożliwiają grupowanie wszystkich kontroli podzbioru hostów. Mają rzeczy takie jak „baseline-hosty Linux”, które sprawdzają obciążenie, miejsce na dysku, sshzdolność i inne rzeczy, które powinny znajdować się na każdym monitorowanym hoście. Dodaj grupy, takie jak „serwery https”, sprawdzając łączność HTTP, łączność HTTPS i daty ważności certyfikatu SSL; „serwery plików” z kontrolami dostępności NFS i SMB i być może bardziej agresywnymi kontrolami dysków; lub „maszyny wirtualne” ze sprawdzeniem, czy narzędzia ułatwień dostępu maszyn wirtualnych działają poprawnie.

Umieść każdy host i grupę hostów we własnym pliku. Plik ten powinien zawierać najpierw definicję hosta lub grupy hostów, a następnie definicje usług, które go dotyczą.

Jeśli użyjesz cfg_dirdyrektywy w swoim nagios.cfgpliku, Nagios przeszuka rekurencyjnie przez ten katalog. Skorzystaj z tego. Dla ustawienia cfg_dir=/etc/nagios/conf.dmożesz mieć drzewo katalogów podobne do następującego:

• /etc/nagios/conf.d/
  • polecenia.d /
    • http.cfg
    • nrpe.cfg
    • smtp.cfg
    • ssh.cfg
  • hosts.d /
    • host1.cfg
    • host2.cfg
    • host3.cfg
  • grupy hosta.d /
    • hostgroup1.cfg
    • hostgroup2.cfg

Staram się tworzyć katalog dla każdego typu zasobu (polecenia, grupy kontaktów, kontakty, eskalacje, grupy hostów, hosty, grupy serwisowe, przedziały czasowe) z wyjątkiem usług, które są zgrupowane z hostami lub grupami hostów, które ich używają.

Dokładna struktura może się różnić w zależności od potrzeb organizacyjnych. W poprzedniej pracy korzystałem z podkatalogów hosts.ddla każdej innej witryny. W mojej obecnej pracy większością definicji hostów Nagios zarządza Puppet, więc istnieje jeden katalog dla hostów zarządzanych przez Puppet i osobny dla hostów zarządzanych ręcznie.

Zauważ, że powyższe dzieli również polecenia na wiele plików, na ogół według protokołu. Zatem nrpe.cfgplik musiałby polecenia check_nrpei check_nrpe_1arg, a http.cfgmoże mieć check_http, check_http_port, check_https, check_https_port, i check_https_cert. ¹

Zwykle nie mam ogromnej liczby szablonów, więc zwykle mam tylko hosts.d/templates.cfgplik i services.d/templates.cfgplik. Jeśli użyjesz ich częściej, mogą przechodzić do odpowiednio nazwanych plików w templates.dkatalogu.

¹ Lubię też mieć check_http_blindlypolecenie, które jest w zasadzie check_http -H $HOSTADDRESS$ -I $HOSTADDRESS$ -e HTTP/1.; zwraca OK, nawet jeśli otrzyma kod odpowiedzi 403.

Szerokie wykorzystanie usług i grup hostów oraz szablonów. Utwórz grupy hostów i przypisz usługi do grup hostów. Użyj grup serwisowych dla zależności, eskalacji i logicznego grupowania w internetowym interfejsie użytkownika.

Jeśli masz grupy do wszystkiego, dodanie nowego hosta to tylko 3 lub 4 linie: nazwa, adres, szablony i (opcjonalnie) grupy hostów. Wszystko może być szablonowane.

Zapoznaj się z dokumentacją dotyczącą dziedziczenia , a także ze stroną poświęconą oszczędzaniu czasu . Wielokrotne dziedziczenie może być trudne, ale przy prawidłowym użyciu może to znacznie zaoszczędzić czas.

Byłem przyzwyczajony do konfiguracji moich serwerów nagios (zanim przełączyłem się na Icinga) w ten sposób i nie brakuje wydajności, dopóki nie osiągniesz więcej niż 500 usług przynajmniej z serwerem 512 MB pamięci / 1 CPU. grupy hosta i grupy serwisowe mogą być traktowane całkowicie osobno, i zaleciłbym to podejście, ponieważ pozwala na posiadanie jednego pliku na serwer (usługi dla tego serwera zdefiniowane w tym pliku), a następnie na plik na grupę host / grupy serwisowe. Jest to tylko bardziej zrozumiałe / jasne.

Jeśli napotkasz problemy ze skalowalnością, możesz rzucić okiem na serwer nagios-nrpe, który wykonuje kontrole po stronie klienta, a serwer nagios prosi tylko o wyniki; które oszczędzają zasoby czeku. (Nagios uruchamia check_nrpe, klient jest proszony, wykonuje kontrole lokalnie i odpowiada z powrotem na nagios). Należy pamiętać, że wszystkich czeków nie można traktować w ten sposób (na przykład SNMP).

Na zakończenie, a nawet jeśli może się to wydawać poza zakresem twojego pytania, sugerowałbym przejście na Icinga, który jest znacznie bardziej skalowalny, utrzymywany przez silniejszą społeczność, która naprawdę dba o implementacje nowych funkcji i wsparcie użytkownika. Konfiguracja jest taka sama (te same pliki konfiguracyjne, ta sama składnia).

Korzystam z tego schematu:

• zastępy niebieskie,
• grupy hostów,
• usługi zdalne,
• lokalne usługi.

Każda jednostka ma swój własny plik. Poza tym dzięki szablonom zawsze możesz uczynić swoją konfigurację czystszą bardziej czytelną. Na przykład możesz mieć średnie obciążenie, miejsce na dysku, pamięć na każdym hoście. Tak więc stworzenie łatwego i poręcznego szablonu jest łatwe i wygodne.

Nie można skomplikować konfiguracji, tworząc grupy. Jak powiedział asciiphil, tworzysz plik lub możesz zdefiniować te same grupy w niektórych istniejących plikach, takich jak (hosts.cfg lub cokolwiek innego), i tworzysz ten plik lub mówisz nagios, że ten plik jest aktywny (to jest, jeśli tworzysz nowy plik, jeśli nie jest już aktywny), i znajduje się on w pliku nagios.cfg, w którym podajesz ścieżkę nowo utworzonego pliku. „cfg_file = / usr / local / nagios / etc / objects / NEW_FILE.cfg”

Inną sprawą jest tworzenie grup w zależności od infrastruktury. Jeśli na przykład mam serwer Linux i Windows, utworzę dwie różne grupy, jedną dla Linuksa i drugą dla Windows. Podobnie jest z usługami. W zależności od tego, jak chcesz skonfigurować i zobaczyć, kiedy monitorujesz na monitorze, jak chcesz widzieć je jako grupy.

A dla pliku lub części, jak utworzyć grupę, jest to proste.

    define hostgroup{
    hostgroup_name novell-servers
    alias Novell Servers
    members netware1,netware2,netware3,netware4
    }

W przypadku konfiguracji hosta / lub jeśli używasz szablonu lub jeśli już zdefiniowałeś szablon hosta lub usługę i korzystasz z użycia, możesz automatycznie powiedzieć wszystkim hostom / Windows lub hostom Linux, że są członkami zdefiniowanej grupy hostów, którą utworzyłeś.