LPS:Nagios

Úvod

Tento dokument popisuje funkce monitorovacího systému Nagios a webového konfigurátoru NConf, které nejsou v prostředí CIV ZČU vůbec využívány nebo jsou využívány jen málo. Dále se popisuje možné změny konfigurace v příkladech.

Nagios Core

Nagios Core1 je monitorovací nástroj spustitelný pod operačními systémy GNU/Linux. Konfigurace se provádí ručně v textových konfiguračních souborech. Systém monitoruje zařízení na odezvu a dále libovolné služby přiřazené k zařízením. Služba je kontrolována na funkčnost spuštěním nějakého příkazu s předem definovanou návratovou hodnotou.

NConf

NConf je webový nástroj zjednodušující konfiguraci systému Nagios. Ve webovém rozhraní je možné připravit celou konfiguraci a následně ji exportovat do systému Nagios.

Verze

V tomto oddílu jsou srovnány používané verze nástrojů.

Nagios

Aktuálně nainstalovaná verze Nagiosu je 3.2.1 03/09/2010. Poslední vydaná verze je 3.4.2 11/09/2012. Aktuální verze je pravděpodobně použitá, protože je obsažena v balíku pro Debian GNU/Linux 6.0.6 Squeeze. Zajímavé změny v poslední verzi oproti nainstalované jsou:

• podpora pro host service dependencies v servicegroups (od 3.3.1),
• nový theme, je možno při make nastavit původní (od 3.3.1).

Stačí jeden host nebo service na který má uživatel práva a už smí prohlížet hostgroup nebo servicegroup, dříve musel mít práva na všechny. (3.4.0)

NConf

Nainstalovaná verze NConfu 1.3.0 je aktuální.

Funkce

Tento oddíl popisuje funkce, které nejsou v současné konfiguraci systému Nagios používány nebo je jejich popis důležitý pro další text a naznačuje jejich možné použití.

Na začátek je třeba si uvědomit, že Nagios Core obsahuje jen základní funkcionalitu a neměly by v něm být hledány žádné vyšší funkce. Nelze v něm vytvářet žádné složité hierarchie, složité závislosti apod. Ať už je konfigurace provedena jakkoliv hierarchicky, Nagios Core z ní vždy vygeneruje pouze plochý seznam služeb, který po jedné prochází. Stav služby vyhodnotí a v případě chyby jí ohlásí. Nagios Core neumí dělat žádné závěry, přestože k takovému uvažování některé složitější konstrukce v konfiguraci svádějí. Jediným náznakem hierarchie je možnost potlačení hlášení chyby viz další text.

Groups obecně

Nagios umí slučovat různé hosty a service do skupin. Jeden host nebo service může být součástí více groups. Groups slouží k:

• optickému sloučení souvisejících hostů/services
• k usnadnění konfigurace více hostů/services najednou

Obecně lze na skupiny nahlížet jako na kontejner na objekty. Nagios je pak umí ve webovém rozhraní zobrazit společně. Neumí ale vyvodit jakýkoliv závěr o funkčnosti nebo nefunkčnosti skupiny jako celku – mezi objekty ve skupině není žádná vazba AND nebo OR.

Z toho vyplývá, že je nelze použít k:

• monitorování clusterů
• hlášení nefunkčnosti skupiny2

Hostgroups

Hostgroups slouží k seskupení souvisejících HW zařízení např. linux-servery, win-servery nebo switche. Jeden host může být ve více hostgroups najednou. Je žádoucí hostgroups používat kvůli přehlednosti a je přímo výhodné je používat kvůli možné kombinaci s advanced services.

Servicegroups

Servicegroups slouží k seskupení souvisejících služeb. Jedna service může být v několika servicegroups najednou. Použití servicegroups je spíše volitelné pro přehlednost ve webovém rozhraní. Na zjednodušení konfigurace prakticky nemá vliv. Příklady konfigurace viz a .

Advanced services

Advanced service je pokročilá služba používaná v konfigurátoru NConf. Systém Nagios ani jeho dokumentace tento pojem nepoužívá. V Nagiosu se nakonfigurovaná advanced service tváří jako běžná service. Advanced service rozšiřuje klasickou service o možnost přiřazení:

• několika hostům místo jednoho
• několika hostgroups
• několika servicegroups (to je možné i u normální)

Kompletní myšlenka advanced service vychází z . Použitím advanced service lze zjednodušit konfiguraci services jednotlivých hostů tak, že:

1. Hosta přiřadím do vhodné hostgroup.
2. Nadefinuji novou advanced service.
3. Advanced service přiřadím hostgroup.

Výsledkem bude, že všichni hosts v hostgroup budou mít u sebe zobrazenu tuto service. To má dvě základní výhody: jedním úkonem se service přiřadí více hostům, není potřeba ji přidávat každému zvlášť veškeré budoucí změny service se promítnou globálně pro všechny hosty Toto je velice výhodné a může to ušetřit spoustu práce, je ale potřeba dbát na správné přiřazování hostů do hostgroups. Nevýhodou může být, že u hosta není service přímo zapsaná a není tak přímo vidět. Naštěstí s tímto problémem je v NConfu počítáno a tak při rozbalení všech services u hosta jsou zděděné vidět jako inhterited services jako na obrázku.

Na následujícím příkladu předvedu použití pro snadnější pochopení.

Příklad:

1. Vytvořím hostgroup linux-servers.
2. Do hostgroup linux-servers vložím všechny linuxové servery.
3. Vytvořím advanced service SSH, která kontroluje dostupnost ssh serveru.
4. Service SSH přiřadím skupině linux-servers.

Všechny linuxové servery tak budou kontrolovány na funkčnost ssh serveru aniž by bylo potřeba to nastavovat u každého zvlášt. Pokud se v budoucnu rozmyslím, že chci změnit např. retry interval stačí ho změnit jen u advanced service SSH a změna se promítne na všechny servery.

Dependencies obecně

Systém Nagios umí potlačovat vybraná chybová hlášení, která mohou vzniknout při selhání některého hosta či service. Toto má několik důvodů: omezení počtu odeslaných hlášení celkově odeslání chybových hlášení jen těm skupinám administrátorů, kterých se problém opravdu týká rychlá izolace tzv. root cause Potlačení chybových hlášení lze provést pomocí parent/child vztahů a pomocí dependencies. Dependencies NEslouží k tomu, aby určily, zda je nějaká vysokoúrovňová služba funkční na základě posouzení funkčnosti nízkoúrovňové služby. Slouží tomu, aby když vysokoúrovňová služba hlásí chybu, tak aby tato chyba byla potlačena, protože nízkoúrovňová služba, na které je „silně“ závislá, také hlásí chybu a pravděpodobně je příčinou.

Parent/child vztah

Parent/child vztah je určen k potlačení chybových hlášení na základě fyzického síťového zapojení.

Příklad: Mám server. Tento server je zapojený do switche, tudíž switch je parentem serveru. Switch je připojen do routeru, tudíž router je parentem switche. Dojde-li k výpadku routeru, je hlášena chyba pouze routeru, protože chyby switche a serveru jsou potlačeny dle parent/child vztahů.

Service dependency

Service dependency slouží k potlačení chybových hlášení závislých služeb. Dependency by měla být použita na „silné“ závislosti mezi službami. Pro lepší pochopení uvedu dva příklady vycházející z .

Správný příklad: Mám LDAP službu a IMAP službu. Nastavím, že IMAP závisí na LDAP. LDAP služba spadne, Nagios detekuje chybu a prozatím řekněme, že chybu nehlásí. V dalším kroku Nagios detekuje chybu služby IMAP, protože se k ní nelze připojit. V tomto okamžiku Nagios vyhodnotí, že obě služby jsou v chybovém stavu. Protože ale IMAP závisí na LDAP nahlásí administrátorovi pouze chybu služby LDAP. Chyba IMAP je potlačena.

Špatný příklad: Mám službu HTTP a v ní e-shop. Funkce e-shopu závisí na OracleDB. Mylně nastavím, že služba HTTP je závislá na službě OracleDB. Dojde k výpadku OracleDB, je detekována chyba. V dalším kroku Nagios detekuje, že služba HTTP je v pořádku. Není tedy, co potlačovat. Ze špatného příkladu vyplývá, že je třeba určit, co je „silná“ závislost a co jsou opravdu předměty závislosti. Špatný příklad lze upravit a získat tak sice složité, ale funkční schéma.

Opravený špatný příklad: Mám službu HTTP, službu ESHOP, službu OracleDB. Vytvořím si vlastní command pro službu ESHOP, který ověřuje funkčnost e-shopu přihlášením testovacího uživatele. Nastavím, že služba ESHOP je závislá na službě OracleDB. Vypadne služba OracleDB, Nagios detekuje chybu. V dalším kroku Nagios detekuje chybu služby ESHOP, nikoliv HTTP. Služba ESHOP je závislá na službě OracleDB, Nagios hlásí administrátorovi pouze chybu OracleDB, chyba služby ESHOP je potlačena.

Host dependency

Host dependency slouží k potlačení chybových hlášení závislých hostů. Neměla by být zaměňována za parent/child vztah. Použití host dependency je vhodné pouze ve velmi specifické situaci. Zřejmě jde o logické doplnění k service dependency, ale v okamžiku existence parent/child vztahů není použití zřejmé.

Templates & inheritance

K ušetření práce, re-use již nastaveného a globalizaci nastavení slouží princip dědění a šablon. Obecný přístup v Nagiosu je, že vlastnosti libovolného objektu lze zdědit v objektu jiném. Libovolně lze pak vlastnosti v dědícím objektu přetížit. Lze definovat abstraktní objekty, které nejsou vidět v monitoringu, ale lze jejich vlastnosti zdědit. NConf modifikuje přístup tak, že připouští pouze dědění abstraktních objektů a ty jsou nazvány Templates. V případě services lze podobného chování dosáhnout s pomocí advanced service a hostgroup. U obojího jsou budoucí změny rozšířeny globálně.

Srovnání advanced service-host group a template

Lze nadefinovat advanced service, přiřadit jí hostgroup a služba se rozšíří na všechny hosty v hostgroup. Změnou advanced service se změní service pro všechny hosty. Výhoda je, že není třeba u každého hosta service přidávat. Nevýhoda je, že všechny nastavené vlastnosti jsou pro všechny hosty v hostgroup fixní a nelze je pro jednotlivého hosta změnit. Naproti tomu lze nadefinovat template service a pak u každého hosta vytvořit service a použít tento template. Všechny vlastnosti jsou zděděny do nové service. Změna template změní všechny service u všech hostů. Výhoda je, že lze u každého hosta libovolnou vlastnost service přetížit a upravit na míru hostu. Nevýhoda je, že se musí u každého hosta service přidat.

Doporučení

Tento oddíl shrnuje doporučení na úpravu monitorovacího systému Nagios. Základem je porovnání současného stavu a nově zdokumentovaných funkcí.

Hostgroups

Hostgroups jsou v současném systému používány středně. Navrhuji provést revizi stávajících hostgroups a vytvoření nových tak, aby bylo možné používat advanced services.

Servicegroups

Service groups nejsou používány vůbec. Jejich používání doporučuji pro zvýšení přehlednosti ve webovém rozhraní. Lze doporučit vytvoření servicegroups souvisejících služeb jako např. HTTP služby apod.

Advanced services

Advanced services nejsou používány vůbec, veškerá konfigurace je provedena ručně/kopírováním služeb/templates. Používání advanced services lze více než doporučit. Stávající service templates mohou použití advanced services komplikovat a je třeba k tomu přihlédnout. Advanced services jsou dobré v kombinaci s hostgroups, ale ruční přiřazování jednotlivých hostů nemohu doporučit.

Dependencies

Parent/child vztahy jsou používány na dobré úrovni. Naopak dependencies nejsou používány vůbec. Host dependencies nemohu doporučit, protože není příliš jasné, k čemu by se hodily. Service dependencies mohu jen částečně doporučit. Jejich konfigurace je obtížná a v případě chyby mohou být potlačena důležitá chybová hlášení.

Monitorování clusterů

V současném systému je monitorování clusterů a složitějších procesů monitorováno pomocí plug-inu check_multiple. Možnou alternativou by mohl být plug-in check_cluster, který je přímo určen k monitorování clusterů. Doporučuji tedy tento plug-in podrobit bližšímu testování. Více informací v , a .

Monitorování složitějších procesů

K monitorování složitějších procesů v současném systému je používán plug-in check_multiple. Lepším řešením by mohlo být použití plug-inu Business Process AddOn. Tento plug-in umožňuje vytvářet složitější hierarchie, and/or vazby a modelování systémů. Slouží především k monitorování vysokoúrovňových aplikací, které jsou chápány jako produkt pro interního nebo externího zákazníka např. aplikace Portál. Každý produkt se skládá z jednotlivých služeb, jako z komponent na kterých je závislý.

• Business Process AddOn se skládá ze dvou základních částí:
• Business Process View – Agreguje výsledky jednotlivých kontrol Nagiosu a zobrazuje je v procesu.
• Business Impact Analysis – Umožňuje simulovat výpadky a experimentálně ověřit, které produkty jsou nefunkční, pokud selže některá z komponent.

Krátké představení lze nalézt na , více informací o plug-inu lze nalézt na .

Komentáře

Téměř u všech hostů a služeb chybí jakékoliv komentáře. Doporučuji komentáře doplnit, aby další, kteří se systémem pracují a neznají funkce jednotlivých serverů, byli schopni jejich funkci pochopit.

Závěr

Monitorovací systém Nagios CIV ZČU nijak výrazně nezaostává za ostatními organizacemi. Orientaci v něm pouze snižuje absence komentářů. Určitě by mělo být vylepšeno používání advanced services. Používání service groups je volitelné, ale doporučené. K problému monitorování clusterů a složitějších procesů by mělo být provedeno další zkoumání doporučených plug-inů.