MUNIN, sieťový monitorovací framework

12. 6. 2014 | Juraj Remenec | Návody | Různé | 6030×

Hugin („myšlienka“) a Munin („pamäť“ alebo „myseľ“) boli podľa severskej mytológie dva havrany boha Odina. Každý deň ráno sa vydávali na dlhý let svetom Midgárdu, aby zbierali rôzne informácie ktoré videli a počuli a ktoré mu na konci dňa pošepkali do ucha.

Práve podľa Munina sa rozhodol autor pomenovať nástroj o ktorom chcem dnes pojednávať. Nástroj, ktorý monitoruje všetky vaše počítače a „spomína“ na to, čo vidiel. Výsledky sú reprezentované grafmi, ktoré sa zobrazujú prostredníctvom webu. Porovnávaním výsledkov z rôznych časových úsekov tak môžete veľmi prehľadne a ľahko zistiť, „čo sa zmenilo“ v porovnaní s minulosťou, keď ste zaregistrovali na niektorej svojej službe problémy či už ohľadom jej výkonu alebo problémy týkajúce sa monitorovaného stroja.

Obsah

• Ako to funguje
• Príklad
• Alternatívy? Je ich celý kopec.
• Inštalácia a minimálne požiadavky
• Inštalácia zo zdrojových kódov
• Inštalácia z balíkov (repozitárov)
• Overenie funkčnosti alebo „Prvé spustenie“
• Pluginy
• Konfigurácia pluginov (/etc/munin/plugin-conf.d)
• Náš vlastný plugin a testovanie (nie len jeho) funkčnosti
• Vzdialené monitorovanie
• Zasielanie mailov
• Zamyslenie na záver

Ako to funguje

Munin je framework a skladá z dvoch častí. Munina (Mástra) a Munin-nodu. Munin katalogizuje a zobrazuje výsledky, zatiaľ čo nódy pracujú na jednotlivých počítačoch a starajú sa o zber týchto údajov na nich. Z uvedeného vyplýva, že na jednom mieste môžete mať skatalogizované prehľady zo všetkých vašich strojov a nemusíte si po výsledky chodiť na každý z nich jednotlivo. V praxi je to máster, ktorý sa pýta všetkých nakonfigurovaných nodov na aktuálne výsledky, sieťovým spojením vytvoreným v pravidelných intervaloch, na TCP port vzdialeného počítača (défaultne 4949), na ktorom munin-node beží. Jeden node môže komunikovať s viacerými mástrami. Je to užitočné, napríklad keď sa o server starajú viacerí ľudia a nechcete, aby mal niekto možnosť okukovať aj výsledky z vašich ďalších strojov – nainštalujete samostatne mástra pre neho. Dobré si je však uvedomiť, že to Munin (máster) spravuje databázu s výsledkami a „pamätá si“. Využíva pri tom dobré známy RRDTool.

Node pracujú s pluginami. To tie sú zodpovedné za zber údajov z jednotlivých služieb. Nód spraví len to, že pluginy spustí a čaká na výstupy z nich. Krásne na tom je, že sú jazykovo nezávislé na Nóde. T.z., že plugin (aj keď je väčšina z nich v Perle) môže byť naprogramovaný v akomkoľvek jazyku v ktorom ak dodržíte syntax výstupu, dokáže node výsledky prevziať. Munin sa inštaluje s veľkým množstvom už pripravených pluginov pre monitorovanie tých najbežnejších služieb (Apache, Postfix, vsftpd, Exim, Bind, SQL, NTP či rôzne tools ako ping na hosta, df, du, lmsensors, SNMP, či smartd). Autor deklaruje „plug-and-play“, takže naozaj stačí plugin len aktivovať a dôjde k okamžitému zberu údajov bez nutnosti väčších konfigurácií.

Zbieranie údajov a vytváranie grafov nie je to jediné čo Munin dokáže. Aj keď si dovolím tvrdiť, že primárne je určený práve na toto, dokáže mimo toho posielať maily, kontaktovať služby ako Nagios alebo spúšťať užívateľské skripty pri rôznych situáciách ktoré môžu nastať. Pri monitoringu naplnenosti disku môžeme napríklad určiť pri akých percentách má poslať varovanie a pri akých je to už kritický údaj, ktorý sa navyše zobrazuje aj v prehľade pri samotných grafoch. Munin reaguje aj na chybové návratové kódy programov, ktoré sa spúšťajú skrze pluginy ako smartd či lmsensors.

Príklad

Príkladov diagnostikovania problémov na (nie len) serveroch prostredníctvom Munina je bezpočetné množstvo. Uvádzať všetky možné scenáre by bolo na tri ďalšie články, preto len tak letmo načriem do pár príkladov uplatnenia Munina.

Nejaká „rastúca“ spoločnosť, zaznamenala v uplynulom období problémy so svojím informačným systémom v podobe ukončujúcich/umierajúcich procesov na svojich serveroch. Aj keď prvé kroky viedli k upgrade CPU a RAM, problémy to nevyriešilo. Preto sa rozhodli nainštalovať komplexnejší monitoring systému (práve Munin), ktorý odhalil pravý dôvod problémov. (Prevzaté z echoman.com.au)

Detaily grafov pre nás nie sú zaujímavé, preto z nich vypichnem len určitú časť. Prvý graf ukazuje vyťaženie procesora naprieč celým dňom. Zaujímavá je tá, „pahornatá“ fialová časť v obedných úsekoch. Podľa legendy sa jedná o IO Wait v ľudskej reči o čas zabratý systémom spotrebovaný na prístup k disku. Druhý graf, ktorý monitoruje konkrétny storage taktiež ukazuje nárast latencie (čas potrebný pre odpovede na requesty). Grafy teda odhalili diskový storage absolútne nezvládajúci nové nároky celého informačného systému a poukázali tak na nutnosť navýšiť IOPS.

Stredná škola bez interného správcu, ktorá si z projektu zakúpila a vybavila dve nové počítačové učebne, sa stretli s problémom počítačov, na ktorých sieť striedavo nabiehala a na druhý deň opäť nešla. Pohľad na graf s dhcp poolom pomohol objasniť problém za pár sekúnd.

No a takto to dopadne, keď do stien miestnosti, kde je aj živý server, začnú vŕtať a sekať drážky pre nové vodovodné potrubie bez toho, aby sa všetka technika niekam dočasne presťahovala ďaleko od všetkého prachu v ovzduší

Alternatívy? Je ich celý kopec.

Munin nie je jedinou odpoveďou na monitoring systému. Pre konzervatívnych užívateľov je tu stále k dispozícii MRTG, ktorý sa teší veľkej obľube ešte aj dnes. Pre väčšie siete je vhodné zvážiť projekty ako Cacti či Nagios. Konkurenciou Muninu môže byť aj Monitorix, ktorý sa tvári podobne, či monitorovanie prostredníctvom Colectd. Každý sa líši použitým typom jazyka, architektúrou, spôsobom fungovania, zberu dát, zložitosťou konfigurácie apod. Všetky však ponúkajú viac-menej to isté.

Munina som si hneď na prvý pohľad obľúbil pre jeho jednoduchosť a okamžitú funkčnosť pluginov ale i nenáročnosť na chod či nutnú konfiguráciu.

Ak používate iný monitoring a neplánujete ho v blízkej dobe vymeniť, môžete zvyšok článku kľudne odignorovať. Pre tých ostatných, dovoľte aby som Vám v krátkosti predstavil tohto „havrana“.

Inštalácia a minimálne požiadavky

Munin framework je celý postavený na jazyku Perl a od neho je aj bytostne závislý. Čiže či sa jedná o master alebo node časť, budete na oboch potrebovať:

• Perl aktuálnej verzie, minimálne však 5.8.
• GNU Make (v prípade inštalácie cez zdrojáky).
• Module::Build, štandardne súčasť Perlu 5.10 a vyššie. Pre menšie treba nainštalovať.
• Perl modul Time::HiRes.

Pre master časť Munina, ktorá bude vytvárať grafy navyše:

• Akýkoľvek web server podporujúci štandardne súborové služby a CGI alebo FastCGI (nepovinné, vysvetlenie neskôr). Apache, nginx alebo lighthttpd.
• RRD s podporou Perlu. T.z., že „perl -MRRDs -e ':;'“ musí zbehnúť bez chýb.

No a potom.... pre oboch je tu nespočetné množstvo potrebných Perl-modulov, ktoré sa líšia aj v závislosti na použitých pluginoch či celkovej konfigurácií. V tomto smere by bolo zbytočné popisovať každý z nich. Pred ručnou inštaláciou odporúčam nazrieť vždy do súboru INSTALL, ktorý obsahuje aktuálne požiadavky na moduly v danej verzií. Väčšinu už budete mať určite nainštalovanú. Tých pár, potrebných si kedykoľvek doinštalujete.

Inštalácia zo zdrojových kódov

• Stiahnite a rozbaľte balík s kódom.
• Editujte/skontrolujte súbor Makefile.config a upravte ho pre svoje potreby.
• Vytvorte v systéme užívateľa a skupinu „munin“. Tento užívateľ nemusí mať shell ani žiadne zvláštne privilégia. Vytvoríme ho len pre spúšťanie cron jobu.
• make
• make install

V prípade inštalácie len samotného nodu:

• Editujte/skontrolujte súbor Makefile.config a upravte ho pre svoje potreby.
• Vytvorte v systéme užívateľa a skupinu „munin“. Tento užívateľ nemusí mať shell ani žiadne zvláštne privilégia.
• make
• make install-common-prime install-node-prime install-plugins-prime

Inštalácia z balíkov (repozitárov)

Munin je k dispozícií aj v rôznych balíkoch pre rôzne linuxové distribúcie. Veľmi rozsiahlé how-to je možné nájsť na munin-monitoring.org. Nebudem tu rozpisovať niečo, čo je napísané už niekde inde. Keďže ja používam na svojich systémoch prevažne Debian, postup inštalácie naň je jednoduchý.

apt-get install munin  # pre Mastera
apt-get install munin-node   # Pre Noda

Overenie funkčnosti alebo „Prvé spustenie“

V tom prvom naj-základnejšom kroku si overíme, či celý systém správne funguje. Node sa vždy nainštaluje so základným súborom aktivovaných pluginov. Nie je potrebné v tomto smere nič dodatočné nastavovať. Navyše sa inštalačný skript pokúsi aktivovať sám pluginy podľa spustených služieb vo Vašom systéme. Spustenie nodu je možné overiť:

#/etc/init.d/munin-node status
Munin-Node is running (PID: 15075).

Tou šikovnejšou možnosťou je kontaktovať node prostredníctvom telnetu:

#telnet localhost 4949
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
# munin node at orion.tucniak.sk
version
munins node on orion.tucniak.sk version: 1.4.5
Connection closed by foreign host.

V prípade, že sa chceme dostať k zoznamu aktivovaných pluginov, použijeme v telnete príkaz „list“.

#list
apache_accesses apache_processes apache_volume cpu df df_inode entropy exim_mailstats forks fw_conntrack fw_forwarded_local fw_packets http_loadtime if_err_eth0 if_err_eth1 if_err_eth2 if_eth0 if_eth1 if_eth2 interrupts iostat iostat_ios irqstats load memory munin_stats open_files open_inodes postfix_mailqueue postfix_mailvolume proc_pri processes squid_cache squid_objectsize squid_requests squid_traffic swap threads uptime users vmstat

Hotovo. Node je plne funkčný.

Presunieme sa na mastra, ktorý sa stará o katalogizovanie a vykresľovanie grafov. Overíme si cestu, kam sa generujú html fajle: /etc/munin/munin.conf

 dbdir /var/lib/munin
 htmldir /var/cache/munin/www
 logdir /var/log/munin
 rundir  /var/run/munin

Následne overíme, či náš webový server dostal potrebnú konfiguráciu (v prípade Debianu a Apache2 je to) v súbore: /etc/apache2/conf.d/munin

Ak sa konfigurácia muninu v Apačovi neobjavila, pridáme potrebnú sekciu do jeho konfiguráka ručne:

Alias /munin /var/cache/munin/www
<Directory /var/cache/munin/www>
   Order allow,deny
   Allow from localhost 127.0.0.0/8 ::1 ALL
   Options None
 <IfModule mod_expires.c>
   ExpiresActive On
   ExpiresDefault M310
 </IfModule>
</Directory>

Reloadneme konfiguráciu:

/etc/init.d/apache2 reload

A nakoniec si overíme si, či sa Munin periodicky spúšťa prostredníctvom cronu. V Debiane je to default každých 5 minút: /etc/cron.d/munin

*/5 * * * *     munin if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi

Odskočíme si na cígu a celú makačku okolo inštalácie zavŕšime pohľadom na linku http://nas_server/munin v našom web browseri. Pre nefajčiarov odporúčam spustiť pred týmto krokom munin-cron ručne.

Na „nástenke“ vidíme prehľady grafov za jednotlivé služby (pluginy) a to denný a týždenný pohľad. Po kliknutí na ne sa pohľad rozšíri o mesačný a ročný. Taktiež je možné vygenerovať graf len za zvolené obdobie. O tom ale v závere článku. Čo sa týka konfigurácie v apache, môžme neskôr vymedziť dostupnosť do prehľadov len pre vymedzených hostov alebo jednoducho použiť mod_auth (bližšie info v dokumentácií k Apache).

Pluginy

Ako som povedal vyššie, Munin prichádza s množstvom pluginov, ktoré len čakajú na aktiváciu. Ako sa teda aktivujú? Jednoducho. Tak, že ich pridáte do adresára /etc/munin/plugins. Všetky Muninovské pluginy sa fyzicky default nachádzajú v /usr/share/munin/plugins/ (môže byť iné v závislosti na Vašom systéme a Vašej konfigurácií pri inštalácií). Vytvorením symbolickej linky na ne, v /etc/munin/plugins sa aktivujú.

Sú tu dva typy pluginov. Tie štandardné a tie so znakom podčiarkovníka v názve („_“) nazývane tiež ako wildcard plugins. Tento typ pluginov dokáže zastupovať rôzne zdroje. Ukážkou je plugin „if_“ (interfaces) za ktorý už len stačí zadať meno sieťového rozhrania, ktoré chceme podrobiť monitoringu. Použitie takéhoto pluginu pri monitoringu dvoch rôznych rozhraní (napr: eth0 a ppp0):

cd /etc/munin/plugins
ln –s /usr/share/munin/plugins/if_ if_eth0
ln –s /usr/share/munin/plugins/if_ if_ppp0
ls –la if*
lrwxrwxrwx 1 root root 28 Jun  9 07:04 if_eth0 -> /usr/share/munin/plugins/if_
lrwxrwxrwx 1 root root 28 Jun  9 07:04 if_ppp0 -> /usr/share/munin/plugins/if_

Ešte jeden príklad s wildcard pluginom. Dajme tomu, že chceme monitorovať latency svojho internetového pripojenia. K dispozícií máme jednoduchý „ping_“. Takže vytvoríme napríklad ping na www.google.com (alebo na nejaký stroj svojho ISP) nasledovne:

cd /etc/munin/plugins
ln –s /usr/share/munin/plugins/ping_ ping_www.google.com
/etc/init.d/munin-node restart

Hotovo. Po tejto akcií, by nám mal automaticky pribudnúť nový, ďalší graf s údajom o priemernej odozve (pingu) na daného hosta. Dokážete si predstaviť jednoduchšie konfigurovanie?

Konfigurácia pluginov (/etc/munin/plugin-conf.d)

Zas aby nebolo všetko len také rúžové, sú tu isté veci, ktoré pluginy nedokážu. Napríklad nedokážu nájsť potrebný konfiguračný súbor ak sa nenachádza na „očakávanom mieste“. Napríklad, aby mohol plugin k dhcp poolu fungovať správne, musí poznať zoznam Vašich poolov (potrebuje nahliadnuť do /etc/dhcp/dhcpd.conf) a poznať aktuálne leases (/var/lib/dhcp/dhcpd.leases). V prípade, že sa tieto súbory nenachádzajú na obvyklých miestach – je plugin nefunkčný. Treba mu upraviť cesty k týmto súborom.

Taktiež som hovoril o možnosti nastaviť limity pre rôzne hodnoty v grafoch, kedy nás munin upozorní na prekročenie týchto hodnôt. Ako graficky, tak aj mailom napríklad. Pre tieto účely teda slúžia súbory v /etc/munin/plugin-conf.d kde môže byť konfigurácia v každom súbore za každý plugin zvlášť alebo v jednom za všetky.

Príklad úpravy pluginu pre vyššie zmienený dhcpd-pool:

[dhcpd-munin_]     # Názov pluginu
env.configfile /etc/dhcp/dhcpd.conf   # Určenie cesty k dhcpd.conf
env.leasefile /var/lib/dhcp/dhcpd.leases  # Určenie cesty k leases.
env.warning 85    # Nastavenie hranice pre upozornenia (plugin udava hodnoty v %)
env.critical 95   # nastavenie hranice pre critical

Náš vlastný plugin a testovanie (nie len jeho) funkčnosti

Ako som už povedal. Krásne na tomto frameworku je, že je úplne jedno v akom jazyku svoj vlastný monitoring naprogramujete/naskriptujete. Dôležité je len dodržať správnu syntax výstupu hodnôt. Začnem, opačne a ukážeme si ako sa dá otestovať funkčnosť pluginov aby sme videli ako vyzerá výstup funkčného (originálneho) počinu. Napríklad aj vyššie zmieneného ping_www.google.com. Postačí nám príkaz munin-run a názov pluginu.

#munin-run ping_www.google.com
packetloss.value 0
ping.value 0.027011

Vidíme, aké jednoduché to celé je. Lenže ako môže Munin vedieť, aký typ grafu chcem z uvedených hodnôt vygenerovať? Ako ho chcem pomenovať? Akej farby chcem dať krivky? Aké budú maximálne/minimálne hodnoty? Či chcem graf škálovať, alebo nie. Všetky tieto údaje si musí každý jeden plugin niesť so sebou. Ako sa predávajú tieto informácie Muninu? Opäť len vhodným výstupom. Stačí za plugin uviesť parameter „config“ a ten musí poskytnúť tento druh informácie.

#munin-run ping_www.google.com config
graph_title IPv4 ping times to www.google.com
graph_args --base 1000 -l 0
graph_vlabel roundtrip time (seconds)
graph_category network
graph_info This graph shows ping RTT statistics.
ping.label www.google.com
ping.info Ping RTT statistics for www.google.com.
packetloss.label packet loss
packetloss.graph no

Vo výpise okrem rôznych pomenovaní jednotlivých mriežok vidíme aj argumenty, ktoré sa predávajú pre RRD a ktorým môžeme graf túningovať na rôzne detaily. Na aké a ako by bolo mimo hranice tohto článku. Bližšie v dokumentácií k Muninu alebo RRDToolsu. Podobné výstupy musia poskytovať všetky pluginy Muninu na požiadanie a bez rozdielu. Budeme sa tým teda riadiť aj pri tvorbe nášho vlastného.

Vytvoríme si plugin na monitorovanie teploty ovzdušia v mojom meste len pomocou obyčajného shell skriptu. Hodnoty budeme wgetovať zo stránky www.accuweather.com. Ja viem, trošku neefektívne ale na demonštráciu nám to bude bohato stačiť. To čo musíme, je nájsť tú správnu URL odkazujúcu sa na monitorované mesto. Keďže ja som zo Žiliny (SK), tou mojou bude stránka:

http://www.accuweather.com/en/sk/zilina/301459/weather-forecast/301459

URL svojho mesta si nebudete mať určite problém nájsť sami. Teraz je už cesta jednoduchá. Stránku wgetneme a awkneme reťazec ktorý potrebujeme.

#!/bin/sh
URL=“http://www.accuweather.com/en/sk/zilina/301459/weather-forecast/301459“
wget -q -O- "$URL" | awk -F\' '/acm_RecentLocationsCarousel\.push/{print $2": "$16", "$12"°" }'| head -1

Po spustení skriptu na nás čaká výstup ako je tento:

Zilina, Slovakia: Mostly sunny, 29°

Teraz sa pokusíme dostať výstup požadovaný Muninom. Shell guruom sa dopredu ospravedlňujem. Nič lepšie ma nenapadlo.

#!/bin/sh
URL=“http://www.accuweather.com/en/sk/zilina/301459/weather-forecast/301459“
wget -q -O- "$URL" | awk -F\' '/acm_RecentLocationsCarousel\.push/{print $2": "$16", "$12"" }'| head -1 | tr -d ',' | awk '{print $1".value "$5}'

Skript som si uložil pod názov „weather“. Skúsime ho spustiť.

#chmod +x weather
#./weather
Zilina.value 30

Prvá, ťažšia časť je úspešne za nami. Tou poslednou bude pridať skriptu potrebný výpis na „config“ parameter. Rozšírime teda skript nasledovne:

#!/bin/sh
case $1 in
   config)
        cat <<'EOM'
graph_title Teplota v meste
graph_vlabel Celsius
Zilina.label Zilina
graph_category Forecast
EOM
        exit 0;;
esac
URL=“http://www.accuweather.com/en/sk/zilina/301459/weather-forecast/301459“
wget -q -O- "$URL" | awk -F\' '/acm_RecentLocationsCarousel\.push/{print $2": "$16", "$12"" }'| head -1 | tr -d ',' | awk '{print $1".value "$5}'
Keď teraz skript spustíme s „config“ parametrom, dostaneme:

#./weather config
graph_title Teplota v meste
graph_vlabel Celsius
Zilina.label Zilina
graph_category Forecast

Toto sú minimálne parametre potrebné pre vytvorenie grafu, bez ktorých to jednoducho nepôjde. Teraz celý náš skript premiestnime pod /etc/munin/plugins, reštartneme node a skúsime, či všetko funguje ako má.

#munin-run weather
Zilina.value 26

Alebo:

# telnet localhost 4949
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
# munin node at altar.doaza.edu.sk
fetch weather
Zilina.value 26

Počkáme na periodické spustenie Munina a na našej nástenke si všimneme graf v novej kategórií „Forecast“.

Pre ďalšie, obšírnejšie informácie o písaní pluginov odporúčam navštíviť munin-monitoring.org.

Vzdialené monitorovanie

Už vieme, že na monitorovanie serverov vzdialene stačí na každom z nich nainštalovaný munin-node a príslušná sada pluginov. Okrem uvedeného je potrebné na klientskom stroji povoliť pristup servera na noda zo siete. Firewallovú časť riešiť nebudem. Na nej potrebujete povoliť prístup na tcp 4949. Na node je nutné uviesť IP adresu servera (munina) ktorý bude mať prístup na tohto noda. Dajme tomu, že náš munin-server (na ktorom sa budú zbierať grafy) má IP adresu 158.193.219.1. Navštívime /etc/munin/munin-node.conf a pridáme potrebný riadok:

# A list of addresses that are allowed to connect.  This must be a
# regular expression, since Net::Server does not understand CIDR-style
# network notation unless the perl module Net::CIDR is installed.  You
# may repeat the allow line as many times as you'd like
allow ^127\.0\.0\.1$
allow ^158\.193\.219\.1$

Reštartujeme noda a skúsime sa naň zo servera telnetnúť. Ak bude spojenie nadviazané – chýba už len posledná vec. Zeditujeme na serveri /etc/munin/munin.conf a pridáme sekciu s popisom nášho klienta.

[nejaky.host.sk]           # Nazov pod ktorym budeme hosta evidovat
   address ip.addresa.munin.nodu

Potom už len stačí počkať na periodické spustenie munina. Nová konfigurácia sa automaticky premietne a na našej nástenke sa zobrazia grafy ďalšieho hosta.

Na čo netreba zabúdať je fakt, že to Munin (master/server) katalogizuje nazbierané údaje. Preto sa nie je možné dostať k dátam pred pridaním vzdialeného hosta do konfiguráku.

Toto je základná konfigurácia. Munin umožňuje vytvoriť aj SSL spojenie na svojich klientov ako aj využívať SSH tunel pre komunikáciu s nimi pre prípad, že sú dakde za NATom. Pre bližšie informácie budete musieť navštíviť domovskú stránku projektu.

Zasielanie mailov

Nakonfigurovanie Munina na zasielanie mailov pri každej dosiahnutej „hranici“ je podobne jednoduchá záležitosť. Vybral som si práve tento úkon, nakoľko je najvyhľadavánejší a veľmi jednoduchý. Počítam však s plne funkčným mailovým systémom, na ktorom Munin beží. Najprv musíme do munin.conf pridať direktívy, ktorými definujeme príjemcu správ. Je možné definovať viacerých pri rozných udalostiach.

contacts me
contact.me.command mail -s "Munin notifikacia ${var:host}" remenec@gmail.com
contact.me.always_send warning critical

Ešte si upravím hodnoty notifikačných hraníc pre niektoré pluginy. Zapísaním direktívy priamo do munin.conf prepisujeme hraničné hodnoty ktoré predával plugin prostredníctvom „config“ alebo konfigurácie uvedenej v /etc/munin/plugin-d.conf. Niektoré pluginy nemajú tieto hodnoty vôbec nastavené.

[nejaky.mojhost.sk]           
   address ip.addresa.munin.nodu
   df._dev_sda1.warning 97
   hddtemp_smartctl.hde.critical 41

Zamyslenie na záver

Na záver by som sa chcel ľahko obtreť o spôsob akým munin generuje grafy a html. Pokiaľ ste inštalovali Munina podľa tohto návodu – grafy (obrázky png alebo jpg) spolu s doprovodnými html súbormi sú stále na novo generované do priečinka uvedeného v /etc/munin/munin.conf. A to konkrétne vo voľbe htmldir (štandardne /var/cache/munin/www). Deje sa to zakaždým keď dôjde k spusteniu munina cez cron-job. Iste si uvedomujete, že v tomto spôsobe sa nedá hovoriť o efektívnom využívaní zdrojov. Hoci samotné generovanie grafov nepotrebuje veľký výpočtový výkon (je minimálny), predsa len je na tento úkon spotrebovaný nemalý procesorový čas (u mňa pri zapnutom monitoringu 7 serverov a staníc je to cca ~35 sekúnd). Mne osobne tento fakt neprekáža. Munin u mňa beží na serveri, ktorý ponuka hlavne sieťové služby, pri ktorých je dopad na procesor minimálny. Takto ho aspoň nejako „zamestnávam“. Na druhej strane to niekomu však môže vadiť. Na čo vyhradzovať prostriedky na niečo, čo zrovna nepotrebuje.

Pre tento prípad je Munin schopný fungovať a generovať grafy na požiadanie prostredníctvom CGI alebo FastCGI. V tomto prípade sa Munin spúšťa len kvôli katalogizovaniu výsledkov, čo je v horšom prípade pár sekúnd práce. Grafy a HTML sa potom generuje dynamicky na žiadosť užívateľa. Pri generovaní prostredníctvom *CGI je v Munine dostupná aj funkcionalita výberu konkrétneho časového úseku a vygenerovania grafu z tohto úseku. Táto funkcionalita pri statickom generovaní nefunguje (logicky ani nemôže).

V prípade, že ste rozhodnutí používať CGI, dobré howto je k dispozícii na munin-monitoring.org.

Týmto ukončím rýchle predstavenie tohto podľa mňa dobrého nástroja.

Na záver sa chcem ešte ospravedlniť za prípadné gramatické a pravopisné chyby ktoré ste našli a unikli mojej pozornosti. Stále sa snažím zlepšovať.

       

Komentáře

[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.

[Ruža Becelin]

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.