abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

včera 23:44 | IT novinky

Společnosti Dell a Canonical společně představily 5 nových počítačů Dell Precision s předinstalovaným Ubuntu. Jedná se o 4 notebooky a 1 all-in-one počítač. Cena počítačů s Ubuntu je o 100 dolarů nižší než jejich cena s Windows 10.

Ladislav Hagara | Komentářů: 6
včera 22:55 | Nová verze

Po pěti měsících vývoje od vydání verze 4.8 byla vydána nová verze 4.9 svobodného open source redakčního systému WordPress. Kódové označením Tipton bylo vybráno na počest amerického jazzového muzikanta a kapelníka Billyho Tiptona.

Ladislav Hagara | Komentářů: 0
včera 22:11 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 146. brněnský sraz, který proběhne v pátek 17. listopadu od 18:00 hodin v restauraci Bogota na Nových Sadech.

Ladislav Hagara | Komentářů: 0
včera 21:55 | Nová verze

Dle plánu byla vydána nová verze 9.2.1 živé linuxové distribuce Slax. Novinkou je především přechod ze Slackware na Debian a z KDE na Fluxbox.

Ladislav Hagara | Komentářů: 2
15.11. 22:44 | Zajímavý projekt

Vítězným projektem letošního ročníku soutěže určené vývojářům open source hardwaru Hackaday Prize se stal podvodní kluzák (YouTube, Onshape). Cenu za nejlepší produkt získala braillská klávesnice pro chytré telefony Tipo (YouTube).

Ladislav Hagara | Komentářů: 0
15.11. 06:33 | Nová verze

Byla vydána verze 3.3 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Řešena je také řada bezpečnostních problémů.

Ladislav Hagara | Komentářů: 3
15.11. 00:11 | Nová verze

Byla vydána beta verze Linux Mintu 18.3 s kódovým jménem Sylvia. Na blogu Linux Mintu jsou hned dvě oznámení. První o vydání Linux Mintu s prostředím MATE a druhé o vydání Linux Mintu s prostředím Cinnamon. Stejným způsobem jsou rozděleny také poznámky k vydání (MATE, Cinnamon) a přehled novinek s náhledy (MATE, Cinnamon). Linux Mint 18.3 bude podporován až do roku 2021.

Ladislav Hagara | Komentářů: 0
14.11. 21:44 | Nová verze

Byla vydána verze 5.2.0 svobodného integrovaného vývojového prostředí KDevelop. Přímo z menu KDevelopu lze nově analyzovat aplikace napsané v C/C++ pomocí nástroje Heaptrack. Vylepšena byla podpora programovacích jazyků C++, PHP a Python. Ke stažení a k vyzkoušení je binární balíček s KDevelopem 5.2.0 ve formátu AppImage.

Ladislav Hagara | Komentářů: 8
14.11. 17:33 | Nová verze

MojeFedora.cz informuje, že bylo oficiálně oznámeno vydání Fedory 27. Ve finální verzi vycházejí dvě edice: Workstation pro desktopové a Atomic pro cloudové nasazení. Fedora Server vzhledem k náročnosti přechodu na modularitu vychází pouze v betaverzi a finální verze je naplánována na leden. Vedle nich jsou k dispozici také alternativní desktopy v podobě KDE Plasma, Xfce a další a k tomu laby – upravené vydání Fedory například pro designery, robotiku, vědecké použití atd. Stahovat lze z Get Fedora.

Ladislav Hagara | Komentářů: 20
14.11. 17:22 | Pozvánky

Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Zajímá tě DIY, CNC, SDR nebo morseovka? Přijď na sraz spolku OpenAlt – tradičně první čtvrtek před třetím pátkem v měsíci: 16. listopadu od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).

xkucf03 | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (9%)
 (1%)
 (1%)
 (1%)
 (73%)
 (14%)
Celkem 676 hlasů
 Komentářů: 36, poslední dnes 18:43
    Rozcestník

    MUNIN, sieťový monitorovací framework

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

    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

    link

    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

    link

    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)

    Munin Munin

    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.

    Munin

    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

    Alternatívy? Je ich celý kopec.

    link

    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

    link

    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

    link
    • 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)

    link

    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“

    link

    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.

    Munin

    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

    link

    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)

    link

    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

    link

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

    Munin

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

    Vzdialené monitorovanie

    link

    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

    link

    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

    link

    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ť. :-)

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    12.6.2014 00:23 MAx
    Rozbalit Rozbalit vše Re: MUNIN, sieťový monitorovací framework
    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.
    12.6.2014 01:31 Ivan
    Rozbalit Rozbalit vše Re: MUNIN, sieťový monitorovací framework
    Skus https://github.com/munin-monitoring/contrib/blob/master/tools/munin2json/cgi-bin/munin-cgi-datafile
    12.6.2014 21:21 MAx
    Rozbalit Rozbalit vše Re: MUNIN, sieťový monitorovací framework
    Díky.
    12.6.2014 00:29 Jan Kundrát (jkt) | skóre: 27 | blog: jkt | Praha - Bohnice
    Rozbalit Rozbalit vše Re: MUNIN, sieťový monitorovací framework
    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 avatar 12.6.2014 08:26 Juraj Remenec | skóre: 30
    Rozbalit Rozbalit vše Re: MUNIN, sieťový monitorovací framework
    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.
    12.6.2014 19:35 Jan Kundrát (jkt) | skóre: 27 | blog: jkt | Praha - Bohnice
    Rozbalit Rozbalit vše Re: MUNIN, sieťový monitorovací framework

    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 22:44 ebik | skóre: 2
    Rozbalit Rozbalit vše Re: MUNIN, sieťový monitorovací framework
    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.
    12.6.2014 22:46 ebik | skóre: 2
    Rozbalit Rozbalit vše Re: MUNIN, sieťový monitorovací framework
    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.
    13.6.2014 08:20 Jiří Lisický | skóre: 31 | blog: JIL_blog | Olomouc
    Rozbalit Rozbalit vše Re: MUNIN, sieťový monitorovací framework
    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?
    14.6.2014 14:07 ebik | skóre: 2
    Rozbalit Rozbalit vše Re: MUNIN, sieťový monitorovací framework
    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.
    12.6.2014 23:05 Pista
    Rozbalit Rozbalit vše Re: MUNIN, sieťový monitorovací framework
    Nepremyslali ste miesto statiky pouzit fastcgi?
    12.6.2014 09:33 karel
    Rozbalit Rozbalit vše Re: MUNIN, sieťový monitorovací framework
    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 avatar 12.6.2014 09:58 Juraj Remenec | skóre: 30
    Rozbalit Rozbalit vše Re: MUNIN, sieťový monitorovací framework
    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.
    16.6.2014 09:03 Yenya
    Rozbalit Rozbalit vše Monitorování technologií?
    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
    16.6.2014 16:14 ebik | skóre: 2
    Rozbalit Rozbalit vše Re: Monitorování technologií?
    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.
    16.6.2014 22:46 Zdenek 'Mst. Spider' Sedlak | skóre: 37 | blog: xMstSpider
    Rozbalit Rozbalit vše Re: Monitorování technologií?
    My pouzivame kombinaci Nagios+Cacti, na kazdem stroji pak Monit. Munin mame jako zalohu.
    17.6.2014 15:14 Chulda | skóre: 19
    Rozbalit Rozbalit vše Re: Monitorování technologií?
    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 avatar 17.6.2014 22:37 Jezekus | skóre: 18 | blog: jezkova_nora
    Rozbalit Rozbalit vše Re: Monitorování technologií?

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

    19.6.2014 08:39 Program
    Rozbalit Rozbalit vše Re: Monitorování technologií?
    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í.
    19.6.2014 17:24 Chulda | skóre: 19
    Rozbalit Rozbalit vše Re: Monitorování technologií?
    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í! :-)
    20.6.2014 07:47 Program
    Rozbalit Rozbalit vše Re: Monitorování technologií?
    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 avatar 21.6.2014 08:29 lolofon | skóre: 3
    Rozbalit Rozbalit vše Re: Monitorování technologií?

    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.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.