Nový Zabbix 8.0 LTS je téměř zde!

Verze Zabbix 8.0 je téměř zde!

Nová verze Zabbix 8.0 přinese řadu zajímavých novinek.

Nový korelační engine CEP (Complex Event Processing)

Jednou z hlavních novinek Zabbixu 8.0 je nový korelační engine CEP, tedy Complex Event Processing. Navazuje na dosavadní práci s událostmi, ale posouvá ji o úroveň dál: místo jednoduchého posuzování jednotlivých problémů umožňuje vyhodnocovat souvislosti mezi více událostmi, pracovat s časovým oknem, tagy, skupinami hostů a následnými operacemi.

V praxi to řeší jeden z nejčastějších problémů monitoringu. Jeden reálný incident často vygeneruje desítky až stovky událostí. Výpadek sítě, databáze, storage nebo centrální služby se může projevit na mnoha hostech a aplikacích najednou. Bez další logiky pak administrátor neřeší jeden incident, ale dlouhý seznam problémů, které spolu souvisí. CEP má pomoct z těchto událostí vytvořit srozumitelnější obraz.

Smyslem CEP není jen zobrazit, že vznikl problém. Cílem je umožnit nad proudem událostí dělat pokročilejší logiku: seskupovat související problémy, vyhodnocovat je v časovém okně, doplňovat jim tagy, měnit závažnost, potlačovat méně důležité události nebo rozlišovat mezi příčinou a následky.

Konfigurační pravidla najdete v Data collection > Event processing

Detail nastavení

Na obrázku je detail CEP pravidla. V horní části se nastavuje, jaké eventy má pravidlo zachytit, uprostřed je logika časového okna a seskupování a ve spodní části jsou operace, které Zabbix nad odpovídajícími eventy provede.

• Name je provozní identifikace pravidla. U větších instalací dává smysl do názvu dostat účel pravidla, například lokalitu, službu, typ incidentu nebo očekávaný výsledek korelace.
• Type of calculation a Conditions tvoří vstupní filtr. Pravidlo může eventy vybírat podle názvu, severity, hosta, host group nebo tagů. V příkladu se pracuje s host group pro New York, tagem lokality a minimální severity. Právě tady se rozhoduje, které eventy se do korelační logiky vůbec dostanou.
• Time window určuje režim zpracování v čase.
  • None znamená reakci bez časového okna.
  • Simple drží odpovídající eventy po dobu nastavenou v Duration.
  • Cause and symptoms grouping je určený pro vztah příčina versus symptomy.
  • Tag correlation páruje eventy podle tagů.
  • Event pattern match pracuje se vzorem událostí.
• Duration definuje délku okna. Hodnota 10m znamená, že se související eventy sledují v desetiminutovém intervalu a mohou být vyhodnocené jako jeden korelační kontext.
• Capacity omezuje počet eventů v okně. Po dosažení limitu může být event z okna vyřazen kvůli kapacitnímu omezení. Na takovou situaci pak mohou navazovat operace typu Event evicted, například změna severity nebo doplnění tagu.
• Group by říká, jak se eventy uvnitř okna rozdělí do skupin. Prakticky jde o host group, hosta nebo hodnotu konkrétního tagu, například lokalitu, službu nebo prostředí. U tagů je potřeba počítat s přesným názvem včetně velikosti písmen.
• Event count tag se používá u režimů, kde je důležitý počet souvisejících eventů. Výsledek se může propsat do tagu, takže je přímo u problému vidět rozsah korelace.
• Operations jsou výstup pravidla. Tady se nastavuje, co má Zabbix s eventy udělat: přidat nebo upravit tag, změnit severity, potlačit symptom, změnit název eventu nebo jinak ovlivnit jeho další zpracování.
• Stop processing zastaví vyhodnocování dalších CEP pravidel pro stejný event po zpracování aktuálního pravidla. To je důležité pro prioritizaci pravidel a pro situace, kdy jedno pravidlo incident jednoznačně klasifikuje.
• Sort order určuje pořadí vyhodnocování. Nižší hodnota se zpracuje dříve, takže spolu se Stop processing umožňuje řídit prioritu celé korelační logiky.

Možnosti operací uvnitř CEP pravidla vypadají takto:

V dialogu Operation details se nejdřív nastavuje, kdy se má operace spustit a na jakou část korelovaných eventů se má vztahovat. Přepínače All events, Cause events a Symptom events jsou důležité hlavně u pravidel, která rozlišují příčinu a následky. Pod tím je možné přidat ještě filtr podle event tagů, takže stejná CEP logika může nad různými typy událostí provést jinou akci.

• Event occurred se spustí ve chvíli, kdy do pravidla vstoupí nová odpovídající událost. Hodí se pro okamžité doplnění kontextu, například tagu nebo upraveného názvu.
• Event evicted nastane, když událost z časového okna vypadne, například kvůli limitu kapacity nebo posunu času. Díky tomu lze odlišit eventy, které už do aktuální korelační skupiny nepatří.
• Window closed se vyhodnotí při uzavření časového okna, tedy po době určené hodnotou Duration. To dává smysl pro akce, které mají proběhnout až po nasbírání celé skupiny eventů.
• Tags correlated se používá u korelace podle tagů, kdy pravidlo najde události se společným kontextem.
• Event pattern matched patří k režimu, kde se vyhodnocuje vzor událostí. Typicky se používá ve chvíli, kdy nestačí samotný počet nebo společný tag, ale záleží i na posloupnosti nebo kombinaci eventů.

Spodní část Operation je samotná akce, kterou Zabbix nad vybranými eventy provede. Nejde tedy jen o filtr, který události najde, ale také o následné zpracování. Podle typu operace se vedle výběru akce zobrazí další pole, například nový název eventu, cílová severity, název tagu nebo hodnota tagu.

• Set event name přepíše název eventu. Praktické je to ve chvíli, kdy chcete z několika technických hlášek udělat čitelnější incidentový název.
• Close a Discard pracují s životním cyklem eventu. Jedna varianta event uzavře, druhá ho může vyřadit z dalšího zpracování, pokud už v daném korelačním kontextu nemá přinášet hodnotu.
• Set severity, Increase severity a Decrease severity umožňují upravit závažnost podle toho, co CEP zjistí. Samostatný problém může mít nižší prioritu, ale v kombinaci s dalšími eventy může jít o vážnější incident.
• Suppress potlačí vybraný event, typicky symptom, který už nechcete ukazovat stejně výrazně jako pravděpodobnou příčinu.
• Add tag, Set tag a Set tag value doplní nebo upraví tagy. To je užitečné pro další filtrování, notifikace, dashboardy i návaznou automatizaci.
• Increase tag value a Decrease tag value pracují s hodnotou tagu jako s čítačem nebo číselným kontextem, například pro počet souvisejících eventů v korelační skupině.
• Rename tag a Remove tag pomáhají normalizovat metadata eventů, aby se dál v Zabbixu pracovalo s jednotným názvoslovím.
• Copy first a Copy last dávají smysl u pattern match scénářů, kde chcete přenést informaci z první nebo poslední události ve zjištěném vzoru.

Příklad: incident v lokalitě New York

Pro představu si vezměme jednoduchý scénář: v lokalitě New York vznikne během krátké doby více problémů na edge gateway, databázovém clusteru a aplikačním serveru. Každý problém dává sám o sobě smysl, ale pro operátora je důležitější vědět, že pravděpodobně patří ke stejnému incidentu.

Před korelací

Bez korelace jde o běžný seznam problémů. Vidíme více událostí se společným kontextem, například site=nyc, region=us-east nebo podobné služby, ale Zabbix je v této podobě stále zobrazuje hlavně jako samostatné problémy. Operátor si vztah mezi nimi musí odvodit z názvů, hostů, severity a tagů.

• problémy vznikly ve stejném časovém úseku,
• část z nich má stejné lokalizační tagy, například site=nyc a region=us-east,
• některé události mohou být označené jako kandidáti pro další analýzu, například ai.candidate=yes,
• bez další logiky ale není na první pohled jasné, co je hlavní příčina a co jsou jen následné symptomy.

Po korelaci

Po zpracování CEP pravidlem se události začnou chovat jako související skupina. V příkladu je databázový problém označený jako pravděpodobná příčina a ostatní problémy jsou vedené jako symptomy. V pohledu Problems je vidět také počet navázaných symptomů a výstupní tag cep.count=5, který dává informaci o rozsahu korelace přímo do metadat události.

• Root cause zůstává viditelný jako hlavní problém, na který se má operátor zaměřit jako první.
• Symptomy nezmizí, ale jsou svázané s hlavní příčinou. Dávají kontext, aniž by se tvářily jako samostatné incidenty stejné důležitosti.
• Společné tagy, například cep.scope=nyc-outage-window, umožní pozdější filtrování, reporting nebo navázání notifikací a automatizace.
• Count tag, například cep.count=5, ukazuje počet souvisejících symptomů nebo rozsah zasažené skupiny přímo v event datech.

Praktický dopad je v tom, že monitoring nepředkládá jen delší seznam jednotlivých problémů. Události dostanou kontext: co spolu pravděpodobně souvisí, co vypadá jako příčina, které problémy jsou následky a jak velká skupina událostí do incidentu patří.

CEP proto vnímáme jako jednu z hlavních změn Zabbixu 8.0. Nejde o náhradu dosavadní práce s problémy, ale o novou úroveň event managementu: Zabbix může nad událostmi udržovat kontext, spojovat je do souvisejících skupin a automaticky doplňovat informace, které administrátor jinak hledá ručně.

Původní global event correlation pravidla v rozhraní zůstávají, ale jsou vedená jako legacy/deprecated cesta vedle nového CEP. Prakticky to znamená, že stávající pravidla nezmizí, ale nový vývoj směřuje k části Event processing a CEP.

Widget Scatter plot

Jednoduše: vezmete dvě metriky (X a Y osa) a Zabbix vám pro každý host/časový úsek vykreslí body. Na jeden pohled tak uvidíte korelaci (nebo naopak její chybění), shluky problémových strojů a anomálie, které v klasickém časovém grafu snadno zaniknou.
Přínosy

• Vztahy metrik: např. „když roste CPU, roste i RAM?“
• Outliery: rychlá detekce vyčnívajících serverů.
• Vizuální triáž: okamžitá priorita, kam se dívat.

Jak funguje

• Datasety: více sad; každá má X‑Axis item a Y‑Axis item.
• Filtrování hostů: Host patterns / Host groups / Host tags.
• Agregace: Aggregation interval (např. 1m) + funkce (např. avg) → jeden bod/okno.
• Vzhled: volba markeru a velikosti; tooltips s hodnotami; time shift pro srovnání období.

Prahy (thresholds)

Kombinované podmínky pro X a Y mění barvu bodu, např. X ≥ 5 AND Y ≥ 36. Více pravidel = více barev → anomálie jsou okamžitě viditelné. (Na obrázku)

Příklady scénářů

• CPU load vs. Memory usage
  Osa X: průměrné zatížení CPU
  Osa Y: procento obsazené RAM
  → Hned vidíte, jestli hosty s vysokým CPU mají i vysokou RAM zátěž. Skvělá první diagnostika „CPU bound“ vs. „RAM bound“.
• Disk usage vs. I/O latency
  Osa X: procento využití disku
  Osa Y: odezva (ms)
  → Odhalí servery s přetíženým storage. Kombinace vysoké využití + vysoká latence je červená vlajka pro I/O.
• Network traffic vs. Error rate
  Osa X: odchozí / příchozí traffic (bps)
  Osa Y: chybovost (dropped packets, errors)
  → Najdete stroje, které sice nemají velký provoz, ale mají hodně chyb – typicky špatné linky, duplex, MTU, driver.
• Response time vs. Availability (služby / aplikace)
  Osa X: průměrný response time (ms)
  Osa Y: procento dostupnosti (%)
  → Rozliší „pomalé, ale stabilní“ vs. „rychlé, ale nespolehlivé“ služby. Strategický pohled pro prioritizaci práce týmu.

ClickHouse backend a výrazná vylepšení pro Elastic

Velkou novinkou je podpora ClickHouse databáze jako volitelného úložiště pro historická data. Hlavní motivací je bezesporu propojení s novou podporou JSON typu dat – právě u takového objemu a struktury dat dává analytický backend typu ClickHouse perfektní smysl.

Koncept i konfigurace jsou velmi podobné tomu, co už řada z vás zná z volitelného napojení na Elastic. Zabbix tak může historická data ukládat do alternativního backendu bez zásahu do základní architektury. Do ClickHouse lze ukládat všechna historická data kromě typu BIN, což pokrývá drtivou většinu běžných i pokročilých use-casů.

Velkou výhodou je, že nastavení lze kombinovat i s Elasticem a (nově) i s ClickHouse a rozdělit typy dat podle toho, kde dávají největší smysl – při zachování PostgreSQL jako primárního backendu pro většinu standardní historie.

Typický scénář může být například:

• LOG / TEXT / CHAR → Elastic(kvůli vyhledávání, fulltextu, práci s logy a “observability” dotazům nad textem)
• Numerická data (float/uint) → PostgreSQL(jako stabilní a osvědčený time-series backend pro klasické metriky a trendy; jednoduchost, kompatibilita, prověřený provoz)
• JSON → ClickHouse(kvůli analytickému výkonu nad semi-strukturovanými daty, agregacím, filtrování a “wide” dotazům nad JSON strukturou)

A samozřejmě si můžete strategii otočit podle priorit – např. když chcete maximum dát do analytického backendu, nebo když vám jde naopak o co nejjednodušší architekturu a ClickHouse použít jen tam, kde to reálně přinese největší efekt (typicky právě JSON).

Frontend konfigurace (Zabbix UI / frontend)

Konfigurace ve frontendu je definovaná v /etc/zabbix/web/zabbix.conf.php pomocí pole $HISTORY_PROVIDERS. Každý backend (ClickHouse, Elastic) je uveden jako samostatná položka tohoto pole – proto jsou jednotlivé bloky oddělené čárkou (standardní PHP syntaxe). V praxi tak můžete mít ClickHouse jako primární provider pro vybrané typy a hned pod ním doplnit další provider (např. Elastic) pro str.

Server konfigurace (Zabbix server)

Druhá část nastavení je pak v /etc/zabbix/zabbix_server.conf, kde se jednotlivé providery definují samostatně po řádcích jako opakovaná direktiva HistoryProvider. Na rozdíl od frontendu nejde o “seznam položek”, ale o konfiguraci ve stylu provider;options, přičemž samotné volby (url=..., db=..., username=...) jsou oddělené čárkami.

Použití těchto backendů je navíc velmi snadno ověřitelné přímo v Zabbix server logu – hned při startu serveru se vypíše seznam aktivních history providerů (včetně detekované verze a přiřazených value_types), takže máte okamžitě jistotu, kam se která historická data ukládají.

Data pak ve frontendu vypadají úplně stejně – z pohledu UI není žádný rozdíl mezi tím, zda jsou historická data uložená v PostgreSQL, ClickHouse nebo Elasticu. Zabbix transparentně zobrazuje poslední hodnoty, historii i grafy bez ohledu na použitý backend; výjimkou jsou pouze BIN hodnoty, které zůstávají uložené v primární databázi serveru (PostgreSQL/MySQL).

Elasticsearch

Elastic backend zároveň prošel výraznými interními změnami – největší rozdíl je ve způsobu komunikace. Nově se více spoléhá na recyklaci spojení (connection reuse) a další optimalizace v síťové vrstvě i v práci s požadavky. Výsledkem je, že se tento backend z pohledu Zabbixu citelně zrychlil, a to hlavně v prostředích s vysokou dotazovací frekvencí a velkým objemem ukládaných dat.

Multi-host connection string pro PostgreSQL backend

Za nás je toto jedno z nejlepších praktických vylepšení pro PostgreSQL backend vůbec. Možnost zadat do DBHostvíce host:port adres v jednom řetězci (oddělených čárkou) a nechat Zabbix, aby si při startu sám našel první dostupný read-write uzel, výrazně zjednodušuje nasazení i provoz – hlavně v HA prostředích. V praxi to často znamená méně závislostí na externím load balanceru a elegantnější, “self-contained” konfiguraci přímo v Zabbixu.

Nová možnost ukládání dat ve formátu JSON

Konečně jsme se dočkali: do (téměř) nativního světa práce s JSON v Zabbixu přibyla i možnost taková data ukládat přímo do databáze – ve formátu JSON. Funkce je dostupná jak na straně proxy, tak na straně serveru. Jde o podobný koncept, jaký už známe z binárních dat, která používáme například pro ukládání screenshotů. Samozřejmostí je i podpora partitioningu nad novou tabulkou. Podpora se promítá také do Elastic implementace.

Ještě jedna důležitá výhoda: na rozdíl od binárního ukládání lze tento typ využít nejen u master itemů, ale také u dependent itemů.

Primární využití vidíme u velkého množství master itemů. Maximální velikost takto uložených dat v rámci jednoho zápisu je 128 MiB.

Stejně jako u typu Binary, který znáte už od verze 7.0, ani zde není možné vytvářet triggery – a ani to není cílem takto ukládaných dat. Důvodem je, že by takové triggery mohly extrémně zatěžovat value cache na serveru. Jde tedy spíš o technické (kapacitní/výkonnostní) omezení – aby se data vešla do paměti používané value cache – než o to, že by to technicky nešlo implementovat.

Přibyl Export a Import dashboardů

Konečně přibyla i možnost exportu a importu dashboardů. Podobnou věc jste sice mohli řešit už přes API, ale bylo potřeba přesně namapovat jednotlivé entity podle jejich ID – jinak import neproběhl.

Teď máte v rozhraní k dispozici dvě tlačítka: jedno pro Export (ve formátu, jak ho ze Zabbixu znáte) a druhé pro Import.

Tlačítko Import najdete v pravém horním rohu přehledu dashboardů, hned vedle Create dashboard.

Samotný import je intuitivní: můžete vytvářet úplně nové dashboardy a pokud už existují, můžete aktualizovat ty stávající. Import samozřejmě umí přenést i stránky (pages), pokud je v dashboardech používáte.

Při importu se jednotlivé objekty nevyhledávají podle ID, ale podle názvů. V našem příkladu došlo k přejmenování hostu z „Zabbix server“ na „Zabbix server RENAMED“ a systém pak už nebyl schopen hosta najít. Řešení je ale jednoduché: vazbu lze snadno upravit přímo ve frontendu, případně úpravou exportovaného souboru.

Před samotným importem navíc uvidíte přehled, které části se přidají, které se smažou a které se aktualizují – a to včetně konkrétních změn.

Clustering v GeoMap widgetu

V widgetu GeoMap si teď můžete nastavit různé chování shlukování hostů na mapách. Na výběr máte Auto(původní/výchozí chování) a novou možnost Zoom level. U Zoom level se shlukování mění při definovaném prahu přiblížení – například když je práh nastavený na 8, při přiblížení se rozbalí do jednotlivých prvků jen několik markerů; když ho snížíte na 5, mnohem více markerů zůstane ve shlucích, takže mapa zůstane přehlednější a „seskupená“ až do momentu, kdy přiblížíte ještě víc.

Ukázkové video ke Clusteringu v GeoMap

Vizuální indikátor zděděného tagu

Zabbix teď dělá ze zděděných tagů plnohodnotnou součást UI, takže na první pohled poznáte, jestli tag pochází ze šablony / nadřazeného objektu, nebo jestli byl vytvořen přímo na aktuální úrovni. To je zvlášť praktické ve velkých prostředích, kde má mnoho objektů stejné názvy a spoléháte na tagy pro routování, filtrování a konzistentní klasifikaci napříč hosty, šablonami, položkami a triggery.

V seznamových pohledech jsou zděděné tagy označené malou ikonou stránky/dokumentu na levé straně „pilulky“ tagu a po najetí myší se zobrazí tooltip typu „Inherited tag“ (jak je zvýrazněno na screenshotu). Tagy bez této ikony nejsou zděděné – byly přidané přímo na dané úrovni. V příkladu níže je většina tagů zděděná, zatímco initMAX je nezděděný tag vytvořený lokálně, takže je rozdíl okamžitě vidět.

Vlastní tagy u triggerů z trigger prototypů

Tato funkce umožňuje přiřazovat vlastní tagy triggerům, které jsou vytvářené z trigger prototypů.

Je to obzvlášť užitečné pro řízení notifikací (odesílat / neodesílat upozornění podle tagů) a pro označování triggerů podle konkrétních služeb, týmů nebo případů použití. Díky tomu je možné přesnější směrování alertů, filtrování a korelace na úrovni služeb.

Možnost upravit tabulkové zobrazení u vybraných stránek

Tato funkce vám umožní přizpůsobit tabulky v seznamových přehledech na podporovaných stránkách pomocí nastavení sloupců v pravém horním rohu. Můžete zobrazit nebo skrýt celé sloupce a měnit jejich šířku; přejmenování je aktuálně dostupné pouze u duplicitních sloupců tagů (jak je vidět na screenshotu).

Kde je to dostupné:

• Monitoring → Hosté (Hosts)
• Monitoring → Nejnovější data (Latest data)
• Monitoring → Problémy (Problems)
• Sběr dat (Data collection) → Hosté (Hosts)
• Sběr dat (Data collection) → Šablony (Templates)

Všechny změny se ukládají do vašeho uživatelského profilu, takže rozložení je osobní a nesdílí se s ostatními uživateli. Zároveň plánujeme aktualizovat i náš User Filter Manager, aby tuto funkcionalitu také podporoval: https://www.initmax.com/product/user-filter-manager/

Na druhém screenshotu můžete vidět příklad duplicitního sloupce „Tags“, kde je možné použít filtrování a zároveň tento duplicitní sloupec s tagy také přejmenovat. Je to opravdu super funkce, která výrazně usnadňuje udržet pohledy s velkým množstvím tagů přehledné a zaměřené jen na to podstatné.

Here’s a short video showing how you can resize columns and hide them in the Triggers view.

Tady je krátké video, které ukazuje, jak můžete v přehledu Triggers měnit šířku sloupců a skrývat je.

Ukládání SAML certifikátů přímo do databáze

Nově můžete nastavit ukládání SAML certifikátů přímo do databáze Zabbixu. Stačí v konfiguračním souboru (nejčastěji /etc/zabbix/web/zabbix.conf.php) frontendu nastavit:

$SSO['CERT_STORAGE'] = 'database';

Díky tomu již nemusíte nahrávat certifikáty přímo na souborový systém serveru. Toto řešení přináší řadu výhod, zejména:

• Snadnou konfiguraci přímo z webového rozhraní,
• Jednotnou správu certifikátů v případě nasazení v režimu High Availability (HA),
• Zjednodušení administrace celého SAML nastavení.

Přehled drobných vylepšení

Audit log export do CSV

Audit log dostává CSV export. Je to menší změna, ale v praxi velmi užitečná. U větších instalací se auditní záznamy často předávají mimo Zabbix, archivují se, porovnávají nebo se používají při kontrole změn. Přímý export snižuje potřebu ručního kopírování nebo dodatečných skriptů.

Bezpečnější výchozí nastavení pro trapper itemy

Zabbix doplňuje výchozí hodnotu pro Allowed hosts u trapper itemů a přidává globální makro {$TRAPPER.ALLOWED_HOSTS}. To pomůže hlavně u šablon, importů a hromadné správy, kde je lepší mít jednotný a snadno upravitelný výchozí režim místo ručního doplňování na mnoha místech.

Nové a aktualizované šablony

Nové šablony:

• OpenAI Platform by HTTP
• GitHub organization by HTTP
• Ribbon SBC Edge by HTTP
• Ribbon SBC SWe core by HTTP
• Ribbon SBC SWe CE by HTTP
• VeloCloud SD-WAN Edge by HTTP 

Aktualizované šablony:

• Proxmox VE by HTTP (nested LLD; mapování SMART statusu)
• GitHub repository by HTTP
• Microsoft 365 reports by HTTP (monitoring Copilotu)
• Ciena 3906 by SNMP (přidané položky pro filesystem a CPU load)
• MySQL šablony (podpora nové syntaxe)
• RabbitMQ šablony (oprava regexu pro HTTP response code u healthchecku)
• Nextcloud by HTTP (logika itemů)
• NetApp AFF A700 by HTTP (změna názvů maker)
• MSSQL šablony (doplněné GRANTy)
• Stormshield SNS by SNMP (oprava OID pro „protected host memory“)
• Zabbix server/proxy health šablony (oprava zpracování chyb u ODBC polleru)

Zabbix ke stažení a další užitečné odkazy

• Zabbix 8.0 je ke stažení zde: www.zabbix.com/download
• Kompletní dokumentaci k nové verzi najdete zde: https://www.zabbix.com/documentation/8.0/en/manual/introduction/whatsnew800

Jako oficiální partneři a velcí fanoušci Zabbix platformy jsme schopni Vám poskytnout služby ze všech oblastí Zabbix monitoringu na té nejvyšší úrovni. Pokud by vás zajímala živá ukázka instalací Zabbixu u našich zákazníků, rádi vám ukážeme Zabbix v praxi.