Vlákno názorů k článku Nový Zabbix 3.0: vylepšené rozhraní a podpora šifrování od sneho - a migrovali by ste z nagiosu ?

  • Článek je starý, nové názory již nelze přidávat.
  • 15. 2. 2016 20:45

    jan (neregistrovaný)

    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.

  • 16. 2. 2016 8:07

    Spider (neregistrovaný)

    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.

  • 16. 2. 2016 17:02

    Cohen (neregistrovaný)

    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!

  • 16. 2. 2016 20:37

    Spider (neregistrovaný)

    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 ;-)

  • 16. 2. 2016 21:34

    Jan (neregistrovaný)

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

  • 17. 2. 2016 7:46

    Spider (neregistrovaný)

    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.

  • 18. 2. 2016 8:40

    Pavel Štros (neregistrovaný)

    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.

  • 18. 2. 2016 23:13

    ebik (neregistrovaný)

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

  • 19. 2. 2016 10:18

    Pavel Štros (neregistrovaný)

    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.

  • 20. 2. 2016 20:16

    ebik (neregistrovaný)

    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.