Fórum Root.cz

Hlavní témata => Software => Téma založeno: Stepan Cirkl 06. 01. 2021, 14:48:52

Název: Dohledový systém
Přispěvatel: Stepan Cirkl 06. 01. 2021, 14:48:52
Dobrý den,

chystám se na nový monitorovací server. Dohled teď nějakou dobu neprovozuju, z dřívějších dob (cca -8 let) mám zkušenost s Nagios na monitoring dostupností v kombinaci s CACTI na grafování trendů. Vzhledem k mé delší absenci v této oblasti bych rád prodiskutoval aktuální stav systémů a možností, než se vrhnu do budování systému dle původní architektury. Přece jen už je to pár let a vývoj jde dopředu a nemusím procházet všechny slepé uličky. :-)

Požadavky:
1. Provoz na Linuxu, ideálně volná licence. Určitě ne licencování založené na počtu monitorovaných systémů.
2. Chtěl bych monitorovat dostupnost hostů, služeb, definici závislostí prvků na sobě. Testy spouštěné z monitorovacího serveru vůči monitorovaným cílům, případně SNMP, agent na monitorovaném systému.
3. Monitoring trendů, tedy grafování. Zde předpokládám SNMP, agent.
4. Pokud bych uměl sbírat na jedno místo logy, nějaké vyhodnocování, alerty, nástroje pro prohledávání, bylo by to fajn, ale není nutné.
5. Víceuživatelský přístup, role s oprávněními jak z hlediska možnosti prohlížení / konfigurace tak přístupu ke skupinám prostředků. Přiřazování monitorovaných hostů do skupin ručně, ne dle typu. Konfigurace stačí povolená pro lidi s globálním přístupem, osoby s přístupem k omezenému počtu monitorovaných systémů stačí jen čtení.
6. Reporting výpadků, mail, případně SMS. Možnost konfigurace komu reportovat dle skupin, případně časů. Potlačení opakovaného reportu po nějakou dobu.
7. Ideálně webové rozhraní. Další může být jako bonus.
8. Monitorované systémy budou routery, switche, servery, služby na serverech. (Linux, Windows, switche a routery různí výrobci HW).
9. Možnost definovat komplexnější služby složené z jednotlivých hostů / služeb je bonus, není nutné.
10. Něco, co nebude moc složité. Jak pro běžného uživatele, tak pro nastavení. Jak prvotní, tak v rámci údržby a aby to nevyžadovalo někoho, kdo to bude na půl úvazku oprašovat. Stejně tak by to nemělo mít přehnané požadavky na HW.

Architektura by byla taková, že by v centru byl umístěný server s monitorovacím SW a ten by pak monitoroval služby a hosty přes internet a další přes site2site VPN do lokalit. VPN by zařizoval FW předřazený tomu serveru, takže to by neřešil.

Počet monitorovaných hostů/služeb bude v řádu vyšších stovek, max. menších jednotek tisíců.

Jak jsem uvedl výše, zkušenost mám s CACTI a Nagios. Nagios mi plně vyhovoval, co tam bylo krkolomnější byla konfigurace přes textové soubory. Kdyby se standardní konfigurační věci (přidání hosta, smazání hosta, uživatele) daly klikat, bylo by to lepší, mohl bych do správy zapojit více lidí. V tomto se mi líbila Cacti, která měla nastavení přes webové rozhraní. U ní býval trochu problém při větším množství monitorovaných systémů proces sbírání dat, který pak trval delší dobu (což nějaké řešení mělo). Také reprezentace dat z dnešního hlediska asi nebyla úplně moderní.

Co jsem koukal, tak Nagios je zatím stále uváděn mezi top produkty. Cacti také stále žije. Je cesta kombinace těchto produktů stále správná, nebo jdou trendy spíš jinam? Je tu Icinga, fork z Nagiosu, narazil jsem na celkem dobře hodnocený Zabbix. Chci něco hostovaného na vlastním HW, nemám zájem o žádnou cloudovou službu.

Jaké jsou Vaše zkušenosti a doporučení?

Díky

Štěpán
Název: Re:Dohledový systém
Přispěvatel: AoK 06. 01. 2021, 15:01:08
krátce, možností je pořád spousta, nagios a cacti ještě žije, ale mrkni třeba na prometheus, prometheus alertmanager, systemd-exporters, grafana, je s tím více práce, ale funguje to dobře.

V enteprise poslední dobou nagios odstraňujeme a jedeme buď splunk a několik pluginů nebo elk stack s logstashem, beatem na alerty, část věcí pak jde do front v kafce, kde nad tím může být nějaký IPS/IDS/Alerting.

Cest je ale hodně, ani nagios není špatný, když s ním umíš.

Název: Re:Dohledový systém
Přispěvatel: ⚫⚫⚫ 06. 01. 2021, 15:48:27
Citace
krátce, možností je pořád spousta, nagios a cacti ještě žije, ale mrkni třeba na prometheus, prometheus alertmanager, systemd-exporters, grafana, je s tím více práce, ale funguje to dobře.

To je urcite cesta, ale podobny setup bych doporucil pro nekoho kdo dokaze vyuzit vsechny jeho vyhody. OP dle zadani chce spis neco jednoducheho na spravu, napriklad Zabbix.
Název: Re:Dohledový systém
Přispěvatel: AoK 06. 01. 2021, 16:40:27
jo, zabbix je také dobrý služebník, za mě je dost rozsáhlý na konfiguraci, přidávání vlastních grafů a dashboardů není zrovna snadné. Nemá svůj backend pro ukládní historických dat, takže k němu musíš stejně přidat něco, kde to vše bude uložené, pokud ti nestačí pouze current monitoring. Někomu může vadit frontend v php a s tím spojené těžkosti při upgrade a provozu.

Také to je ale dobrá volba.
Název: Re:Dohledový systém
Přispěvatel: ⚫⚫⚫ 06. 01. 2021, 16:44:10
Grafy a dashboardy pro Zabbix resi https://grafana.com/grafana/plugins/alexanderzobnin-zabbix-app
Název: Re:Dohledový systém
Přispěvatel: AoK 06. 01. 2021, 18:27:21
grafana je ksicht pro zobrazení historických metrik, nemá ale uložiště, tím je třeba prometheus (či výkonnější victoriaMetrics) a jsme vlastně u mé první odpovědi :).

K zjišťovaní trendů potřebuješ historii. Zabbix + grafana + prometheus + prometheus alertmanager je pěkný stack, často ho nasazuji do menších projektů, umí to monitorovat vše, sestavit se to dá rychle, konfiguruje se to dobře přes ui, api i staticky textovými konfigy.

Další možnost je pak věci kolem influxDB, dříve jsem je měl rád, dneska jim nerozumím. Nagios pořád ale patří mezi špičku a není na něm nic zlého, když ho umíš.
Název: Re:Dohledový systém
Přispěvatel: ⚫⚫⚫ 06. 01. 2021, 18:38:37
Samozrejme, ze Zabbix ma data storage - myslq/postgress/timescaledb. Vyhoda zabbixu je prave to, ze nainstalujes dva baliky a mas funkcni nastroj pro pomerne komplexni monitoring.
Název: Re:Dohledový systém
Přispěvatel: Stepan Cirkl 06. 01. 2021, 18:45:18
Co si pamatuji, tak on samotný Nagios také je spíš pohled na aktuální stav, než historii. Respektive, je tam historie pádů, spolehlivost. Na vytížení linek, cpu a pod jsme používali CACTI. Což byly dva nástroje. Tohle mít v jednom by nebylo špatné, aby se člověk nedostával do situace, kdy je to zařízení v jednom systému je a v druhém ne.

Zkusím si ještě něco počíst a asi krapet s tím pohrát. Ten Zabbix nevypadá úplně špatně. Když to bude moc složité, tak hodím Nagios.

Díky
Název: Re:Dohledový systém
Přispěvatel: Václav Ovsik 06. 01. 2021, 19:45:37
Hodil bych oko i na https://checkmk.com/ (https://checkmk.com/). Má to RAW edition, která je OpenSource a používáme to. Výhoda je, že to je značně přímočaré. Samo si to zinventorizuje co najde a sleduje. V té RAW verzi běží uvnitř starý Nagios, ale na vrchu je dosti vymakaný frontend. Teď začátkem roku má vyjít verze 2, která už bude přepsaná do Pythonu 3...
Název: Re:Dohledový systém
Přispěvatel: faha 06. 01. 2021, 21:43:25
https://www.librenms.org
https://www.zabbix.com
Název: Re:Dohledový systém
Přispěvatel: hexdump 07. 01. 2021, 19:43:58
Také doporučuji mrknout na https://checkmk.com/. Jednoduchá minutová instalace a máte vymazlený klikací nagios s grafy.
 Používám jej denně cca 4 roky bez problémů. Teď je před vydáním nová verze s přepracovaným ovládáním. Zatím používám na testovacím virtuálu betaverzi a nezaznamenal jsem problémy. Opravdu doporučuji alespoň zkusit. Výsledek stojí za to.
Název: Re:Dohledový systém
Přispěvatel: Pavel Rauš 08. 01. 2021, 07:55:29
icinga2 - S Directorem ( který zatím nepoužívám ) lze snad vše naklikat a pokud se na servery nainstaluje agent, tak si to spolu bude samo povídat a konfigurovat se.

centreon - kdysi fork nagiosu, dnes už jdou vlastní cestou. Vše se kliká nebo konfiguruje přes api.

Obojí mám prakticky vyzkoušené z poměrně velkých instalací. Obojí vyžaduje na začátku poměrně dost času na pochopení a správnou instalaci ( ale to je asi obecná vlastnost komplexních monitorovacích systémů ). Ale když to člověk udělá správně tak v obou případech je pak následná správa jednoduchá a kromě aktualizací je to víceméně bezúdržbové. Obojí má aktivní vývoj, nejsou tam žádné náznaky, že by projekt měl umřít.

Samozřejmě existují i věci jako prometheus apod. - ten bych si jako primární monitoring asi nevybral ( podobně jako stejnojmenný film, je to trošku horror ), ale třeba jako doplněk stávajícího monitoringu pro detailnější pohled do kubernetes platformy ... asi proč ne.

A k té grafaně - lezou z toho pěkné grafy, jejich definice ale neni jednoduchá a pozor - hotové dashboardy mají dost často chyby, které nejsou na první pohled vidět ( člověk si toho všimne obvykle až ve chvíli, kdy mu začné být podezřelé, že má na 1Gbit síťovce špičky 1.5Gbit :-) ). Náročnost pro zobrazení dat na klientovi je obrovská.
Název: Re:Dohledový systém
Přispěvatel: AoK 08. 01. 2021, 11:46:24
Pavel Rauš: používáš centreon ve free nebo placené verzi? Mně ta free připadá výrazně omezená na konfiguraci, chybí tam spousta užitečných funkcí, v placené verze to je ale výtečný nástroj a rád s ním dělám

U icinga2 jsem byl z prvnu nadšený z Directoru, vše se nakliká, ale pak vlastně člověk ztratí přímou vazbu mezi monitorováním a konfigurací. Spousty textových souborů, které mohu generovat externě ze systému podle šablon zase také nejsou k zahození, dá se nad tím dobře dělat review, dobře to verzovat, sdílet. Je to na osobní preferenci.

Prometheus + Grafana jsou hodně nenažrané a problémové, grafana vše renderuje z primárních dat až na frontendu, pokud chci dlouhé časové osy musím ručně vytvářet vlastní metriky přes agregace rovnou na backendu, to je takové neomalené. Jako malé řešení a rychlý start to je ale poměrně solidní. Grafy na jejich marketplace jsou spíše pro inspiraci než pro použití.

Člověk pak zjistí, že umírající naogis a ve spolupráci s cacti je vlastně pořád dobrá a příjemná volba, zejména pokud to znáš. Řada těch nových nástrojů mají super lazy webové ui, takže nelze rychle scrollovat přes grafy, spotřebu prostředků větší než aplikace, které monitorují a na konfiguace je čím dál častěji vysvětlena na youtube místo v textu.
Název: Re:Dohledový systém
Přispěvatel: _mbily 08. 01. 2021, 16:26:08
 Rovněž provozuji Icingu2 bez Directoru. Stejné důvody jako uvádí kolega, není nad to mít konfiguraci hezky v souborech. Icinga je pěkný nástroj v  moderním kabátku. Sympatická je možnost doinstalovat různá rozšíření (mapičky pro šéfy, grafická znázornění závislostí apod.). Samotné monitorovací jádro ve srovnání s nagiosem ale považuji za poněkud tupé. Tam, kde nagios při podezření na problém pro jistotu ověří i host status dotyčného prvku (a tuším i nadřízeného), tam icinga dál nerušeně jede svým pravidelným rytmem kontrol služeb a hostů. Při dohledování sítových prvků nechcete dostat 20 zpráv o výpadku třeba telefonů, ale jedinou zprávu o výpadku switche, na který jsou připojeny. V icinze mi nezbylo než postupně zapnout tři různé nestandardní volby, kterými se tento problém jakž takž obejde, byť za cenu určitých kompromisů. Autor či autoři tento problém nějak nechtějí chápat a v debatním fóru na výtky většinou reagují tím, že topologicky vzdálenější prvky je třeba testovat méně často.

Pokud na něco stačí nagios, tak bych ho s klidným svědomím nasadil i dnes.
Název: Re:Dohledový systém
Přispěvatel: cjohn 08. 01. 2021, 20:22:11
Zoznam monitorig nastrojov (zial uz par rokov neupdatnuty): https://github.com/monitoringsucks/tool-repos
Novsi: https://github.com/Enapiuz/awesome-monitoring

V zasade su hraci ktory maju viacmenej cely stack na monitoring, ako napr. InfluxDB (TICK stack: Telegraf, InfluxDB, Chronograf, Kapacitor; ELK stack: Beats, Logstash, Elasticsearch, Kibana, ...), pripadne ktori buduju svoj stack (taka Grafana uz nie je iba na vizualizaciu, ale Grafana labs ponuka toho uz viac - Loki, Tempo, ... a samozrejme Grafana ma asi najviac podporovanych time series databaz, z ktorych vies vizualizovat; mozno tak PowerBi je jej konkurenciou vo vizualizacii).

Na "konzervativnu" infrastrukturu budu dobre aj konzervativnejsie nastroje ako Nagios, Cacti a pod. Pokial to uz je progresivnejsie (kontajnery) tak by som cakal ze sa to vysklada z dostupnych novsich monitoring nastrojov - necakal by som ze jeden tool bude riesit vsetko.


Název: Re:Dohledový systém
Přispěvatel: Standa Blábol 09. 01. 2021, 10:22:31
Pro tyhle ucely rozhodne Zabbix s TimescaleDB na historii a proxyny na offload sberu metrik + ansible na spravu zabbixu, je tam pro zabbix luxusni modul + agent2 psany v GO s jednoduchou moznosti vlastnich pluginu

Nagios a jeho klony uz nechte konecne zdechnout.
Název: Re:Dohledový systém
Přispěvatel: Max Devaine 09. 01. 2021, 16:34:23
Používám Centreon. Výhodou je, že je to stále kompatibilní s Nagiosem, tím pádem je dostupné hodně hotových checků.
Má to hodně vymazlené web rozhraní s podporou ACL, lze krásně naklikat komu a za jakých podmínek posílat notifikace atd.
Má to pěkné grafy (umožňuje i jejich split, export a další věci), opravdu detailní nastavení, možnost jednoduchého předávání auth informací z hostu na všechny služby atd.
Ač to vypadá jednoduše, tak pro slušné nastavení to vyžaduje jistý skill. Tzn., že člověk si musí na web ksichtu připravit dobrou posloupnost šablon a dalších věcí tak, aby nebyl problém měnit jednu hodnotu jak globálně, tak na konkrétních službách. Prostě návrh celé struktury je stěžejní. Kdo to zvládne, tak přidání dalšího serveru na monitoring je otázkou pár kliků myší bez přemýšlení.
Jedinou ofiko podporovanou platformou je CentOS, takže nedoporučuji provozovat na ničem jiném, jelikož na ostatních platformách si to musí člověk buildit sám a někdy nemůže přejít na novou verzi, kvůli tomu, že v jiném OS je něco novějšího, ještě nepodporovanýho, než ve starém CentOS.
Centreon provozuji hafec let, býval s tím problém, pak jsem přešel z Debianu na offiko CentOS a posledních cca 5 let no problemo, plynulé upgrady a funguje to.
Má to i nějaký systém pro dynamické konfigurace, ale ten nepoužívám, zatím jedu statiku.
Placený je akorát support a některé rozšířené checky pro jiné služby. Nicméně celé je to OSS a není problém.

CheckMK dost pokročil od doby, co jsem ho viděl naposledy, ale zase pokročil směrem ke closed source, takže tím pádem u mně nemá šanci.
Incynga2 mi přijde, že je za Centreonem hodně pozadu.
Zabbix neznám, resp. nasazoval jsem ho asi před 10 lety a nelíbil se mi, od té doby jsem ho nezkoušel, takže jeho aktální stav neznám.
Zdar Max
Název: Re:Dohledový systém
Přispěvatel: ⚫⚫⚫ 09. 01. 2021, 17:12:11
Nagios a jeho klony uz nechte konecne zdechnout.

+1
Název: Re:Dohledový systém
Přispěvatel: by_cx 09. 01. 2021, 22:41:45
Dlouho jsem používal InfluxDB+Telegraf+Grafana. Fungovalo to výborně, ale není tam tak silná podpora komunity, takže další metriky tam už člověk musí nastrkat sám. Nedávno jsem přešel na Prometheus+node_exporter+cadvisor+Grafana a i když bych řekl, že to potřebuje trochu víc prostředků na samotný monitoring, tak komunita je kolem Promethea mnohem silnější. Navíc alertmanager od vývojářů Promethea je úplně úžasně jednoduchej a zároveň silnej nástroj, bez kterýho bych už žít nechtěl. Když si to člověk všechno nastaví v Ansiblu nebo podobném nástroji, tak při přidávání nového serveru na tyhle detaily vůbec nemusí myslet. Nagios a jeho klony už mají to nejlepší dávno za sebou a nechtěl bych ho znovu používat.
Název: Re:Dohledový systém
Přispěvatel: czechsys 10. 01. 2021, 11:50:45
Dlouho jsem používal InfluxDB+Telegraf+Grafana. Fungovalo to výborně, ale není tam tak silná podpora komunity, takže další metriky tam už člověk musí nastrkat sám. Nedávno jsem přešel na Prometheus+node_exporter+cadvisor+Grafana a i když bych řekl, že to potřebuje trochu víc prostředků na samotný monitoring, tak komunita je kolem Promethea mnohem silnější. Navíc alertmanager od vývojářů Promethea je úplně úžasně jednoduchej a zároveň silnej nástroj, bez kterýho bych už žít nechtěl. Když si to člověk všechno nastaví v Ansiblu nebo podobném nástroji, tak při přidávání nového serveru na tyhle detaily vůbec nemusí myslet. Nagios a jeho klony už mají to nejlepší dávno za sebou a nechtěl bych ho znovu používat.

No, ale ta komunita neni tak silna jak vypada. Kolega delal komplet Ansible/Prometheus/Grafana reseni a delali na tom dva lidi na fullday peknych par dni/tydnu.

Ve Vasem pripade mate tedy v Prometheus stacku co? Slepenec z X ruznych zdroju pro generovani grafu v Grafane ne? To je jedna z veci, co mne stale odrazuje od opetovneho zkouseni P/G, takze mam momentalne rozjety zabbix. A i tak mam problemy obcas sehnat vhodny moduly. Zde je rozsirenost monitoring-plugins apod. v nagiosu stale nejlepsi.

Kdyz to tak vezmu tak mne trapi vzdy 2 veci:
1] hledat vsude mozne zdrojaky a nutnost programovat grafy, pokud to neni out-of-box sjednoceno
2] dodavani vsemoznych extra skriptu na jednotlive monitorovaci body - jo. da se to naprogramovat v ansible, ale ta rozhodovaci logika neni uplne nejjednodussi
Název: Re:Dohledový systém
Přispěvatel: NaRootuJeNeskutecneDebilniRegistracniFormular 10. 01. 2021, 12:52:09
Nagios a jeho klony uz nechte konecne zdechnout.

Vy asi nemate v siti kamery, switche, PDU a podobne veci, ktere se daji monitorovat leda pres SNMP, co?
Název: Re:Dohledový systém
Přispěvatel: ⚫⚫⚫ 10. 01. 2021, 13:57:46
To bych nepovazoval za argument ve prospech Nagiosu.

https://github.com/prometheus/snmp_exporter
https://github.com/influxdata/telegraf/tree/master/plugins/inputs/snmp
Název: Re:Dohledový systém
Přispěvatel: ⚫⚫⚫ 10. 01. 2021, 13:58:22
No, ale ta komunita neni tak silna jak vypada. Kolega delal komplet Ansible/Prometheus/Grafana reseni a delali na tom dva lidi na fullday peknych par dni/tydnu.

Ve Vasem pripade mate tedy v Prometheus stacku co? Slepenec z X ruznych zdroju pro generovani grafu v Grafane ne? To je jedna z veci, co mne stale odrazuje od opetovneho zkouseni P/G, takze mam momentalne rozjety zabbix. A i tak mam problemy obcas sehnat vhodny moduly. Zde je rozsirenost monitoring-plugins apod. v nagiosu stale nejlepsi.

Jako nejvice flexibilni reseni se mi jevi pouzivat Telegraf jako agenta na hostech, ma pluginy na 85% pouzivanych technologii a pripadne jde velmi jednoduse rozsirovat vlastnimi skripty.
Nagios je urceny na stavovy monitoring - funguje/nefunguje. Pro seriozni monitoring potrebujete vic, mnohem vic.

Citace
Kdyz to tak vezmu tak mne trapi vzdy 2 veci:
1] hledat vsude mozne zdrojaky a nutnost programovat grafy, pokud to neni out-of-box sjednoceno
Ano, prinasi to praci navic. Ale zaroven i flexibilitu sestavit si grafy a dashboardy presne podle potreby.

Citace
2] dodavani vsemoznych extra skriptu na jednotlive monitorovaci body - jo. da se to naprogramovat v ansible, ale ta rozhodovaci logika neni uplne nejjednodussi
Souhlasim, CM je v tomhle pripade nutnost.
Název: Re:Dohledový systém
Přispěvatel: AoK 10. 01. 2021, 15:42:06
nagios, zabbix, icinga2 velice dobře slouží k takovémotu obecnému monitorování všeho. Nové věci jako Prometheus/Grafana/Kibana/Kafka/Logstash nasazujeme poslední dobou vedle toho a slouží velice dobře, pokud potřebuji notifikovat, korelovat a sledovat různé události v čase na sobě závislé a pak podle složitých pravidel dávat vědět na různá místa podle závažnosti (ala IDS/IPS/SIEM), stejně tak se hodí velká flexibilita ve sběru různých metrik z různých zdrojů vč. aplikačních dat a to vše v distribuované podobě. Připravené dashboardy a grafy jsou fajn, ale zpravidla si stejně všude potřebujem vytvořit vlastní, je skvělé pokud je možné spojovat metriky z více zdrojů a pohledů vč. hodnot z logů.

Je těžké říct, který ten systém je nejlepší, když každý je k něčemu jinému. Sebelepší systém se mi může rychle rozpadnout, pokud potřebuji monitorovat virtuální stroje (či dnes dockery) s jepičím životem a vázat metriky do nějakých velkých logických celků podle oddělení nebo aplikace. Pak se láme chleba, někdo na to je horší, někdo lepší.

Stejně tak může být rozhodující, jestli si chci tvořit historii i rok zpátky, jestli chci snižovat časem granualitu dat, jestli potřebuji mít možnost nastavit retenci a granualitu pro každou metriku zvlášť, opět je to pro některé nástroje nativní (influxdb) a pro některé neřešitelný.
Název: Re:Dohledový systém
Přispěvatel: NaRootuJeNeskutecneDebilniRegistracniFormular 10. 01. 2021, 16:57:54
To bych nepovazoval za argument ve prospech Nagiosu.

https://github.com/prometheus/snmp_exporter
https://github.com/influxdata/telegraf/tree/master/plugins/inputs/snmp
Ani jeden z nich neresi TRAP/INFORM.
Název: Re:Dohledový systém
Přispěvatel: by_cx 10. 01. 2021, 17:41:38
Citace
No, ale ta komunita neni tak silna jak vypada. Kolega delal komplet Ansible/Prometheus/Grafana reseni a delali na tom dva lidi na fullday peknych par dni/tydnu.

Záleží na spoustě věcí. Když někomu něco zabere týden, tak to nic neznamená. Někdo jiný by to udělal za dva dny, další za měsíc. Navíc nechápu, jak to souvisí s komunitou :-)

Citace
Ve Vasem pripade mate tedy v Prometheus stacku co?

Node exporter, Caddy exporter, Nginx exporter, cAdvisor a nějaké naše věci. První čtyři mají moc pěkné dashboardy už hotové. Dashboard s našimi věcmi jsem naklikal v Grafaně.

Název: Re:Dohledový systém
Přispěvatel: Standa Blábol 11. 01. 2021, 09:39:02
My two cents.

Ze zde dikutovane trojice, Nagios (+klony), Zabbix, Prometheus se to ma takto:

- Nagios uz nechte zdechnout, byl prvni a proto je rozsireny, jinou vyhodu nema

- Zabbix - zdaleka nejlepsi z techto, ve verzi 5.x + proxy + pluggable agent2 psany v GO + ansible oficialni modul + pyzabbix knihovna + TimescaleDB + Grafana - absolutne nejlepsi feature set, ostatni se ani neblizi.
Zabbix vsak vyzaduje vytvoreni pevneho modelu monitorovaneho sveta, ktery se polluje. Neni vhodny pro dynamicke kontejnerove aplikace, kde kontejnery vznikaji a zanikaji podle aktualniho loadu

- Prometheus + AlertManager - specializovany dohled vznikly pro potreby Kubernetes, resi problem dynamickych kontejneru. Jinak je funkcne dost omezeny a je to defacto funkcionalni navrat k devadesatym letum, kdy letely hloupe eventove konzole + RRD. V pripade kontejneru to ale jinak nejde, tam se pevny model monitorovaneho sveta ve stylu Zabbixu, CA Spectrum, EMS Smarts proste udelat neda.
Existuje pro to spousta rovnaku na ohybaky typu SNMP exporteru, funcionalite Zabbixu v teto staticke oblasti se to ani neblizi.

Resultat:
Pokud chci monitorovat staticky svet -> Zabbix
Pokud chci monitorovat pouze dynamicky svet (kontejnery) -> Prometheus
Pokud mam oboje -> Zabbix a AlertManagerem do nej preposilat vyhodnocene eventy z Promethea
Název: Re:Dohledový systém
Přispěvatel: czechsys 11. 01. 2021, 10:31:05
- Zabbix - zdaleka nejlepsi z techto, ve verzi 5.x + proxy + pluggable agent2 psany v GO + ansible oficialni modul + pyzabbix knihovna + TimescaleDB + Grafana - absolutne nejlepsi feature set, ostatni se ani neblizi.

Tohle by mne zajimalo, co to umi. Proxy je mi jasna, agent2 taky pouzivam - ale ten je podporovan je nekterych verzich debianu (zavislost na ssl apod).
S ansiblem mam ten problem, ze pak je problemove to spravovat z GUI.
Co mne nejvic zajima - k cemu ten pyzabbix, k cemu ta timescaledb (ja to mam v postgresql). Jak je to s tou grafanou - co se tam musi udelat, kazdy graf kazdeho monitorovaneho modulu se musi prevytvorit ci jak?
Název: Re:Dohledový systém
Přispěvatel: Standa Blábol 11. 01. 2021, 11:03:49
- Zabbix - zdaleka nejlepsi z techto, ve verzi 5.x + proxy + pluggable agent2 psany v GO + ansible oficialni modul + pyzabbix knihovna + TimescaleDB + Grafana - absolutne nejlepsi feature set, ostatni se ani neblizi.

Tohle by mne zajimalo, co to umi. Proxy je mi jasna, agent2 taky pouzivam - ale ten je podporovan je nekterych verzich debianu (zavislost na ssl apod).
S ansiblem mam ten problem, ze pak je problemove to spravovat z GUI.
Co mne nejvic zajima - k cemu ten pyzabbix, k cemu ta timescaledb (ja to mam v postgresql). Jak je to s tou grafanou - co se tam musi udelat, kazdy graf kazdeho monitorovaneho modulu se musi prevytvorit ci jak?

Pro Ansigle je GUI AWX, osobne pro ansible GUI nepotrebuju.
Pyzabbix je knihovna pro Python pro praci s Zabbix API a zabbix sender. Da se s tim velice jednoduse na zabbixu naskriptovat cokoliv, co udelas z GUI.
TimescaleDB je time-series extenze do postgresu, samo se to pak stara o housekeeping a podporuje kompresi metric dat, typicky ping metrika, kde je v 99% porad 0 (OK) se zkomprimuje do par KB. Ale toto ocenis spise u vetsich instalaci, pro male monitorovane baze postaci holy Postgres
Greafana: https://www.zabbix.com/integrations/grafana
Ale popravde, posledni verse Zabbix dashboardu jsou z Grafany opajcovane a maji obdobnou funkcionalitu.

Název: Re:Dohledový systém
Přispěvatel: by_cx 11. 01. 2021, 11:55:35
Citace
Prometheus + AlertManager - specializovany dohled vznikly pro potreby Kubernetes

Prometheus je starší než Kubernetes, tak jak mohl vzniknout pro jeho potřeby? Dokonce je starší než Docker. Vznikl v době, kdy světu serverů vládla stará dobrá virtualizace.

Název: Re:Dohledový systém
Přispěvatel: matuscak 11. 01. 2021, 12:17:12
Zabbix som naposledy skúšal pred niekoľkými rokmi a narazil som vtedy na viaceré problémy, ktoré ho robili z môjho pohľadu v porovnaní s "Nagios klonmi" horšie použiteľným. Spomínam si na nasledovné:

1. Nemožnosť upravovať frekvenciu testovania v prechodných stavoch.

U Nagiosu som bol zvyknutý na to, že testujem dostupnosť povedzme 1x za 10 minút a keď nastane error, tak to pretestujem ešte povedzme 2x v odstupe 1 minúta a ak sa chyba opakuje, tak generujem notifikáciu. Takto mám istotu, že nebudem zbytočne notifkovaný pri náhodnom jednorazovom zlyhaní testu (zlyhania musia byť minimálne 3), testovať mi normálne stačí iba raz za 10 minut a aj tak sa o poruche dozviem najneskôr do 12 minút od jej vzniku.

V Zabbixe toto možné nebolo a buď som teda testoval každú minútu stále (čo je zbytočný load) alebo ak som testoval iba každých 10 minút, tak som sa o probléme dozvedel až po 30 minútach, alebo som ho musel hlásiť už po jednom zlyhaní (čo zvyšovalo riziko falošných poplachov).

2. Veľmi obskurný jazyk na definíciu alertov so spústou obmedzení
Napríklad si pamätám, že ak mi dva testy (data sources) vracali údaj typu string (napríklad serial number nejakého deploynutého datasetu) tak nebolo možné zapísať alert ktorý by sa aktivoval na základe zhody/nezhody týchto reťazcov, porovnávať sa dali len numerické hodnoty.

A už vôbec nebolo možné napísať podmienku toho typu, že "aktivuj alert ak sa tieto dva údaje nezhodujú dlhšie ako 5 minút".

3. Limitované možnosti offloadovania testov na agenta
Štandardne všetky testy robil Zabbix server, bola aj možnosť nechať testy vykonávať agenta s tým, že ich výsledky iba "reportuje" na Zabbix. Problém ale bol, že tieto testy  nevedel agent vykonávať paralelne, čiže ak sme ho nechali robiť viacero testov a jeden z nich z nejakého dôvodu trval dlho (čakalo sa na timeout), tak aj vykonávanie všetkých ostatných testov na danom agentovi bolo zastavené a "nestíhalo".

Toto sú hlavné problémy, čo si z testovania Zabbixu pamätám.  Budem rád, ak niekto, kto pozná súčasné verzie Zabbixu, potvrdí, či to stále platí, alebo to už bolo nejako vyriešené.

Název: Re:Dohledový systém
Přispěvatel: Standa Blábol 11. 01. 2021, 13:53:30
Zabbix som naposledy skúšal pred niekoľkými rokmi a narazil som vtedy na viaceré problémy, ktoré ho robili z môjho pohľadu v porovnaní s "Nagios klonmi" horšie použiteľným. Spomínam si na nasledovné:

1. Nemožnosť upravovať frekvenciu testovania v prechodných stavoch.

U Nagiosu som bol zvyknutý na to, že testujem dostupnosť povedzme 1x za 10 minút a keď nastane error, tak to pretestujem ešte povedzme 2x v odstupe 1 minúta a ak sa chyba opakuje, tak generujem notifikáciu. Takto mám istotu, že nebudem zbytočne notifkovaný pri náhodnom jednorazovom zlyhaní testu (zlyhania musia byť minimálne 3), testovať mi normálne stačí iba raz za 10 minut a aj tak sa o poruche dozviem najneskôr do 12 minút od jej vzniku.

V Zabbixe toto možné nebolo a buď som teda testoval každú minútu stále (čo je zbytočný load) alebo ak som testoval iba každých 10 minút, tak som sa o probléme dozvedel až po 30 minútach, alebo som ho musel hlásiť už po jednom zlyhaní (čo zvyšovalo riziko falošných poplachov).

2. Veľmi obskurný jazyk na definíciu alertov so spústou obmedzení
Napríklad si pamätám, že ak mi dva testy (data sources) vracali údaj typu string (napríklad serial number nejakého deploynutého datasetu) tak nebolo možné zapísať alert ktorý by sa aktivoval na základe zhody/nezhody týchto reťazcov, porovnávať sa dali len numerické hodnoty.

A už vôbec nebolo možné napísať podmienku toho typu, že "aktivuj alert ak sa tieto dva údaje nezhodujú dlhšie ako 5 minút".

3. Limitované možnosti offloadovania testov na agenta
Štandardne všetky testy robil Zabbix server, bola aj možnosť nechať testy vykonávať agenta s tým, že ich výsledky iba "reportuje" na Zabbix. Problém ale bol, že tieto testy  nevedel agent vykonávať paralelne, čiže ak sme ho nechali robiť viacero testov a jeden z nich z nejakého dôvodu trval dlho (čakalo sa na timeout), tak aj vykonávanie všetkých ostatných testov na danom agentovi bolo zastavené a "nestíhalo".

Toto sú hlavné problémy, čo si z testovania Zabbixu pamätám.  Budem rád, ak niekto, kto pozná súčasné verzie Zabbixu, potvrdí, či to stále platí, alebo to už bolo nejako vyriešené.

Ad 1.
Zabbix resi obdobny problem jinak.
Sbira se normalne s periodou 1 minuta, pricemz na item je aplikovany preprocessing step "Throttling - Discard unchanged with heartbeat", takze hodnota je pollovana fyzicky co minutu, zapis do historicke DB co 10 minut, kdyz dojde k problemu, automaticky se ukladaji zmenene hodnoty s periodou minuta. Preprocessing i vlasni mereni se deji na proxy, server dostane uz predzvykany vysledek.
Tento mechanismus odhali chybu po 3 minutach, namisto 12, pri stejnych pozadavcich na historickou DB.
Jinak s nasazenim TimescaleDB time-series extension do postgresu spolu se zapnutou kompresi se vykonove dostavame uplne jinam, velka radu vykonnostnich omezeni uz neni potreba resit.
A pokud je precejen nutno pouzit vyse popsany mechanismus z duvodu omezeni loadu na merenem prvku, mozno lokalne naskriptovat a metriky zasilat asynchronne senderem, tak bych to resil ja. Dalsi alternativa je custom plugin v GO do Zabbix Agent2.

Aktivovat alert pokud se dve metriky neshodovaly vice nez 5 minut, slo vicemene vzdycky. Bud krapet neohrabane, ze se porovnavaly shody retezce ve vzorku LAST && LAST-1 && LAST-2, az se pokrylo cele pozadovane okno, nebo se udelal dodatecny computed item (nastaveny aby se neukladal do historic DB, jenom se bral z cache), s informaci 0/1 ok/bad a ten se vyhodnotil min(5m)=1.

Ad 2. Porovnavat stringy slo vzdycky, nyni je uz primo mozno aplikovat preprocessing step "Regex substr", vyparsovat ho cislo a ulozit jej numericky.

Ad 3. Zabbix agent1 psany v C mel v defaultni konfiguraci povolene 4 processing thready, po vycerpani threadu ostatni checky staly. Zabbix agent 2 je psany v GO a vsecko sere paralelne do gorutin. To ovsem nic nemeni na faktu, ze UserParameter skripty maji byt rychle a jednoduche, mely by skoncit do 5 sec, jinak je vhodne pouzit neco jineho.  Typicky dlouhe checky nechat agentem jenom invokovat a vysledek posilat asynchronne zabbix senderem (pouziva stejny TCP port jako Zabix Agent v active modu, takze zde neni problem s firewall rules) Pripadne, nyni je moznost jednoducheho dopsani pluginu v GO do agenta2, ten pak muze uplne cokolivek.  Treba novy Oracle monitoring je napsany jako modul do agent2 - sam si drzi session spojeni a provadi SQL dotazy do session views.
Název: Re:Dohledový systém
Přispěvatel: lazywriter 11. 01. 2021, 14:35:03
Záleží na velikosti a dynamice prostředí.
Sám provozuju monitoring nad nižšími stovkami nodů (fyzické, virtuály, kontejnery) v Icinga2. S integrovanými metrikami v Graphite, správou přes Ansible (při deploy služby se automaticky doplní i příslušné checky) a notifikacemi přes PagerDuty je to prostředí s jednoduchou správou, rychlou učící křivkou a dostatečným výkonem.
Název: Re:Dohledový systém
Přispěvatel: matuscak 11. 01. 2021, 14:41:59
Ad 2. Porovnavat stringy slo vzdycky

Tak to teda rozhodne nešlo, keď som to ja testoval, tak vyhodnocovať v trigeroch nenumerické hodnoty nebolo možné.

Pozrel som si teraz dokumentáciu a práca so stringami je novinka verzie 5.0 vydanej pred pol rokom, viď. druhy odstavec v nasledovnom texte:
https://www.zabbix.com/documentation/5.0/manual/introduction/whatsnew500 (https://www.zabbix.com/documentation/5.0/manual/introduction/whatsnew500)

A to stále jediná operácia, čo sa dá so tringami spraviť, je porovnať dva stringy na zhodu/nezhodu, nič komplikovanejšie ako napr. porovnanie substringov možné nie je.

A presne takto si ten Zabbix pamätám, že ten jazyk/syntax na definíciu trigerov bol značne obmedzený a plný nepochopiteľných absurdít.

Název: Re:Dohledový systém
Přispěvatel: Stepan Cirkl 12. 01. 2021, 13:23:13
Zatím jsme dospěl k závěru, že se podívám na Zabbix.

Ve čtvrtek je webinář na téma Poznejte Zabbix Agent 2 a v pátek Quick introduction to Zabbix, tak se na ně podívám a zkusím si s tím pak pohrát.

Potvrdili jste mi můj pocit, že od dob Nagiosu přece jen k nějakým posunům došlo, dám jim tedy šanci. A Nagios si nechám jako fallback řešení.

Děkuji Vám za dosud poskytnuté konzultace a pohledy.
Název: Re:Dohledový systém
Přispěvatel: ivoszz 13. 01. 2021, 12:15:41
Ad 2. Porovnavat stringy slo vzdycky

Tak to teda rozhodne nešlo, keď som to ja testoval, tak vyhodnocovať v trigeroch nenumerické hodnoty nebolo možné.

Pozrel som si teraz dokumentáciu a práca so stringami je novinka verzie 5.0 vydanej pred pol rokom, viď. druhy odstavec v nasledovnom texte:
https://www.zabbix.com/documentation/5.0/manual/introduction/whatsnew500 (https://www.zabbix.com/documentation/5.0/manual/introduction/whatsnew500)

A to stále jediná operácia, čo sa dá so tringami spraviť, je porovnať dva stringy na zhodu/nezhodu, nič komplikovanejšie ako napr. porovnanie substringov možné nie je.

A presne takto si ten Zabbix pamätám, že ten jazyk/syntax na definíciu trigerov bol značne obmedzený a plný nepochopiteľných absurdít.
To, že máte nějaká očekávání a ono to nejde podle nich neznamená, že to nejde nějak jinak. Níže odkaz na dokumentaci Zabbix 2.0, Example 6, kde se přímo testuje na konkrétní substring (funkce str()).
https://www.zabbix.com/documentation/2.0/manual/config/triggers/expression

P.S.: Většina vašich výtek jsou nesmysly, jediné s čím souhlasím je, že zápis je nepřehledný. Možnosti konfigurace triggerů v Zabbixu většinou dalece převyšují schopnosti jiných systémů (i komerčních).