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.
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=<seconds>
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/nagios/plugins/check_load
/usr/lib64/nagios/plugins/check_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.
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.