Doporučte monitoring pro SNMP

[PCnity]

Hello,

O monitoringu je toho pisaneho velmi vela, TL; Did Read, napriek tomu som nedosiel k ziadnemu zasadnemu zaveru. Od bashingu nagiosu a jeho klonov pre zastaralost, az po rozne moderne systemy pouzivajuce akysi ESB na prenos sparv a midlleware si clovek musi zriesit sam... Je toho vela.

Moja situacia je do urcitej miery specificka: Potrebujem "monitoring" skoro vyhradne na boxy [specificke appliance, mimo scope-u prispevku] ktore dokazu vsetky co chcem vediet odpovedat cez SNMP protokol... Cize ziaden agent beziaci priamo na akejsi ditribucii, ale viac menej centralny cluster ktory bude konstatne zistovat stav cez SNMP a v pripade akejsi "nespravnej" hodnoty to vykona akusi akciu (mail/sms/script).

Doteraz som monitoring nikdy priamo riesit nemusel, starali sa o to iny [nagios, neskor opsview]. Treaz to vsak bude na mne. Mate nejaky tip ktory system pouzit? Nagios? Opsview? Iny fork Nagiosu? Zabbix? Nieco uplne ine?

Dakujem za kazdy input.

[Reklama]

[dodopolly]

Skus pozriet na Zenoss (http://www.zenoss.org/).

[PCnity]

Zenoss je sice vyzdvihovany pre jeho podporu SNMP, ale vo vacsine porovnavacich clankov sa riesi pri zabbixe verzia 1.8... Pricom prave vo verzii 2.2 sa "ze vraj" velmi zlepsila podpora SNMP.
Preco Zenoss?

To iste plati pre ostatne... Preco Zabbix? Preco Nagios (OMD, check_mk)? Preco nieco ine?
Ako ste si vy zvolili vas Monitoring? Ste spokojny s vyberom? Planujete prechod na nieco ine?

Google trends su zaujimave: https://www.google.com/trends/explore?q=nagios#q=nagios%2C%20opsview%2C%20zabbix%2C%20zenoss%2C%20check_mk&date=1%2F2010%2060m&cmpt=q

Nagios pada... Zabbix stupa... Zenoss pada tiez.

[Togusa]

Ahoj,

já mám zkušenosti s Nagiosem a Zabbixem. Já osobně spatřuji velkou nevýhodu ve správě Nagiosu, protože když chce někde něco upravit, tak musí přepisovat konfigurační soubory (ale tohle se třeba změnilo, už dost dlouho jsem ho nepoužíval, třeba nějakou nadstavbou to lze pořešit)

Zabbix je super v tom, že má webové rozhraní, ve kterém lze nastavit téměř vše. Když je potřeba, tak si můžeš volať klidně nějaké svoje skripty. Uděláš si svoje šablony, pak už je jenom přiřazuješ daným zařízením. Když to vyplníš dostatečnými daty, tak údržba už je pohodička. Pár šablon se dá stáhnout, ale není jich zdaleka tolik. My to hojně používáme i na stavy tonerů v tiskárnách a tam třeba tolik šablon(alepoň funkčních moc nebylo). Pak si můžeš dělat grafy ze všeho a se vším najednou :-). Řekl bych tedy, že Zabbix je pohodlnější na správu, alespoň pro mě osobně.

[tdvorak]

já mám zkušenosti s Nagiosem a Zabbixem. Já osobně spatřuji velkou nevýhodu ve správě Nagiosu, protože když chce někde něco upravit, tak musí přepisovat konfigurační soubory (ale tohle se třeba změnilo, už dost dlouho jsem ho nepoužíval, třeba nějakou nadstavbou to lze pořešit)

My to řešili instalací Centreon, který se choval jako webové rozhraní pro konfiguraci + monitoring dat z Nagiosu. Veškerá správa nagiosu pak šla přes centreon a na konfiguráky se nemuselo vůbec sahat. Šablony pro monitoring stavu inkoustu/toneru jsem psal sám pro nagios, funkční jsem také nenašel. 

[Reklama]

[Mirek Prýmek]

viac menej centralny cluster

[rypnuti] Co presne si mam predstavit pod pojmem "centralni cluster"? Neco jako "suchou vodu"? [/rypnuti]

Je fajn, ze sis neco o veci precetl, ale naprosto klasicky z toho vubec nevychazis:

1. co se ti teda na tom, co sis precetl, nezdalo? Chybela ti tam nejaka informace a ted se nas na ni ptas? Nebo k cemu ti to precteni teda bylo? Jak se tyka problemu, ktery resis?

2. nepises poradne, co vlastne chces resit. Ono je neco jinyho sbirat data jednou za pet minut z deseti zarizeni v lokalni siti a neco jinyho jednou za sekundu z milionu zarizeni po cele planete...

3. nepises, jaky mas pozadavky - staci ti vedet "vsechna zarizeni jsou ok" (sumarizace binarniho stavu krabicek) nebo potrebujes graficky prehled, nebo chces treba dokonce graf toho, jak se ty hodnoty vyvijely?

4. jak slozita maji byt ta pravidla "kdyz neco, tak posli mail"?

SNMP klienta si v libovolnem dnesnim jazyce (treba v pythonu) napises na cca dvaceti radcich, k cemu teda potrebujes nejaky "monitorovaci system"?

[PCnity]

Mirek Prýmek: Nie je to uplne tak...

Centraly cluster je uplne normalne pomenovanie niekolkych serverov pracujucich z pohladu inych systemov ako jeden system. V tomto pripade tym myslim 2 fyzicke stroje v dvoch datacentrach [Bratislava a Nurnberg] ktore mienim cisto cez HB prevadzkovat v active/passive alebo active/active al to dany monitorovaci system bude umoznovat.

1) VSETKY systemy co som evaluoval [Nagios [omd], Zabbix, Zenoss, OpsView] dokazu to co chcem. Rozdiely su v konfiguracii, pripadne v moduloch na grafy... Tak ako Zabbix grafuje snad vsetko, v nagiose je to v podstate nadalej praca pre nejaky addon... Ci uz bezne RRD alebo som videl aj rozne exoticke nadstavby co drzali udaje v relacnych db.

Tu nejde o to ktory system splna poziadavky... Ale o SUBJEKTIVNE nazory preco vybrat nejaky konkretny z nich. Kto je spokojny s tym co ma, a kto by najradsej migroval na nieco ine.

2) Chcem zbierat data mozno z 10 GNU/Linuxov... Kludne agentom. A k tomu potrebujem zbierat data vyhradne cez SNMP z povedzme 20 az 100 boxov (specializovane appliance). Frekvencia na urovni kazdych 5 minut je viac nez dostacujuca... Ide hlavne o ZIJE/NEZIJE a PERFORMANCE data.

Davat to do grafov ma vzdy zmysel. Neexistuje nic lepsie na capacity management ako sledovat trendy vyvoja vytazenia... Ak budem mat v grafe aj statistiku ZIJE/NEZIJE vo forme akehosi percentualneho grafu availability sluzieb za dane obdobie, o to lepsie.
Toto vsak dokaze kazdy z hore uvedenych monitoring systemov... Akurat s rozdielonou namahou na strane admina.

Skalovatelnost k 100 - 1000 systemom do buducnosti je podstatna, ale ak sa nemylim, kazdy z hore uvedenych systemov ma danu vec nejako vyriesenu. Ci uz vo forme niekolkych samostatnych instancii + agregator dat, alebo dokazu pracovat v kaejsi paralelnej forme. Nemyslim si ze by som narazil na neriesitelny bottleneck pri ktoromkolvek z nich.

4) To je nieco co este neviem uplne odhadnut. Predtym som sa tym nezaoberal. V danom momente riesim primitivity typu zije/nezije kontrolou navratovej hodnoty a povedzme dafinovanie range hodnot pre urcite metriky (disk space viac ako 70% used, ukaz warning, viac ako 85% used, triggeruj nejaky kontakt/skript)

5) Pravdaze nie je problem tahat data z snmp, zatial mi stacil bash, snmpwalk, grep a awk.

Zmysel tejto temy je zistit kto co pouziva a ci je s tym spokojny. V danom momente mi nie je jasne ci chcem mat radsej akesi API na pridavanie novych targetov, alebo ci si radsej vygenerujem textovy config a reloadnem service... Flatfile my boli vzdy sympaticke, otazka je aky mess z toho vznikne po urcitej dobe a velkom mnozstve zariadeni. Puppet tiez riesi len cast problemu... Generuje config, kvalita vsak zavisi od admina a jeho schopnosti/skusenosti.

Nazorov je na oboch stranach prilis vela a casto sa navzajom vyvracaju. Ja nie som schopny posudit pravdu. Priklad moze byt flapping detection Nagiosu vs. Zabbix. Zabbix-aci hovoria ze false possitives su priamo sposobene debilnou konfiguiraciou, pricom clanky co vyzdvihuju Nagios popisuju akusi schopnost inteligentnej flap detection ktora setri adminov cas v pripade ze navratova hodnota kolise okolo thresholdu.

Zabbix ludia vyzdvihuju jeho vlastnost pchat kazdy udaj do grafu, nagiosaci zase vyzdvihuju jeho flexibilitu a neviazanie sa na ziaden grafovaci nastroj... A takto to ide do nekonecna. Zaujimaju ma skor osobne nazory/skusenosti.

[Mirek Prýmek]

Super, tohle jsem presne potreboval slyset, uz jsem doma Takze ti vlastne jde o klasicky monitorovani sitovych prvku a serveru, zadne exoticke krabicky, u kterych bys chtel merit janevim prutok vody. A taky vlastne nehledas konkretni reseni konkretniho problemu, ale ptas se tak nejak obecne na nase zkusenosti. Ok, pokusím se přispět troškou do mlýna, snad ti to k něčemu bude

Hele, prvně bych řekl, že to, že jsi četl různý silně protichůdný informace, je v téhle oblasti samozřejmý, protože zkušenosti se odvíjí od toho, jakou přesně situaci ten kterej admin řeší. Např. pokud jsi ISP, tak monitoruješ stabilní infrastrukturu a Nagios je pro tebe super, protože konfiguraci nepotřebuješ zas tak často měnit. Oproti tomu pokud máš nějakej elastickej klaud kdesi na AWSku a přibývají a mizí ti tam servery každých 10 vteřin, tak by ses z Nagiosu vosral... Takže prostě nečekej jednotný názory, spíš si všímej, na jakej typ nasazení se komu kterej sw osvědčil a proč *přesně* (co konkrétně na něm chválí a co ho štve).

Moje zkušenost:

Monitoruju stabilní infrastrukturu s malým počtem položek. Zkoušel jsem různý nástroje a zvolil jsem Nagios, protože se mi na něm líbilo, že jsem byl schopnej pochopit *přesně*, jakým způsobem funguje (prostě jednou za x minut spustí určitý skript, ten vrátí určitý kod, ten se pak hodí do RRD nebo se dá zpracovávat dalším skriptem atd. atd.) - prostě Nagios mi ze všech těch nástrojů přišel "nejunixovatější" - jasně oddělené části, které dělají jasně definované jednoduché ulohy. Takže mi dával nejlepší prostor si jednotlivý části přizpůsobit. Jo a taky není v Javě, to jsem považoval za velký plus

Postupně jsem jednotlivý čísti Nagiosu začal nahrazovat vlastními řešeními a nakonec mi zůstalo jenom jádro (scheduler), který jsem nakonec přepsal taky, takže ted už Nagios nemám, už používám jenom jeho pluginy

Nagios má v základu různý nevýhody, ale celkem všechno se dá překonat, bud pomocí check_mk nebo forků (icinga, schinken), ale jednu věc považuju za fakt velkou koncepční chybu: jednotlivý checky vracejí přímo STAV a kromě něj taky nějaký performance data. To je podle mě špatně. Checky by imho správně měly být koncipovaný jenom jako senzory, který vrací hodnoty a nad nima je pak nějakej vyhodnocovač, kterej řekne, jestli v kontextu ostatních hodnot je to ok nebo ne. Tahle koncepční chyba se pořádně nedá překonat, protože od stavu, kterej vrací check, se odvíjí i rescheduling. Takže dost těžko se dá na Nagios naroubovat nějaká korelace eventů apod. Pokud ji chceš, tak Nagios je slepá ulička. Tohle byl hlavní důvod, proč jsem si ho pro svoje potřeby přepsal. Jinak je to ale hezkej kus sw, žádná pětisetmegová hipsterská pětisetmegová srágora která jenom pro sebe potřebuje spešl cluster

[ondra2]

omd (omdistro.org) (resp. check_mk + nagios + spousta dalších věcí). Asi nejlepší varianta, co jsme viděl. Jednoduchá konfigurace, jednoduchá rozšířitelnost, docela přehledné GUI, docela pochopitelný systém konfigurace. Možnost si jednoduše napsat SNMP plugin. IMO asi momentálně nejlepší, co v této oblasti existuje. (na různé korelace událostí to není, ale pro monitorování SNMP a jiných síťových záležitostí je to ideální)