Dohľadové systémy 3 – Nagios II

Po dlhšej odmlke spôsobenej nedostatkom času a následnom udelení si telesných trestov za nedodržanie záväzku, prichádzam s pokračovaním seriálu. Dnes dokončím načaté konfiguračné súbory a následne vytvorím fungujúcu infraštruktúru.

Z /etc/nagios rozpíšem súbor cgi.cfg. Opäť, aby som nekopíroval celý súbor, skopírujem len zaujímavé časti, prípadne časti, ktoré budem meniť.

Výcuc cgi.cfg:

use_pending_states – táto možnosť je zaujímavá pri pridávaní nových služieb do nagiosu, ten totiž službu nekontroluje v momente jej pridania, ale scheduluje a potom, kým si neoverí fyzicky jej status, ju zobrazuje ako pending.

use_authentication – minule sme vytvárali nagiosadmina cez htaccess, keby sme prepli túto možnosť na 0, tak by sme sa nemuseli autnetifikovať, ale striktne sa to neodporúča, skôr je to možnosť pre nejaké uzavreté lokálne siete, kde si ľudia budú veriť navzájom. V každom prípade taký nagios potom nemôže byť reálne použiteľný z internetu.

default_user_name – štandardne vypnutá možnosť. Je to kompromis medzi vypnutou autentifikáciou a zapnutou autentifikáciou. Užívateľ sa nemusí autentifikovať, čo môže byť dosť nebezpečné.

authorized_for_blabla – v podstate môžte ľubovolnému užívateľovi umožniť prehliadať si veci, ku ktorým by normálne prístup nemal, štandardne má užívateľ prístup k informáciám o hostoch a službách, ktoré sú naviazané na užívateľa pomocou direktívy contacts alebo contact_groups (minulá časť seriálu hosts/local.cfg)

default_statusmap_layout – možnosť, v ktorej sa dá upraviť spôsob zobrazovania mapy monitorovaných systémov. Popis si pozrite sami

refresh_rate – web rozranie má nastavený autorefresh, 90 sekúnd je celkom v norme, aj tak len v málo firmách sedí človek, ktorého úlohou je pozerať sa na obrazovku statusov a väčšinou sa to rieši alertami cez email alebo/a sms.

Teraz prejdem k sľúbenej infraštruktúre, ktorá názorne predvedie možnosti, ktoré poskytuje nagios.

Pôvodný router1 nechám, to je gw do internetu, okrem toho pred ním mám ešte default gw pre localnet, na ktorom beží prípadový nagios zo seriálu. Preto ho pridám do hosts/local.cfg:

Teraz už vieme, že k router1 sa nedostaneme, ak nám nepôjde nagios-gw, preto pridáme do konfigurácie router1 parenta, čím zabezpečíme, že keď nepôjde nagios-gw, nepôjde ani router1

V hosts/local.cfg pridáme do definície host router1 riadok:

Okrem smerovačov (a neskôr aj iných služieb) by nebolo dobré, aby zostali obuvníkove deti bosé. Preto nastavíme monitorovanie služieb systému, na ktorom prevádzkujeme nagios.

Do hostgroups.cfg pridáme:

do hosts/local.cfg:

Parents mu nenastavíme, lebo z pohľadu nagiosu je to najbližší stroj. Po kontrole konfigurácie (nagios -v /etc/nagios/nagios.cfg) nám nagios správne zaplače, že nepozná node2, ktorú už máme v hostgroups, preto si pridáme aj tú:

Po ďalšej kontrole konfigurácie zistíme, že už nemáme žiadne chyby, iba dve varovania súvisiace s tým, že k node1 a node2 sme nepriradili žiadne služby. Zatiaľ nám to neprekáža, pozrieme sa, čo sa zmenilo:

a vo webrozhraní prejdeme do položky Status Map

Vidíme, že z pohľadu nagios procesu máme najbližšie seba (node1), node2, nagios-gw a jeho podriadený host router1.

Node2 je červená, zámerne som ju vypol, aby sme videli, ako vyzerajú hromy-blesky. Keďže sme si v contacts.cfg na rozdiel od mojich fiktívnych mailov nastavili korektné maily, tak nagios nám súčasne poslal aj email o tom, že node2 je down.

Ideme pridávať služby, najprv pridáme kontrolu webserveru:

Podobne pridáme kontrolu SSH a SMTP:

V commands.cfg nemáme definovaný príkaz check_ssh (minule som naschval použil iba check_tcp pre zjedndoušenie) medzi pluginmi, ale check_ssh máme. Preto ho pridáme do commands.cfg, najskôr si ale o ňom zistíme pár info:

Podľa toho si do commands.cfg vytvoríme:

Zaujímavý je napríklad argument -r, ktorý si do commandu môžme tiež pridať. Môže byť celkom použiteľný, ak by sa v budúcnosti vyskytla v nejakej verzii ssh remote vulnerability atď. Ja som použil iba port, ktorý mám často preložený niekde inde, aby mi zbytočne logy nešpinili rôzne roboty.

dáme service nagios reload a pozrieme sa do Service Detail webrozhrania:

Ako vidíme, služby sú v stave PENDING (viď info pri cgi.cfg), počkáme teda na refresh, ktorý nám naservíruje nasledovné:

Dostali sme warning (o ktorom dostaneme aj email), že http je forbidden. Je to preto, že http nám beží od minula default, iba kvôli nagiosu. Preto čisto kvôli nagiosu urobíme:

nech nám dá pokoj. Po chvíli sa služba prepne do stavu OK. Samozrejme, že si konfiguráciu každý prispôsobí a nepredpokladám, že bude niekto monitorovať službu len preto, aby monitoroval, takže podobný stav u vás nevznikne.

Aby sme boli spokojnejší, budeme monitorovať ešte lokálne ukazovateľe. Pomocou balíka nagios-plugins máme dostatočnú výbavu

lokálne disky:

Opravíme v commands.cfg pri príkaze check_disk nasledovné:

z pôvodných 85 a 95%, ktoré boli o zaplnení, check_disk ale kontroluje percentá volného miesta.

Okrem filesystémov môžme kontrolovať aj swap, load, počet prihlásených užívateľov atď (priamo z pluginov) alebo si môžme napísať svoje pluginy.

Aby som nerozpisoval jednu vec milión krát iným spôsobom, prejdem ďalej, na webe prejdem do Host detail:

a počkám na zmenu statusu:

Teraz by som chcel na druhom stroji tiež monitorovať aj nejaké služby. Http služba tam nebeží, smtp nebeží, postačí mi ssh a lokálny filesystém.

Na ssh použijem to isté, čo som použil pre node1:

Po opätovnom reloade nagiosu ssh nabehne do stavu pending. Vzniká ale problém, ako skontrolovať lokálny filesystém na node2, keď nie je dostupný cez žiadnu sieťovú službu?

Do boja povoláme nrpe (nagios remote plugin executor). Tu medzi verziu v repozitári a aktuálnou nie je až tak dramatický rozdiel, preto použijeme nrpe z EPEL repozitára.

Ako som spomenul, pre nrpe 2.12 môžte použiť spec file z epel repozitára a nabuildovať si novší nrpe.

Po nahlľiadnutí do /etc/nagios na node2 zistíme, že sa nám nainštaloval nrpe.cfg.

Stále nemáme pluginy, opäť môžme použiť nie najaktuálnejšie, ale použiteľné pluginy z repozitára epel:

Nainštaluje sa nám balíček nagios-plugins. Balíček pluginov je trošku starší ako naše pôvodné vytvorené v minulej časti, to však nevadí. Jediný rozdiel spočíva v tom, že nie sú v /usr/lib/nagios/plugins, ale v /usr/lib64/nagios/plugins. Malý chyták spočíva v tom, že nagios-plugins neobsahuje pluginy samotné. Preto sa pozrieme, aké možnosti epel repozitár dáva:

vyhodí to tony pluginov, lebo epel má každý plugin ako samostatný balík.

Nám postačí pre názornú ukážku:

Keď sa vám nechce prplať so všetkými pluginmi naraz, môžte nainšťalovať balík nagios-plugins-all

Pozrieme sa na zaujímavé časti /etc/nagios/nrpe.cfg:

server_port – nrpe sa spúšťa ako služba, na ktorú sa pripája proces nagios serveru. 5666 je defaultný port.
server_address – ak chceme spustiť nrpe len na jednom interfejsi (v prípade, že ich máme viac), tak nastavíme ip adresu
allowed_hosts – ktoré hosty môžu prikazovať niečo nrpe démonovi. My si to teda zmeníme na:

Okrem toho sa odporúča použiť na obmedzenie aj /etc/hosts.allow ale v našom príklade to nepotrebujeme.

Príkazy sa nastavujú cez command, uviedol som jeden príklad, my si prirobíme svoj command:
command[check_disk_root]=/usr/lib64/nagios/plugins/check_disk -w 15% -c 5% -p /

Podľa potreby povolíme 192.168.122.90 v iptables na port 5666 a spustíme nrpe démona:

prípadne môžme rovno:

aby sa služba spúšťala pri boote servera.

Prejdeme na server node1 a začneme uvažovať, čo nám chýba ku šťastiu. Spôsob, akým z nrpe na node2 získame informácie o našom disku. Na node1 budeme potrebovať check_nrpe plugin.

Keďže sme si minule nevyrobili nrpe plugin, nainštalujeme ho z epel repozitára:

Ako vieme už z node2, epel repozitár uložil plugin do /usr/lib64/nagios/plugins.
Skontrolujeme teda, či bude fungovať, ako chceme:

Takže funguje.

(Áno viem, že minule bol nagios nainštalovaný na i386 systéme, musel som však urobiť pár zmien a tak mi teraz beží na x86_64, nagios balík a nagios-plugins balík som nabuildoval zo src.rpm balíkov, ktoré som priložil v minulej časti)

Aj keď plugin funguje, nagios by bol stále zmätený, preto do commands.cfg pridáme:

a do hosts/local.cfg:

service nagios reload a po chvíľke PENDING stavu na službu uvidíme:

Alternatívou k nrpe je použitie pluginu check_by_ssh, kedy sa nagios pripojí na ssh, vykoná lokálny plugin a vráti výsledok (o tom niekedy neskôr).

Dobre, máme pár prkotín, môžme ísť rozvetvovať našu infraštruktúru. Ďalej budeme kontrolovať stroj u iného providera, preto si nadefinujeme dostupnosť bodov oboch providerov v peeringovom centre (SIX).

Do hosts/local.cfg pridáme:

a do hosts/serverovna-1.cfg dáme:

A konečne pridáme aj jeden server z tej serverovne:

Pridáme si hosts/serverovna-2.cfg:

reloadneme nagios a pozrieme sa, ako sa nám rozrástla chobotnica:

Stále nás ale môžu jedovať dve veci. Prvou z nich je skutočnosť, že okrem toho či zariadenia žijú nevieme, čo na nich beží a v akom stave. Druhou nezbednosťou sú nepekné otázniky na Status mape. Najprv vyriešime škaredé otázniky.
Nagios umožňuje k jednotlivým hostom prideliť obrázky. Skočíme preto napríklad sem: http://www.nagiosexchange.org/cgi-bin/page.cgi?g=1320.html;d=1

a obrázky rozbalíme do /usr/share/nagios/images/logos/

Následne začneme editovat definície hostov, k routrom pridáme 2 riadky:

k serverom podľa toho, čo používajú.
Pre centos si logo vyrobíme:

Následne po dorobení icon_image a statusmap_image a po reloade nagiosu uvidíme niečo takéto:

Opäť kilometer textu a malý výsledok a preto, aby to dávalo zmysel, budem pokračovať nabudúce. Konkrétne sa lepšie pozriem na host a service dependencies (momentálne som ich len načrtol prípravou v konfigurácii), na tvorbu pluginov, na ďalšie konfiguračné možnosti, na web rozhranie a veci, ktoré som zabudol napísať sem.