Názory k článku Nový Zabbix 3.0: vylepšené rozhraní a podpora šifrování

Jak jsou na tom grafy? Co me na 2.x zabbixu neskutecne iritovalo, bylo, ze bylo nutno vytvaret grafy (resp. templaty) rucne pro vse. Umi to tedy konecne automaticky generovat bezne grafy na zaklade hodnot podobne jako Cacti, Centreon atd?

Nevím, co je myšleno "běžným" grafem, ale implicitní grafy pro všechny sbírané číselné metriky jsou v ZABBIXu minimálně od verze 1.6 z roku cca 2006, což je ta nejstarší, co pamatuji. Komplexnější a barevnější graf kombinující více veličin si už tenkrát mohl uživatel nadefinovat snadno (tj. na pár kliků přímo z webového rozhraní), nově od verze 2.0 to jde i pomocí "low level discovery", např. pro všechna rozkrytá síťová rozhraní na routeru.

Trochu nepresne jsem se vyjadril. Kdyz vezmu napr. Centreon a zobrazim si sekci grafy, mam tam vsechny grafy pres stromove menu k dispozici, muzu si napr. zobrazit libovolny at uz z jenoho hostu, nebo vice. Kdykoli jsem zkousel Zabbix, tak tuhle funkcionalitu jsem tam nenasel, vzdy jsem se musel ten graf nejakym zpusobem teprve definovat vyberem z kontextoveho menu, aby se vubec zobrazil. A to jeste pokud si dobre pamatuji, ani zobrazoval automaticky 1d/1w/...

Tak dneska jeste stihli vydat RC3... Jinak na 3.0 se tesim, hlavne kvuli podpore SSL a autentizace. Co nikdy moc nechapu je to matlani se s milionem jazykovych verzi pro ruzny obskurni jazyky u aplikaci urcenych pro adminy. Co asi tak admin oadminuje bez znalosti anglictiny?

jazykove mutace delaji casto fanousci daneho sw pro ktere je to nativni jazyk, a casto je to jejich podekovani tvurci sw a zaroven mozne priblizeni tohoto sw svejm neanglicky mluvicim krajanum...
ale asi bys radeji aby si vsichni koupili letenky do CR a sli ti doma uklidit, nalestit boty, namasirovat a umejt zada ze ?

Za sebe doporučuji při hledání sw na monitoring vyzkoušet také NetXMS (http://www.netxms.org/).

To vypada dobre, umi to i manualni "user friendly" spousteni preddefinovanych skriptu na agentovi? To je zatim asi nejvetsi vyhoda Zabbixu, na kterou jsem pri mym hledani zatim narazil.

http://nahraj.to/1m2G

Jinak pro nějaký přehled o možnostech:
NetXMS Tutorials
https://www.youtube.com/playlist?list=PLt3aE2eGS5P9L72H82S83MrKx2uz5x8gv
NetXMS Advanced Tutorials
https://www.youtube.com/playlist?list=PLt3aE2eGS5P_WE9238mg9tMNMxoed1bRt

Pecka, diky moc. Vypada to skvele, i moznost jednoduse dostat logy z agenta je super. Vyzkousim.

Seriozna otazka; mozem si tam spustit rm -rf / ? Co takyto prikaz zmaze? T.j. ake opravnenia ma agent?

Jo, jen je trochu problem tom, ze prevazne skoncis bud na tom, ze vybrana vec neumi co potrebujes, nebo je to prozmenu neuveritelnej moloch co potrebuje desitky GB prostoru, hromady ramky a CPU.

a migrovali by ste z nagiosu ?

Zalezi od poziadaviek a znalosti. Niektorym osobam staci NRPE check raz za 5 minut a su spokojni. Ini zase potrebuju 5k metrik skontrolovat kazdych 10 sekund. Z mojho pohladu je Nagios nastroj z 18.storocia a je to list pozliepanych bash/perl/python skriptov :-P
Odhadom Nagios dokaze dat 200 new values per second (nvps), zatial co Zabbix agent pri optimalnom checku (custom C module, vsetko in memory - no iops) a konfiguracii zvlada 5k-8k nvps.

Jo, tohle platilo tak u verze 1.x

Doporucuji se podivat na verzi 4.x a vygooglovat jak se Nagios pouziva na velkych instalacich.

Priste do toho netahat nabozenstvi, ty nastroje jsou srovnatelne rychle.

Nezlobte se, ale spíš to vypadá, že píchl do Vašeho náboženství. Nagios funguje pořád v podstatě stejně. Jeho filosofii asi nejlépe vystihuje toto:

Timing Interval Length

Format: interval_length=<se­conds>
Example: interval_length=60

This is the number of seconds per "unit interval" used for timing in the scheduling queue, re-notifications, etc. "Units intervals" are used in the object configuration file to determine how often to run a service check, how often to re-notify a contact, etc.

Important: The default value for this is set to 60, which means that a "unit value" of 1 in the object configuration file will mean 60 seconds (1 minute). I have not really tested other values for this variable, so proceed at your own risk if you decide to do so!

Ne, to fakt ne :-) Ja rozhodne nepreferuji nejake reseni na zaklade nabozenstvi, delam s monitoringem dost dlouho a nemam problem s Nagiosem, Icingou, Zabbixem a dalsimi. Teda korme SCOMu, to je übershit :-D

Aktivni checky jsou jen jedna cast Nagiosu, podivejte se do dokumentace a doporucuji mrknout na par videi z LISA, jak to delaji pro treba 20000 zarizeni.

Nagios checky davno nejsou bash/perl/python - to byla domena v 1.x, ted je majorita v C a vlastne neni problem je napsat v cemkoli.

Nic ve zlem, ale reagoval jsem pouze na hodnoceni Nagiosu od cloveka, ktery jej videl tak pred deseti lety. Nagios se musi pochopit, pak se s nim daji delat divy ;-)

> ty nastroje jsou srovnatelne rychle
Podla Githubu je 84% Nagios Core Cecko, takze by to mohlo byt porovnatelne. Chcel by som si to otestovat. Rad by som vzdialene cital zakladnu metriku cpu load z daneho servera. Ako na to v Nagiose? https://exchange.nagios.org/directory/Plugins/System-Metrics/CPU-Usage-and-Load ponuka same bash/perl/python skripty kde uz dopredu viem ze to nie je nic na rychlost. Stiahol som si aj posledny oficialny ova - nagios user ma 20 procesov avsak 10 z nich su PHP :(. Stale to moze byt rychle, len si to potrebujem otestovat. Uvitam aj pripadne vhodne zdroje/porovnanie. Potom aj pripadne zvazim, ci zmenim moje monitoring nabozenstvo :-)

CPU check (check_load) je v zakladu:

file /usr/lib64/na­gios/plugins/chec­k_load
/usr/lib64/na­gios/plugins/chec­k_load: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped

Frontend Nagios Core za moc nestoji, to je prvni, co clovek nahradi, doporucuju Thruk a check_mk. Dobra vec je taky OMD, coz je zapakovany Nagios s Thruk, check_mk a dalsim, popr. Centreon nebo komercni Op5.

Já vnímám největší rozdíl mezi ZABBIX a NAGIOS ve třech věcech:

1. Schopnost snadno definovat komplexní podmínky alarmů nad sbíranými metrikami, např. "aktivuj alarm závažnosti Warning, pokud minimální hodnota zatížení CPU za posledních 20 minut je 50%". Analogické komplexnější podmínky potřebujeme vytvářet naprosto běžně, často i v kombinaci s podmínkou definovanou nad jinou sbíranou metrikou. Jak se toto řeší v NAGIOSu?

2. Pohodlnost správy konfiguračních položek monitoringu v ZABBIXu, který to od svého vzniku řeší kompletně ve webovém rozhraní. V NAGIOSu se to dlouho dělalo jen editací textových konfiguráků a ani těm dnes dostupným nadstavbám jsem v tomto ohledu nepřišel na chuť. Zejména v rozsáhlých prostředích člověk ocení pohodlnost úprav monitorovacích šablon a funkce hromadné editace konfiguračních položek v ZABBIX.

3. Nativní multiplatformní agent ZABBIXu, poskytovaný přímo výrobcem, který explicitně podporuje sběr mnoha běžných metrik plus samozřejmě sběr "custom" metrik definovaných správcem. Ano, NCPA a NRPE pluginy NAGIOSu znám, ale je tu rozdílek ;-)

Na NAGIOSu se mi líbí impicitní podpora pro "závislost mezi hosty", což v ZABBIX ošetřujeme složitěji až na úrovni závislostí mezi monitorovanými službami. Libí se mi i vlastnosti grafické nadstavby Thruk, včetně některých jejích grafických prvků. Chápu, že znalec NAGIOSu může chtít u něj zůstat. Pro ostatní bych doporučil spíše ZABBIX. Určitá "krabicovost" ZABBIXu je zejména pro začátečníky velkou výhodou a naštěstí není ani pro pokročilý monitoring překážkou.

A lze jit i v zabbixu cestou textovych konfiguraku misto nejakeho klikani? (Bez psani nejakeho pluginu...). Nektere veci chce clovek spravovat automaticky z jinych nastroju, ve kterych ma popsanou celou infrastrukturu (napriklad ansible).

Nejde. Veškerou konfiguraci (vyjma startup parametrů procesů a custom monitorovacích skriptů) si Zabbix drží v relační databázi. Pro interakci s jinými nástroji Zabbix poskytuje API, které aktivně využíváme a používáme Zabbix například jako konfigurační databázi pro integrovanou centrální správu konfigurace agentů našeho log management řešení ELISA.

Provádět integraci nástrojů na úrovni jejich konfiguraků nepovažuji zrovna za šťastné řešení z hlediska dlouhodobé udržitelnosti provozu.

S orchestracnimi nastroji jako je ansible je to naopak ta nejjednodussi a nejudrzitelnejsi cesta. Tyto nastroje totiz udrzuji konzistenci konfigurace napric stroji a nastroji v konzistentnim stavu. Pro snadnou integraci s temito nastroji je potreba aby se nastroj snadno nastavil do predepsaneho stavu idealne bez ohledu na stav ve kterem se nachazi. Coz je napriklad prepsani konfigurace a jeji nasledny reload.

Zabix je staromodni monoliticky system velmi podobny Nagiosu a jeho odnozim jako napriklad Cacti. Na svete neexistuje jediny monitorovaci system, ktery by dokazal monitorivat vsechno. Proto se vetsina lidi uchyluje k tvorbe kompozitniho monitorovaciho systemu, ktery je slozeny z vice komponent, ktere spolu nazajen spolupracuji a kazda z nich lze nahrati jinou, pokud prestane vyhovovat. Ja si podobny system sestavil z Collectd (kolekce metrik a vyhodnocovani thresholdu), InfluxDB (timeseries databaze), Sensu + Uchiwa (alerting dashboard) and Grafana (graphing dashboard). Vrele doporucuji vyzkouset.

> Na svete neexistuje jediny monitorovaci system, ktery by dokazal monitorivat vsechno.
S tym by som suhlasil.
> Proto se vetsina lidi uchyluje k tvorbe kompozitniho monitorovaciho systemu, ktery je slozeny z vice komponent
Vo velkych korporacia sa tlaci myslienka "unifikovaneho" monitoringu,tam takymto sposobom nie su moc nakloneny - ibaze sa to zabali do buzwordu microservices ;-)

Z vasho stacku by som vyhodil InfluxDB - su dobri, ale este skaloval nevedia dostatocnev - pri vyssich poziadavkach na nvps bude problem (CERN publikoval nejake porovnania kde InfluxDB jednoznacne pohorel v tomto smere - na SME monitoring je vsak OK). Mozno v buducnosti. Takze asi klasika OpenTSDB (HBase). Alebo by stalo za skusenie "sialena", avsak realna myslienka - pouzit ako storage Elasticsearch a potom Kibanu (davny predok Grafany) na grafy,

Porovnani co provadeli v CERNu je uz skoro rok stare. Od te doby se InfluxDB hodne zlepsil. Posledni verze by mela umet ukladat data s frekvenci 350 tisic zaznamu za sekundu (https://influxdata.com/blog/announcing-influxdb-v0-10-100000s-writes-per-second-better-compression/).

Presne tak, CERN sice nepise aku verziu skusali, no podla casu kedy to robili to bolo asi 0.8. Performance ako features boli v tom case uplne inde ako su teraz. S novym TSM storage engine je to velmi rychle a data zaberaju malo miesta, kedze sa pouziva kompresia (udajne priemer je cca 3 byte / hodnota ).

Vybudování a dlouhodobá údržba takovéhoto "vlastního" monitorovacího systému jsou činnosti extrémně náročné na lidské zdroje. To je práce pro tým velmi kvalifikovaných lidí, který nedělá prakticky nic jiného. S tím by nás naprostá většina zákazníků kvůli vysokým nákladům vyhodila - naopak zdařile fungujeme jako komerční poskytovatel služeb k monitorovacímu systému ZABBIX, příležitostně i k NAGIOS.

Zenoss Core 5 je nej system na monitorovani. Kazdy demon bezi ve vlastnim dockeru, tim padem se necha verzovat kazda zmena. Super stable stack. ;-)