MUNIN, sieťový monitorovací framework (diskuse)

[MAx]

Podporuje Munin nějaké jednoduché (ideálně HTTP) API, přes které je možné získávat surová data (ne grafy)? Aby bylo možné data zpracovávat a analyzovat vlastními nástroji.

[Ivan]

Skus https://github.com/munin-monitoring/contrib/blob/master/tools/munin2json/cgi-bin/munin-cgi-datafile

[MAx]

Díky.

[Jan Kundrát (jkt)]

No, rekl bych k tomu tolik, ze kolegum, kteri Muninem monitoruji radove stovky serveru, nepomohlo kloudne ani umisteni RRD souboru na tmpfs, a to pouzivaji interval monitoringu peti minut. (Ted maji cca. 56k RRD souboru.)

Collectd v kombinaci s rrdcached oproti tomu dela dojem, ze je zcela nenarocne, ale je pravda, ze ho zatim mame nasazeny jen v mnohonasobne mensim meritku. Prave sbira cca. 6600 metrik kazdych 10 sekund a load je velmi, velmi blizko nule. Bude zajimave to rozsirit na vic senzoru.

TL;DR: velmi silne doporucuju prozkoumat collectd.

[Juraj Remenec]

Colectd je napísaný v C-čku. Verím, že oproti riešeniu v skript. jazyku ponúka neporovnateľne vyšší performance. Ale keď som ho riešil naposledy, tak zapisoval hodnoty do RRD fajlov. Na generovanie grafov bolo treba použiť ďalšiu, inú utilitku. Vtedy som hladal riešenie, ktoré v sebe nieslo tak trochu zo všetkého niečo. Neviem ako je na tom dnes.

[Jan Kundrát (jkt)]

Collectd sbira a posila data. Jeden z pluginu, ktery umoznuje data zapisovat, vyuziva RRD soubory -- jenom drobne upresneni.

Co se tyka grafovani, ano, samotny collectd to sam od sebe nedela. Nicmene nastroju pro kresleni, ktere si rozumi s daty z collectd, je mnoho, viz seznam.

Interne kreslim pres collectd-web.

[ebik]

Pod toto bych se podepsal, Munin (defaultně) vykresluje grafy každých 5 minut, což znamená, že pokud se podíváte na něj ten den jen jednou tak vidíte jen 1/288 obrázků, a to jedině tehdy, pokud se podíváte na všechny vygenerované grafy (je jich typicky o řád víc, než sledovaných strojů). Ale i bez grafování jsme u stovek strojů měli problém, aby to munin vždy stihnul a nevypadl občas jeden "cyklus". Nicméně tehdy množství napsaných pluginů a jejich snadná úprava/vytváření dalších (a také to, že počet sledovaných strojů se měl pomalu snižovat) byly důvody, proč jsme Munin používali. Hlavní nevýhodu "statického" grafování ale vidím v tom, že se nedá zoomovat.

Dnes sleduji jen jeden stroj, takže nemohu posoudit výkonost, ale na on-line zoom v grafech se mi osvědčil již zmíněný collectd-web. Výhodu to má, že grafy vykresuje browser, a server tedy vůbec negrafuje, jen poskytuje rrd soubory přes http.

[ebik]

Pardon, spletl jsem si collectd-web a jarmon. Ten druhý je ten co grafuje v browseru a tedy vůbec nezatěžuje server grafováním.

[Jiří Lisický]

To rrd přes javascript vypadá zajímavě. Existuje i nějaký fallback pro přepnutí na klasický png graf pro prohlížeč, který neumí nebo má nedokonalý/pomalý javascript?

Dá se někde podívat na nějaké živé demo?

[ebik]

Obávám se, že fallback je většinou nejjednoduší vyřešit na straně uživatele - když bude jarmon jen jedním z více frontendů, tak si uživatel zvolí, na který se chce zrovna podívat. (Ona sada několika RRD může být větší datový tok, než jedno PNG. Ale pak se v tom dá zoomovat a pohybovat, bez dalšího načítání). Živé demo jsem nenašel..., ale našel jsem http://pommi.nethuis.nl/collectd-graph-panel-v0-4/ - podle toho videa se mi ty grafy líbí víc, než ty v jarmonovi, ale ještě jsem to nezkoušel.

[Pista]

Nepremyslali ste miesto statiky pouzit fastcgi?

[karel]

mam dotaz asi spatne hledam ale nenasel jsem nic o zabezpeceni nodu konfigurace pres telnet je pekna vec ale nemusi to delat kazdej na siti.

[Juraj Remenec]

Narážate na nezabezpečenú komunikáciu cez telnet?
Uviedol som, že je možné nakonfigurovať munina na používanie TLS/SSH tunnela, tak aby nemohol niekto medzi vami odpočuť hodnoty ktoré sa vymieňajú. Viac som sa tomu v článku nechcel venovať nakoľko možností ako toho dosiahnúť je viac. Pre bližšie info odporúčam: http://munin-monitoring.org/wiki/MuninConfigurationNetworkTLS
alebo pre SSH tunneling: http://munin-monitoring.org/wiki/faq#Q:HowcanIuseanSSHtunneltoconnecttoanode

Čo sa týka zamedzenia konektu na noda - nod používa Allow direktívu vo svojom konfiguračnom súbore v ktorom je uvedená povolená IP adresa alebo si niečo takéto zavediete do pravidiel firewallu.

[Yenya]

Už nějakou dobu hledám lepší nástroj na monitorování než je kombinace MRTG, Smokeping a Nagios. Ale teda vypadá to, že Munin to spíš nebude. Možná Zabbix, ale ani ten není přesně podle mých požadavků.

Nějaké požadavky jsem sepsal tady:

http://www.linux.cz/pipermail/linux/2014-June/272898.html

Jde například o možnost zobrazovat schémata a v reálném čase sledovat stav. Nebo ukládání velkého množství proměnných a přehledného zobrazení jen některých z nich: například ethernetové switche dávají v SNMP informaci o zahozených packetech, o broadcastech, atd., ale to není to, co by člověk za normálních okolností chtěl vidět. Toto potřebujeme jen pokud lovíme nějaký konkrétní problém. Ale pak je dobré už ta data mít, aby šlo porovnávat, co tak zhruba je "normální" a co se změnilo.

-Yenya

[ebik]

Osobně bych to rozdělil na dva systémy. Jeden upozorňovací (nagios) a jeden grafovací. Jde o to, že ten grafovací sbírá výrazně více dat, a případné úpravy (byť jen konfigurace) by mohly rozbít upozorňovací systém. V předchozím zaměstnání jsme měli vlastní upozorňovací systém na hlídání služeb, cricket na hlídání "provozních údajů (volné místo, load, ...)" a munin na grafování. V současném zaměstnání (už nejsem provozák, ale) provozní oddělení používá nagios na upozorňování a zenoss na grafy a obecný přehled o strojích.

[Zdenek 'Mst. Spider' Sedlak]

My pouzivame kombinaci Nagios+Cacti, na kazdem stroji pak Monit. Munin mame jako zalohu.

[Chulda]

zabbix to asi taky nebude. Kolega se v něm hrabe a má to spoustu různých "ale" až "ALE!", kvůli kterým s díky zůstaneme u nagiosu :(

poslední ALE - rekonfiguroval síť na testovacím routeru, který v zabbixu měl spoustu sledovaných parametrů a zřejmě kvůli přetížení zabbix vyhlásil falešný alarm na switchi. Probral se to až po restartu, 14 hodin před restarem stále trval na svém i když se už všechno uklidnilo.

[Jezekus]

To je zajimave info, ja jsem prave chtel zkusit nasadit zabbix misto nagios+munin

[Program]

Zkuste ho. Podle toho příspěvku nechápu v čem byl problém. Zabbix prostě sbírá data a upozorňuje, pokud se aktivuje nějaký trigger (typicky překročení nějakého thresholdu), kdy Vám ale poví, co konkrétně je špatně (resp. jinak, než by mělo být).

Pokud byl alarm falešný, tak buď switch/router vracel špatná data nebo se v důsledku rekonfigurace nějaký parametr dostal na hodnoty na které by se dostat neměl a pak je na adminovi, aby situaci posoudil. Ale není vinou zabbixu, že upozornil na skutečnost, která byla pravdivá.

Zabbix je bezvadný monitoring, který je navíc neskutečně ohebný. Nagios je mrtvola, s cacti a munin nemám moc zkušeností, ale ačkoli je rrd fajn věc, tak může být omezující.

[Chulda]

Problém byl v tom, že nemohl vyčíst router, na kterém byla spousta testů, protože v ten moment byl router nedostupný. Odhad je, že zabbixu se naštosovala tuna testů, která se ukončila až po timeoutu. A protože se vyčítala často (tuším každou minutu), tak tohle ten zabbix zabilo. Ale je to jen dohad a jednalo se o lab, takže nás to tolik netrápilo, jen rozladilo.

Rekonfigurace routeru, nikoli routingu nebo testů či zabbixu. Neměl se jak k té hodnotě dostat, kdyby ji opravdu vyčetl. A znovu (správně) ji pak už nevyčetl až do restartu zabbixu, který proběhl až 14h po té události.

Neskutečně ohebný? No, jak spustíte test mimo pořadí, protože z provozních důvodů je běžný check pouze jednou za 30 minut a problém je již opraven?

Jak změníte timeout 30s pro check nebo discovery?

Trochu chápu, proč to změnit nejde, ale ohebnější pro to není.

Jako je fajn, co s ním lze dělat díky triggerům. V tomhle má výhodu oproti nagiosu, kde check a vyhodnocení výsledku je neoddělitelně spojeno, což je často problém.

Na druhou stranu trigger pracuje s hodnotou uloženou v historii. Pokud by alarm trval déle než je historie, tak hláška "problém na rozhraní XY" se změní na "problém na rozhraní UNKNOW". Jde to obejít, ale hloupá komplikace.

A nagios mrtvola? Proč, protože není v javascriptu? To mě netrápí, backend mi šlape tak jak má a není problém zopakovat check mimo pořadí!

[Program]

Zabbix dotazy nehromaní. On tam má sice "frontu", která ale není frontou, je to seznam itemů, které nestihl přečíst. Ale další pokus provede až v dalším naplánovaném termínu (podle periody itemu).

Já už asi vím, co se Vám stalo. Tam byla delta hodnota a tím, že to 14h bylo dole, tak ten rozdíl byl obrovský a vyhodilo to trigger. Ale to přece není věc, která Vás vyvede z míry. Tohle přece těžko je kritická eventa a navíc se to dá čekat, mrknete na graf a je jasno. A pokud by to byla kritická hodnota, tak tam budete mít měření často a za pár vteřin Vám dojde OK. V tomhle fakt nevidím problém.

Timeouty jdou nastavit 1-30s. Těch 30s max je občas nepříjemných, ale je tam proto, aby se server nezahltil otevřenými spojeními. Pokud potřebujete měřit něco, co trvá dlouho, použijte cron+zabbix_sender (zabbix trapper eventa). Takže to ohnout jde.

Obecně s tou ohebností, pokud si myslíte, že v zabbixu něco nejde, tak to jde, jen nevíte jak (osobní zkušenost). Už jenom proto, že zabbix má JSON RPC api, díky kterému můžete udělat snad úplně vše.

Testy mimo pořadí dělat myslím nejdou. Což mě nikdy netrápilo, pokud je itema důležitá, tak se stejně měří řádově v sekundách a pokud nějakou dlouhou chci mermomoci přečíst, tak jí na chvíli nastavím krátkou periodu. A pokud to chcete mít jó jednoduché, máte zabbix api.

Trigger delší než historie. To je snad hypotetický stav se kterým jsem se vživotě nesetkal. Spíš je problém, že zabbix neumí zahlásit, že itema se stala unsupported -> řeším přes zabbix api.

Nagios je mrtvola. Ne protože má škaredé rozhranní, ale protože už se snad 20 let nevyvýjí, spousta featchur tam není, vlastně nagios neumí ani sbírat data (teda dá se to udělat, ale už je to obezlička, tohle je základní featchura, která prostě má být zabudovaná) nedejbože dělat grafy, všechno se ukládá do txt souboru. Konec konců cacti vzniklo právě proto, že nagios se přestal vyvýjet a zastaral. To je prostě fakt, on dokáže posloužit dobře, ale do firmy bych no nenasazoval, jsou prostě lepší možnosti.

[lolofon]

Prehlad monitoring systemov je na wiki: https://en.wikipedia.org/wiki/Comparison_of_network_monitoring_systems

Ad Zabbix:
(pre politicku korektnost je potrebne spomenut ze mam Zabbix certifikaciu a je to moj preferovany system)
> No, jak spustíte test mimo pořadí, protože z provozních důvodů je běžný check pouze jednou za 30 minut a problém je již opraven?
Zmen docasne collection interval na 1 sekundu a bude spusteny o 1 sekundu.
> Jak změníte timeout 30s pro check nebo discovery?
zabbix agent - configuracia Timeout
> Navic ma nejak agregovana data po urcite dobe, ja bych asi chtel uchovavat plna data - disky jsou velke.
Mozes nakonfigurovat osobitne per item. V kludne aj na 5 rokov ked mas velke disky.
Ak mas dalsie otazky/problemy odporucam pytat sa na zabbix fore/irc.

Ad Nagios:
Stop using Nagios (so it can die peacefully)
http://www.slideshare.net/superdupersheep/stop-using-nagios-so-it-can-die-peacefully
https://www.youtube.com/watch?v=Q9BagdHGopg
Ja sa zdrzim nevhodnych komentarov na Nagios adresu.

Ad RRD:
Momentalne robim s Zenossom (popularny hlavne v USA), ktory tiez pouziva RRD. 250k metrik v RRD (rozlozene po viacerych kolektoroch s rrdcache) - jednoznacne nie. Ziadna flexibilita a API v style rrdtool dump :-P.
Na druhej strane Zenoss ide v dalsej verzi do bigdata - data budu v OpenTSDB (HaBase) + deployment cez novy hype - docker.

Sumarne:
Monitoring zamrzol v 90 rokoch (Caskey z Google https://www.usenix.org/conference/lisa13/working-theory-monitoring). Ano niektore riesenia pouzivaju nove technologie OpenTSDB, influxdb, Logstash (elasticsearch), splunk, ... ale stale nevidel poriadne komplexne riesenie ktore by ponukalo naraz realtime monitoring spolu s analyzou, detekciou abnormalii/korelacii a vizualizaciou problemov v ramci infrastuktury.
Z ocakavanych novych monitoring rieseni cakam na oficialny release od https://www.dataloop.io/ - aj ked ten nagios styl sa mi moc nepaci.