Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).
ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.
LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).
Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
Společnost Volla Systeme stojící za telefony Volla spustila na Kickstarteru kampaň na podporu tabletu Volla Tablet s Volla OS nebo Ubuntu Touch.
Společnost Boston Dynamics oznámila, že humanoidní hydraulický robot HD Atlas šel do důchodu (YouTube). Nastupuje nová vylepšená elektrická varianta (YouTube).
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.
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í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ší 
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“.
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ť:
Pre master časť Munina, ktorá bude vytvárať grafy navyše:
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.
V prípade inštalácie len samotného nodu:
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
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).
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?
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
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.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
#!/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.
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.
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
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ť.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
12.6.2014 08:26
Juraj Remenec | skóre: 30
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.
12.6.2014 09:58
Juraj Remenec | skóre: 30
16.6.2014 22:46
Ruža Becelin | skóre: 40
| blog: RuzaBecelinBlog
17.6.2014 22:37
Jezekus | skóre: 19
| blog: jezkova_nora
To je zajimave info, ja jsem prave chtel zkusit nasadit zabbix misto nagios+munin 
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.
21.6.2014 08:29