U zákaz­níka jsme měli nasazené řešení (sestávající se z několika málo desítek kompo­nent), ke kterému jsme posky­to­vali second level support. Selhání byť jediné kompo­nenty mohlo způsobit zasta­vení celé produkce. Identi­fi­kace toho, která kompo­nenta zapříč­i­nila výpadek, bylo zbytečně zdlou­havé. Nehledě k tomu, že jsme nedokázali problémy dosta­tečně předvídat. Zákazník zcela logicky začal požadovat monitoring celého řešení.

Velkou část minulého roku jsem tak strávil s monitorin­gem. Nepovažuji se v dané proble­ma­tice za odbor­níka (podle kompe­tenční matice bych to viděl tak na n2), ale minimálně si chci napsat pár poznámek pro sebe, abych vše nezapom­něl. Měl jsem zahrnout monito­rování do Joel Test 2.0, protože si dnes už nedokážu předs­tavit provo­zovat komplexní systém bez monitoringu.

Chci se nejprve obecně věnovat proble­ma­tice monitoringu a pak konkrétní imple­men­taci a to Nagios, respek­tive Eyes of Network, které nad Nagiosem staví.

Úvod do monitorování

Co to je monitoring? Z mého pohledu jde o sledování a hlášení kritic­kých chyb, nebo ještě lépe včasné varování, pokud se nějaká chyba blíží. Mezi základní kritéria si můžete předs­tavit volné místo na disku či operační paměti, čas do vypršení certi­fikátu, ping, telnet… Předs­ta­vi­vosti se meze nekla­dou. Mám vyzkoušené, že analýza toho, co monito­rovat a jaký nastavit threshold (práh, hranice) zabere mnohem víc času než samotná imple­men­tace, která je v podstatě jedno­duchá. Platí, že měření by nemělo ovlivnit měření či v lékařské termi­no­logii vyjádřeno primum non nocere (především neškodit).

Technologie

Job trends na Indeed.com

U samot­ného výběru techno­logie jsem nebyl, šlo o politické rozhod­nutí, ale myslím, že (zpětně viděno) šlo o dobré rozhod­nutí. Byla vybrána techno­logie Eyes Of Network (dále jen EoN) posta­vená na techno­logii Nagios, která je de facto průmys­lovým standar­dem. Jedná se o open-source řešení (pod licencí GPL2, se kterou ovšem můžete někde v komerční sféře mít problémy, ale neměli byste, protože k EoN budete nejspíš přistu­povat jen jako k black-box). Distri­buo­vané jako CentOS image. Projekt sponzo­ruje firma APX, u které si můžete objednat konzul­tanty. Jediná nevýhoda je, že je to francouzský kód, takže občas na mě v logu nebo některých návodech vykoukla francouzština.

Archi­tek­tura Eyes of Nework, zdroj: www.eyesofnetwork.com

Nagios

Pár termínů, se kterými se setkáte v Nagiosu. Host je cokoliv, s čím se domluvíte přes TCP. Service je logická entita, která běží na hostu (pozor, nezaměňovat za windows service).

Hard/soft state, zdroj: JBsWiki (cc-by-sa 3.0)

Nagios rozlišuje tzv. hard a soft state. Jde o to, že když se zatoulá jeden ping, tak aby vás to zbytečně neděsilo či dokonce nebudilo. Indiku­je-li se chyba, výrazně se zkrátí interval kontroly a teprve když se chyba potvrdí, přepne se do hard state.

SNMP

SNMP (Simple Network Manage­ment Protocol) je protokol pro správu sítí, ale my ho můžeme využít i pro monitoring, aniž bychom museli insta­lovat nějaké agenty (o nich později). Můžete tak monito­rovat třeba místo na disku, volnou operační paměť…

Potře­bu­jete, aby vám na monito­ro­vaném stroji běžela windows služba SNMP (pokud ne, musíte si featuru přidat). Službu si musíte nasta­vit. Bude vás zajímat především commu­nity name, stačí přístup READ ONLY. Dobré omezit na IP adresu monito­ro­vacího serveru. Ano vím, lze podvrh­nout, ale jednak jsme zapnuli READ ONLY režim a jednak doufám, že vaše síť má ochranu proti ARP poisoning. Každopádně vyšší verze SNMP už umí i TLS (nezkoušel jsem).

Lokální Pluginy

Pro Nagios existuje kvanta pluginů, takže dost možná nebudete muset psát žádný vlastní. Ale i kdyby, tak psát vlastní Nagios plugin je triviální. Můžete použít libovolný progra­mo­vací či skrip­to­vací jazyk, vystačíte si s pár status kódy a formátováním textu. Ty již hotové jsou často Perlu, ale když pluginy pouze spouštíte, tak vás to nemusí děsit. To jen připomínka, kdybyste se v nich chtěli vrtat.

Namátkou jmenujme pár, se kterými se nejspíš setkáte. Předně check_snmp je potřeba pro monito­rování SNMP (podrob­nosti viz výše). S pluginem check_http můžete kontro­lovat HTTP status kódy, (ne)přítom­nost konkrét­ního textu, platnost certi­fikátů… Pro monito­rování Oracle databáze slouží check_oracle_health. Pozor­nosti javistů by neměl uniknout plugin check_jmx.

Vzdálené pluginy

Předchozí pluginy se volají přímo z monito­ro­vacího serveru. Můžete ovšem potře­bovat kontro­lovat něco lokálně na daném hostu, ať už kvůli tomu, že potře­bu­jete přímý přístup na systém či daný protokol nepro­leze firewallem.

K tomu slouží NRPE (Nagios Remote Plugin Executor), protokol založený na TCP/IP. Pomocí pluginu check_nrpe provoláte na hostu agenta.

NSCLIENT

Nejznámější agentem je NSClient++ pro operační systémy MS Windows. Díky němu můžete volat VB skripty, BAT, EXE a v neposlední řadě PowerShell.

zdroj: nsclient.org

JNRPE

Existuje i Java klient JNRPE. Pokud imple­men­tu­jete vlastní plugin v Javě (návod bohužel zmizel!), tak se s každý checkem nespouští separátní JVM.

Nagvis

Díky Nagvis, který je součástí EoN, si můžete monito­ro­vanou platformu vhodně vizua­li­zo­vat. Jako pozadí si vyberete libovolný obrázek a pak nataháte bubliny, které repre­zen­tují jednot­livé service nebo host.

zdroj: nagvis.org

Zkušenosti

EoN podpo­ruje šablony (templa­te), takže je dobré je využívat, abyste si ušetřili práci. Lze tak nadefi­novat třeba šablonu pro Windows host, která bude zahrnovat kontrolu rozhraní (např. Hyper-V), ping, disku a operační paměti. To se bude kontro­lovat na každém hostu, ale přidáte si speci­fické kontroly pro daný host a jednot­livé service.

Kde se musí monitoring auten­ti­zo­vat, je kvůli bezpeč­nosti potřeba použít speciál­ního uživa­tele s omezenými právy. Ukázka pro databázi Oracle.

Dost se mi osvědčil PowerShell. Ne že bych skripty raději nepsal v Groovy, ale Power­Shell je v podstatě na každé windows mašině.

Co jsme v první fázi neřešili, protože bychom na tom analy­ticky strávili dost času, jsou notifi­kace a eskalace. Systém může posílat třeba SMS nebo e-maily, přičemž pokud ten, kdo drží službu, neopraví chybu do nějaké doby, tak se upozorní například jeho nadřízený. Zase je to víc o byznys procesech.

Škálování bych se nebál. Naše nasazení mělo řádově stovky kontrol. Ale chlapci z APX tvrdili, že (jestli si dobře pamatu­ji), v Airbus továrně na vrtul­níky mají 20 tisíc kontrol.

Závěr

Pokud pouze nedodáváte hotové řešení, ale rovněž ho i provo­zu­jete, rozhodně bych po nějakém, byť minimálním monitoringu sáhnul. Za sebe můžu říct, že Nagios v podání Eyes of Network byla dobrá volba a že i placená podpora od APX v případě složitějšího systému stojí za zvážení.

Edit

Martin Stiborský mě na twitteru upozornil na Incinga, jedná se o fork Nagiosu. Podle dema vypadá pěkně a respon­zivně (hlavně ve srovnání s EoN). Při nějakém dalším monitoringu určitě zvážím, GUI mě nalákalo a téměř vše výše řečené tam bude platit taky.