Nový Zabbix 8.0 LTS je zde!

Verze Zabbix 8.0 je zde!

Nová verze Zabbix 8.0 LTS přináší řadu zajímavých novinek. Mezi největší patří APM s OpenTelemetry a nový korelační engine CEP. Změny se týkají také monitoringu, uživatelského rozhraní a zabezpečení. Níže najdete přehled hlavních funkcí a jejich praktického využití.

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. Ve stejném seznamu jsou vedle nových CEP pravidel i původní event correlation pravidla, filtr Type je umí oddělit. Sloupec Info ukazuje chybu pravidla za běhu a tlačítko Reset time windows zahodí rozpracovaná časová okna po změně pravidla.

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 Event name, Tag name, Tag value, Severity, Host, Host group a nově také Time period. Tag name a Tag value jsou samostatné podmínky s operátory Equals, Does not equal, Contains a Does not contain, u severity je k dispozici Is more than or equal. 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ů.
  • Pattern match vyhodnocuje vzor událostí. Vzor se popisuje JavaScriptem v poli Script, který má přístup k eventům v okně.
• 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. V poli lze použít i uživatelské makro.
• Capacity omezuje počet eventů v okně. Přepínač Unlimited / Limited a číslo nebo makro určuje, kolik eventů se v okně drží. Po dosažení limitu je nejstarší event z okna vyřazen. Na takovou situaci pak mohou navazovat operace spouštěné při Event evicted, například změna severity nebo doplnění tagu.
• Group by říká, jak se eventy uvnitř okna rozdělí do skupin. Jsou to tři nezávislé checkboxy Host group, Host a Tag, které jde kombinovat, a u tagů lze zadat více názvů najednou, například lokalitu a službu. U tagů je potřeba počítat s přesným názvem včetně velikosti písmen. U režimu Cause and symptoms grouping není Group by povinné.
• 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 after this rule 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, při shodě rozhoduje název pravidla, takže spolu se Stop after this rule 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 (Execute when) a na které eventy se má vztahovat. Výběr eventů řeší vlastní blok Conditions se stejnou logikou jako u pravidla: And/Or nebo Custom expression a podmínky typu Tag name, Tag value, Problem is opened, Problem is symptom, First event in time window, Last event in time window, Problem is suppressed a Event is cloned. Stejná CEP logika tak může nad příčinou, symptomy nebo jen nad prvním eventem v okně 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 added to window nastane až ve chvíli, kdy je event skutečně zařazen do časového okna. Od Event occurred se liší tím, že už jde použít podmínky First event in time window a Last event in time window.
• 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ů.
• Pattern matched patří k režimu Pattern match, kde se vyhodnocuje vzor událostí skriptem. 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ů.

Spouštěče mají pevné pořadí Event occurred > Event added to window > Event evicted > Window closed > Pattern matched a operace v pravidle musí být takto seřazené. Které spouštěče jsou k dispozici, závisí na typu okna: u None je jen Event occurred, Pattern matched je jen u Pattern match. Podle spouštěče se mění i nabídka operací, například Discard jde použít jen při Event occurred a Pattern matched.

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 name přepíše název eventu, v hodnotě fungují makra. 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. Nastavuje se buď Duration, nebo Indefinitely. Opačná operace Unsuppress potlačení zruší. Potlačení se zapisuje do historie eventu jako CEP akce.
• 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.
• Clone first a Clone last vytvoří kopii první nebo poslední události v okně. Jsou k dispozici při Event evicted, Window closed a Pattern matched a dávají smysl tam, kde chcete z nasbírané skupiny vyrobit jeden souhrnný event.
• Close (window) uzavře celé časové okno předčasně. Hodí se v Pattern match scénářích, kdy je vzor nalezen a není důvod čekat na vypršení Duration.
• U režimu Cause and symptoms grouping Zabbix sám označí první event v okně jako příčinu a ostatní jako symptomy; v detailu eventu je pak vidět akce Set as symptom s odkazem na CEP pravidlo.

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

Z provozního pohledu: časová okna se ukládají do databáze a přežijí restart serveru, CEP má vlastní workery s interním itemem pro statistiky a sekcí v diaginfo, a v API přibylo cep_ruleid ve výstupu event.get a problem.get. Změny provedené CEP se ukazují v historii eventu jako samostatný typ akce.

Původní global event correlation pravidla v rozhraní zůstávají a dál je lze používat. V části Event processing je od CEP odděluje typ Event correlation. Nový CEP přidává časová okna a širší možnosti zpracování; stávající pravidla se na něj automaticky nepřevádějí.

Mobilní aplikace Zabbix a push notifikace

Zabbix 8.0 přináší oficiální mobilní aplikaci a k ní nový typ media type Push. Notifikace o problémech tak chodí přímo do telefonu, bez e-mailu, SMS brány nebo webhooku třetí strany. Na straně serveru je to nová infrastruktura: správa spárovaných zařízení, oprávnění v user roles a šifrovaný kanál mezi serverem a aplikací.

Jak to funguje

Zabbix server neposílá push zprávy přímo. Mezi serverem a mobilní platformou stojí Bridge Adapter, samostatná služba s JSON-RPC rozhraním přes HTTP(S), na kterou se server obrací při párování zařízení (device.init) i při každé notifikaci (device.notify). Server jí předává události problem.created, problem.updated a problem.resolved včetně severity, priority, titulku a těla zprávy.

Mobilní aplikace Zabbix Mobile App je samostatný klient pro iOS a Android, nikoli součást webového frontendu nebo balíčku Zabbix serveru. Párování zařízení, jejich oprávnění a push média se nastavují v Zabbixu; samotný mobilní klient a dostupný Bridge Adapter jsou další části řešení. Informace o aplikaci najdete na oficiální stránce Zabbix Mobile App.

Bridge Adapter není součástí instalace Zabbix serveru. Server se k němu připojuje přes nastavenou URL; jeho implementace není součástí zdrojových kódů serveru. Pro mobilní notifikace proto potřebujete dostupný adapter a funkční propojení se serverem. Samotná instalace serveru push notifikace nezprovozní.

Obsah notifikace je šifrovaný pro konkrétní zařízení. Každý telefon má při párování vygenerovaný vlastní šifrovací klíč, bridge adapter vidí jen zašifrovaný payload a nevidí text problému. Přihlašování aplikace k API používá DPoP tokeny (proof-of-possession, podpis ES256) s ochranou proti opakovanému použití, takže odcizený token bez klíče zařízení nejde zneužít.

Konfigurace serveru

Celá funkce je ve výchozím stavu vypnutá. Zapíná se v zabbix_server.conf:

EnableMobileDevices=1
BridgeAdapterURL=https://bridge-adapter.example.com:10005/rpc
# volitelně: připojit se jinam, než říká URL (např. přes tunel)
BridgeAdapterConnectTo=127.0.0.1:10054

Dokud je EnableMobileDevices=0, položky Devices se ve frontendu vůbec nezobrazí a API metody device.* nejsou dostupné. Bez dostupného bridge adapteru párování skončí chybou Cannot initialize mobile device, cannot connect to bridge-adapter.

Párování zařízení

Uživatel si telefon přidá sám v User settings > Devices > Add device. Frontend vygeneruje QR kód s platností 10 minut (odpočet běží přímo v dialogu), aplikace ho naskenuje a zařízení se po dokončení objeví v seznamu jako Active. Žádné ruční opisování adres serveru nebo API tokenů.

QR kód je deep link zabbix://v1/link_device a nese vše, co aplikace k párování potřebuje: identifikátor a název Zabbix serveru, ID zařízení, adresu bridge adapteru, dva jednorázové enrollment tokeny (pro Zabbix a pro bridge) a veřejný klíč adapteru. Identifikátor serveru je nová Zabbix server ID viditelná v System information, takže aplikace umí rozlišit více Zabbixů.

Administrátor má přehled všech zařízení v Users > Devices: název, Device ID, uživatel, role, kdy bylo spárováno a kdy bylo naposledy aktivní. Stavy jsou New (zahájené párování), Active a Unassigned. Zařízení lze filtrovat podle uživatele, role nebo skupiny a odebrat; administrátor může párování zahájit i za jiného uživatele.

Oprávnění

V user roles přibyla samostatná sekce Devices: zapnutí funkce pro roli, akce Manage own devices a Manage user devices a výchozí přístup k nově přidaným akcím. Vedle toho je v UI elementech nová položka Users > Devices. Lze tak například povolit push notifikace všem, ale správu cizích zařízení nechat jen helpdesku.

Media type Push

Nový typ media type Push stojí vedle Email, SMS, Script a Webhook. Formulář je minimální: název, typ a popis, k tomu indikátor Bridge adapter connection, který rovnou ukáže, jestli server adapter má nakonfigurovaný. Výchozí šablony zpráv pro problém, recovery a update vypadají například {HOST.NAME} - {EVENT.NAME} a [RESOLVED] {HOST.NAME} - {EVENT.NAME}, makra fungují jako u ostatních typů.

U uživatele se pak médium nastavuje jako obvykle, jen Send to není adresa, ale volba Active devices (všechna aktivní zařízení uživatele) nebo Selected devices. Akce a eskalace se konfigurují stejně jako u jiných media typů, push je jen další krok v eskalaci.

Co to znamená v praxi

Menší týmy mohou využít push notifikace na mobil namísto placené SMS brány. Pro větší prostředí je důležité, že párování je samoobslužné, zařízení jsou centrálně vidět a dají se odebrat, a že obsah notifikací neopouští Zabbix v čitelné podobě. Při nasazení ověřte párování zařízení i doručení skutečné notifikace.

Nový vzhled: téma Dark blue, písmo Inter a zaoblené rozhraní

Zabbix 8.0 je první verze po dlouhé době, která mění nejen funkce, ale i to, jak rozhraní vypadá. Změny jsou tři: nové barevné téma Dark blue, nové písmo vložené přímo do frontendu a modernizované komponenty se zaoblenými rohy a lepší přístupností. Nic z toho nemění rozložení stránek, administrátor se orientuje stejně jako v 7.x.

Téma Dark blue

Vedle stávajícího Dark přibývá Dark blue: tmavě modrý podklad (#001F42), modré akcenty (#004FA8) a světlý text, navržené tak, aby na velkých obrazovkách v dohledovém centru neoslňovalo, ale zůstalo čitelnější než čistě černé téma. Má vlastní paletu i pro klasické grafy, takže barvy křivek sedí s pozadím.

Vlastní písmo místo systémového

Frontend nově nese vlastní písmo Inter (variabilní font, včetně kurzívy) a pro japonštinu, korejštinu, čínštinu, gruzínštinu a hebrejštinu Noto Sans. Zabbix tak vypadá stejně na Windows, macOS i Linuxu a nezávisí na tom, jaké fonty má prohlížeč k dispozici. Spolu s tím prošly úpravou formuláře, kde delší texty dřív přetékaly (grafový widget, preprocessing, setup wizard).

Kdo chce zůstat u původního vzhledu, má k dispozici témata Blue (classic) a Dark (classic) s dosavadní sadou písem. Seznam témat je tedy: Blue, Blue (classic), Dark, Dark (classic), High-contrast light, High-contrast dark a nově Dark blue.

Modernizované rozhraní

Vstupní pole, tlačítka, tabulky, filtry, záložky i dashboardové widgety dostaly jednotné zaoblení rohů a upravené okraje. Na první pohled drobnost, v součtu ale rozhraní působí lehčeji a jednotněji. Srovnání stejné obrazovky v 7.4 a 8.0:

Druhá část modernizace je přístupnost: odkaz Skip to main content pro ovládání z klávesnice (objeví se po stisku Tab), lepší zvýraznění fokusu a opravené kontrasty. Vybraná textová pole se navíc automaticky zvětšují podle obsahu (názvy, výrazy, popisy), takže se dlouhé hodnoty nemusí procházet v jednořádkovém políčku.

Drobnosti, které s tím souvisí: tooltipy a hintboxy jdou přetáhnout myší jinam, když překrývají to, co potřebujete vidět; automatické spouštění slideshow dashboardů je nově vypnuté a ovládá se parametrem v URL; a většina konfiguračních formulářů běží v modálních oknech s inline validací, takže chyba se ukáže rovnou u pole, ne až po uložení.

Co to znamená v praxi

Pro uživatele je to hlavně jistota, že Zabbix vypadá všude stejně a že se s ním dá pohodlně pracovat i z klávesnice. Pro firmy, které mají vlastní branding frontendu (logo, barvy přes brand.conf.php), se nic nemění, mechanismus zůstává. Pokud máte vlastní moduly nebo widgety s vlastním CSS, počítejte s kontrolou na nových tématech, hlavně na Dark blue a classic variantách.

APM a OpenTelemetry: traces, metriky a logy přímo v Zabbixu

Největší architektonická novinka 8.0 se dá shrnout jednou větou: Zabbix začíná přijímat OpenTelemetry data. Aplikace instrumentované OpenTelemetry SDK nebo OpenTelemetry Collector posílají traces, metriky a logy do Zabbix proxy, která zajišťuje vestavěný příjem OTLP/gRPC a ukládá data do ClickHouse. Zabbix server vlastní OTLP collector nemá: uložená data čte pomocí položek Telemetry query a vytváří z nich hodnoty pro triggery, grafy a upozornění. Frontend data prohlíží v pohledech Traces, Metrics a Logs. Zabbix tím vstupuje do oblasti APM (Application Performance Monitoring), kde dosud bylo potřeba sáhnout po Jaegeru, Tempu nebo komerčních nástrojích.

Proxy je tedy potřeba pro vestavěný příjem OTLP, nikoli pro samotné čtení telemetrie serverem. Může běžet na stejném stroji jako Zabbix server; samostatný server nebo virtuální stroj není podmínkou. Pokud data do kompatibilních telemetrických tabulek ClickHouse zapisuje jiný collector, Zabbix server je může číst i bez sběru přes Zabbix proxy. Položky Telemetry query umí vykonávat i proxy.

Trace zachycuje průchod jednoho požadavku aplikací. Skládá se ze spanů, tedy jednotlivých operací, například zpracování HTTP požadavku, dotazu do databáze nebo volání platební brány. Společné Trace ID a vazby mezi rodičovskými a podřízenými spany spojují tyto operace do jednoho průchodu. Aby se data sbírala, aplikace musí používat OpenTelemetry instrumentaci nebo jiný zdroj OTLP dat; samotná instalace Zabbixu trace nevytvoří.

Skládá se to ze tří částí, které dohromady tvoří jeden řetězec:

• Sběr: OTLP/gRPC collector v Zabbix proxy (výchozí port 4317).
• Prohlížení: nová sekce hlavního menu APM s pohledy Traces, Metrics a Logs nad globálním APM datovým zdrojem.
• Zpracování: nový typ itemu Telemetry query, který z telemetrických dat dělá hodnoty pro triggery, grafy a dashboardy.

Sběr: OpenTelemetry collector v Zabbix proxy

Vestavěný příjem OpenTelemetry dat zajišťuje výhradně proxy. Zabbix server žádný collector nemá a v zabbix_server.conf pro něj nejsou žádné volby; i v prostředí, kde jste dosud proxy nepotřebovali, tedy pro vestavěný sběr jednu nasadíte. Proxy dostává nový proces APM collector s OTLP/gRPC rozhraním a zapisuje přijatá data do ClickHouse. APM úložiště a volitelný ClickHouse backend pro běžnou historii položek jsou přitom dvě samostatná nastavení. Konfigurace je v zabbix_proxy.conf:

StartAPMCollectors=1
APMListenIP=0.0.0.0
APMListenPort=4317
TelemetryProvider=clickhouse;url=http://clickhouse:8123,db=zabbix,username=zabbix,password=zabbix
# TLS pro OTLP klienty: APMTLSCAFile, APMTLSCertFile, APMTLSKeyFile

Heslo k ClickHouse jde uložit do HashiCorp Vaultu (vault_path=), stejně jako u databáze serveru. Pro sběr potřebujete proxy s podporou APM. U hotového balíčku s touto podporou se nic dodatečně nekompiluje; collector zapnete konfigurací. Jen při vlastním sestavení ze zdrojů se podpora zapíná volbou --enable-proxy --with-apm a používá knihovny gRPC a protobuf. Podporu proto ověřte u konkrétního balíčku, nikoli pouze podle čísla verze proxy.

Vestavěný collector přijímá OTLP/gRPC, standardně na portu 4317. OTLP/HTTP na portu 4318 není jeho druhé rozhraní: exporter musí používat gRPC, případně mezi aplikaci a proxy zařadíte OpenTelemetry Collector, který data předá podporovaným protokolem.

APM nastavení proxy ve frontendu

Vedle konfigurace collectoru přibývá ve formuláři proxy nová záložka APM. Zde se povoluje příjem dat, nastavuje limit exportních zpráv a doplňují atributy prostředí či lokality. Nastavení má dvě části, Input a Process:

Ve frontendu má proxy nový tab APM rozdělený na dvě části. Input: přepínač Data collection enabled a limit Max messages per second (Unlimited / Custom), aby jedna upovídaná aplikace nezahltila úložiště. Process: tabulka Add resource attributes, tedy atributy, které proxy doplní ke všem přijatým datům (například prostředí nebo lokalita), aniž by se musely nastavovat v každé aplikaci. Pokud proxy nemá collector v konfiguračním souboru zapnutý, frontend na to upozorní přímo ve formuláři.

Max messages per second omezuje exportní zprávy, ne počet spanů uvnitř zprávy. Po překročení limitu collector požadavek odmítne; opakování pak závisí na exporteru. Povolení sběru v této záložce a spuštění collectoru v konfiguraci proxy jsou dvě samostatné podmínky.

Prohlížení: Traces, Metrics a Logs

V hlavním menu přibývá hned pod Monitoring nová sekce APM se třemi pohledy. Traces filtruje podle Trace ID, Span ID, názvu služby a operace, scope, délky trvání (min/max), stavu (Ok / Error / Unset) a libovolných atributů s logikou And/Or a vypisuje celé traces s počtem spanů, chybami, časem startu a dobou trvání. Na snímcích níže je seznam traces modelového nákupu itemMAX PRO na webu initMAX a stejný pohled zúžený na pomalá volání platební brány. Logs hledá v těle záznamu, podle severity (Trace až Fatal) a atributů a přes Trace ID / Span ID propojí log se související trace. Metrics filtruje metriky podle názvu, typu, služby a scope. Všechny tři pohledy používají stejný časový výběr jako zbytek Zabbixu.

Ukázka vychází z našich služeb: itemMAX na webu initMAX, e-shopu a portálu initMAX. Modelový požadavek propojuje přípravu objednávky, ověření produktu v katalogu portálu a testovací platbu. Jde o simulovaná OpenTelemetry data, nikoli záznam skutečného nákupu, výpadku nebo přesný popis produkční architektury.

Filtr služby hledá i uvnitř trace, seznam ale ukazuje celý požadavek. Proto při filtru Service name = Payment provider (demo) a Min. duration = 1s vidíte řádky služby initMAX web: právě tam modelový požadavek začal. Číslo 6 označuje počet spanů v trace, červené 4 počet chybových spanů. Detail ukáže, kde čekání na testovací platební službu prodloužilo nákup itemMAX PRO.

Detail trace: strom spanů a časová osa

V APM > Traces lze otevřít i detail celého trace. Místo samostatných řádků dostanete strom spanů a waterfall časovou osu: vlevo vidíte návaznost operací, vpravo jejich začátek a délku. Rozbalením větve se dostanete k podřízeným voláním a výběrem rozsahu na časové ose se zaměříte na konkrétní část požadavku.

• Span tree zobrazuje vztahy rodičovských a podřízených operací. Jeden požadavek tak můžete sledovat napříč službami, pokud instrumentace předává trace kontext.
• Waterfall ukazuje, které operace běžely za sebou a které současně. Délky všech spanů proto nelze jednoduše sečíst jako celkovou dobu požadavku.
• Span details obsahuje název operace, službu, scope, čas a délku spanu. Dále ukazuje resource a span attributes a případné události zaznamenané uvnitř spanu.

Ve vybraném spanu Payment provider (demo) / Authorize payment (demo) je kromě délky volání vidět HTTP stav 502 a událost payment.timeout. Resource attributes popisují službu a prostředí, například deployment.environment.name=demo a lokalitu nyc. Span attributes patří konkrétní operaci: zde produkt itemMAX, edice PRO a testovací objednávka. Events doplňují události uvnitř spanu, zde TimeoutError, retry.count=2 a gateway=demo-provider. Tyto údaje dodává instrumentace, Zabbix je z délky požadavku neodvozuje.

U pomalého checkoutu nejprve vyfiltrujete službu a delší trvání. V detailu trace pak zjistíte, zda většinu času zabral dotaz do databáze, čekání na platební bránu, nebo vlastní zpracování aplikace. Atributy a události vybraného spanu doplní konkrétní kontext chyby; samotná časová osa příčinu neurčí automaticky.

V APM > Logs stejným Trace ID dohledáte zprávu testovací platební služby: DEMO: itemMAX PRO payment timeout; order returned HTTP 502. Filtr propojí konkrétní průchod webem a e-shopem s jeho aplikačním logem. Severity, tělo zprávy a atributy pomáhají upřesnit, co během požadavku nastalo.

Pohled APM > Metrics doplňuje provozní kontext. Metrika eshop.checkout.queue.depth typu Gauge udává počet čekajících objednávek; vedle ní jsou modelové metriky aktivních požadavků na produktové stránky a stahování z portálu. Na rozdíl od trace popisují stav služby v čase, ne cestu jednoho požadavku. Název metriky, služba a atributy umožní vybrat správnou časovou řadu.

Datový zdroj APM: připojení k telemetrii v ClickHouse

Pohledy čtou z globálního APM datového zdroje, který se nastavuje v Administration > Data source > APM: typ databáze (ClickHouse), URL, přihlášení (jméno a heslo, nebo bez autentizace), název databáze a u HTTPS ověření certifikátu a hostname. Je to stejný ClickHouse, do kterého zapisuje proxy, jen z pohledu frontendu; data jsou ve standardních tabulkách OpenTelemetry ClickHouse exporteru (otel_traces, otel_logs a otel_metrics_*), takže se dají číst i jinými nástroji.

Datový zdroj ve frontendu nenahrazuje TelemetryProvider v konfiguraci serveru nebo proxy. Frontend jej používá k prohlížení dat, server a proxy k vykonávání položek Telemetry query. Všechny části proto musí mít přístup ke správné telemetrické databázi. Tabulky history* z ClickHouse history backendu telemetrické tabulky nenahrazují.

Toto je nastavení ClickHouse pro APM, nikoli backend běžné historie položek. History backend popisujeme samostatně v kapitole ClickHouse backend a výrazná vylepšení pro Elastic. Oba způsoby mohou využívat stejný databázový cluster, ale mají vlastní konfiguraci a jiné tabulky.

Zpracování: item typu Telemetry query

Nový typ itemu Telemetry query spojuje svět OpenTelemetry s klasickým Zabbixem. Vedle klíče položky se skládá dotaz: kategorie (Traces, Metrics, Logs), u metrik jejich typ (Sum, Gauge, Histogram nebo Exponential histogram), sloupce, které se mají číst, agregované sloupce s funkcí a aliasem a podmínky nad atributy s logikou And/Or nebo vlastním výrazem. Tři časové parametry určují, jak se dotaz vyhodnocuje: Granularity (velikost agregačního bucketu), Time shift (posun okna zpět) a Lookback limit (jak daleko do minulosti dohánět dosud nezpracované intervaly).

Výsledek je obyčejná hodnota itemu, takže nad ní fungují triggery, grafy, dashboardy i eskalace. Typický příklad: 95. percentil doby odpovědi služby initMAX e-shop v minutových intervalech jako numerický item s triggerem na překročení 800 ms. Zabbix server (nebo proxy) k tomu potřebuje vlastní TelemetryProvider v konfiguraci a pro tyto dotazy má samostatný timeout timeout_telemetry_query.

• Granularity je velikost agregačního intervalu. Hodnota 1m dává minutové výsledky, i když se položka kontroluje každých 30s.
• Time shift posouvá vyhodnocovaný interval do minulosti. Například 15s nechá prostor datům, která do ClickHouse dorazí s krátkým zpožděním.
• Lookback limit určuje, jak hluboko do minulosti se dohánějí dosud nezpracované intervaly. Není to retence dat v ClickHouse.

Dotazy vykonávají samostatné procesy řízené parametrem StartTelemetryQueryPollers. Jejich vytížení lze sledovat stejně jako u dalších procesů Zabbixu.

Granularity sama nezaručuje kompletní uzavřený interval. Když je interval kontroly kratší než granularita, vyhodnocovaná okna se mohou překrývat; formulář na to upozorňuje. Příliš krátký Time shift navíc může zahrnout jen část dat, která už do úložiště dorazila. U počtů a percentilů proto nastavte časování podle skutečného zpoždění sběru, ne jen podle požadované rychlosti grafu.

Ukázka: od traces k triggeru

Vyzkoušeli jsme celý řetězec na modelovém nákupu itemMAX PRO: data procházejí OTLP/gRPC collectorem Zabbix proxy do ClickHouse a server nad nimi počítá položky Telemetry query. Pro p95 přípravy objednávky zvolíme kategorii Traces, agregace percentile(Duration, 95), avg(Duration) a count a podmínky ServiceName equals initMAX e-shop a SpanName equals Prepare itemMAX PRO order. Granularita i interval kontroly jsou 1m, Time shift je 2m, aby zůstala rezerva pro data přicházející v exportních dávkách. Další spany stejné služby se tak do latence ani počtu objednávek nepletou.

Server dotaz přeloží do ClickHouse SQL a vrátí výsledek za agregační interval jako JSON, například {"columns": {"p95": 1438000000, "avg": 1386000000, "cnt": 29}}. Duration je v nanosekundách. Preprocessing JSONPath $.columns.p95 a Custom multiplier 1.0E-6 převedou p95 na milisekundy; položka pak používá jednotku ms. Stejným způsobem získáme průměrnou latenci, počet objednávek, p95 testovací platební služby a počet chybových objednávek.

Samotný count nad traces počítá spany, ne automaticky unikátní objednávky. Služba initMAX e-shop má v jednom průchodu tři spany. Proto v příkladu vybíráme také SpanName equals Prepare itemMAX PRO order, tedy právě jeden span přípravy objednávky. Pro chyby přidáme StatusCode equals Error. Bez podmínky na operaci by se do počtu zahrnula i interní volání katalogu a platební služby.

Nad itemy fungují triggery jako u čehokoli jiného: last(/initMAX digital experience demo/apm.eshop.latency.p95)>800 hlídá p95 latenci přípravy objednávky, last(/initMAX digital experience demo/apm.eshop.errors)>=3 počet chybových objednávek v minutovém intervalu. Když v modelovém provozu zpomalí testovací platební služba, objeví se zvýšená latence v grafu a problém v Problems s tagem service=initMAX e-shop. Konkrétní požadavek pak dohledáte v APM > Traces podle času, služby nebo Trace ID. Samotný tag problému automatický odkaz na konkrétní trace nevytváří.

Co to znamená v praxi

Pro týmy, které už mají aplikace instrumentované OpenTelemetry, znamená 8.0 možnost mít infrastrukturní monitoring a APM v jednom nástroji, se stejnými uživateli, oprávněními a notifikacemi. Počítejte s tím, že to přináší nový stavební kámen pro APM, ClickHouse, a s tím i nároky na disk a provoz. Rozumný začátek je jedna proxy s collectorem pro jedno prostředí a několik Telemetry query itemů na klíčové služby; pohledy Traces a Logs pak slouží k dohledání příčiny, když se trigger aktivuje.

ClickHouse není povinný pro celý Zabbix, ale pro tuto telemetrickou část. Při nasazení sledujte objem traces, metrik a logů, nastavte jejich retenci a ověřte vytížení Telemetry query pollerů. Citlivé údaje v atributech je vhodné omezit už v instrumentaci nebo v OpenTelemetry Collectoru.

ClickHouse pro produkční APM navrhněte předem, včetně vysoké dostupnosti. Proxy do něj zapisuje a server, případně proxy, i frontend z něj čtou; výpadek úložiště tak zasáhne sběr, dotazy i prohlížení. U kritického provozu počítejte s replikovanými tabulkami, dostupnou koordinační službou ClickHouse Keeper a stabilním přístupovým bodem s přepnutím při výpadku. Samotné spuštění dvou databázových uzlů HA nezajistí.

Předem navrhněte také síťové prostupy, TLS, oprávnění a kapacitu. Aplikace nebo OpenTelemetry Collector potřebují přístup k proxy přes OTLP/gRPC (standardně TCP 4317); proxy, server a frontend potřebují své HTTP(S) spojení do ClickHouse. Přidejte interní komunikaci replik a Keeperu, zálohy, retenci a ověření chování při výpadku. Vysoká dostupnost sama o sobě není záloha ani záruka nulové ztráty telemetrie; záleží také na nastavení zápisů, replikace a front exportérů.

Bezpečnost a řízení: Vault AppRole, feature flags, API vypnuté ve výchozím stavu

Zabbix 8.0 přináší několik změn, které nejsou vidět na dashboardu, ale zajímají každého, kdo Zabbix provozuje pro víc týmů nebo zákazníků: bezpečnější výchozí nastavení (API vypnuté v rolích, žádné staré protokoly na trapperu), lepší práci se secrets (HashiCorp Vault AppRole) a nástroje, jak instalaci osekat na to, co administrátor opravdu chce povolit (feature flags, regulární výrazy pro klíče agentů, omezení uživatelů na konkrétní proxy).

HashiCorp Vault: AppRole místo tokenu

Přihlášení do HashiCorp Vaultu dosud vyžadovalo statický token v konfiguraci serveru i frontendu. 8.0 přidává AppRole: server dostane VaultAppRoleID a VaultAppSecretID, frontend $DB['VAULT_APP_ROLE_ID'] a $DB['VAULT_APP_SECRET_ID'], a token si vyžádá sám. Pro bezpečnostní tým to znamená standardní způsob, jak Zabbixu vydat identitu s omezenou politikou a rotovat secret ID, místo dlouhodobě platného tokenu v souboru.

### zabbix_server.conf
Vault=HashiCorp
VaultURL=https://vault.example.com:8200
VaultDBPath=secret/zabbix/db
VaultAppRoleID=8a1c2f7e-0b3d-4c5e-9f10-1a2b3c4d5e6f
VaultAppSecretID=...

Instalační průvodce frontendu má v kroku Configure DB connection nový přepínač Vault authentication type: Token / AppRole. Stejná volba platí i pro heslo k ClickHouse u APM datového zdroje (vault_path= v TelemetryProvider).

API vypnuté ve výchozím stavu

Nové uživatelské role mají Access to API vypnutý, včetně typu Super admin. Integrace, skripty nebo náš Zabbix MCP server potřebují API v roli výslovně povolit. Prázdný allow list nově nepovoluje žádnou API metodu. Když zvolíte režim allow list, musíte přidat potřebné metody; pouhé zapnutí API nestačí. Existující role si při upgradu zachovají nastavení přístupu k API, ale nová logika prázdného allow listu se týká i jich. Před upgradem proto zkontrolujte obě části oprávnění.

Feature flags: systémové omezení funkcí frontendu

Do zabbix.conf.php přibývá pole $ZBX_FEATURE_FLAGS, kterým se na úrovni systému vypnou celé funkce frontendu, bez ohledu na oprávnění uživatelů:

$ZBX_FEATURE_FLAGS['modules_config_enabled'] = false;   // blokuje správu, aktivní moduly zůstávají
$ZBX_FEATURE_FLAGS['http_auth_enabled'] = false;        // zákaz HTTP autentizace
$ZBX_FEATURE_FLAGS['media_type_denylist'] = ['script', 'webhook'];  // zákaz editace vybraných media typů
$ZBX_FEATURE_FLAGS['banners_enabled'] = false;          // bez informačních bannerů

modules_config_enabled=false skryje stránku Modules a zablokuje správu modulů přes frontend a příslušné API metody. Není to automatické odinstalování ani vypnutí již aktivních modulů. Jejich načítání běží samostatně podle uloženého stavu a oprávnění. Podobně media_type_denylist omezuje editaci vybraných typů médií, nikoli samotné odesílání již nastavených notifikací. Provozovatel tak může centrálně omezit změny konfigurace i pro administrátory.

Ostatní přepínače nemají stejný význam: http_auth_enabled=false vypne samotnou HTTP autentizaci, nejde jen o skrytí jejího nastavení. banners_enabled=false vypne informační bannery. Rozlišujte proto omezení správy konfigurace od vypnutí konkrétní funkce.

Trapper bez starých protokolů a regulární výrazy pro klíče agentů

Trapper serveru a proxy už nepřijímá legacy textové a XML protokoly používané před Zabbixem 1.6. Nejde tedy obecně o všechny verze před 4.x. Před upgradem prověřte velmi staré agenty a vlastní sendery používající tyto historické formáty a nahraďte je podporovaným klientem nebo aktuálním Zabbix protokolem.

Minimální kompatibilní verze klasického Zabbix agenta se tím posouvá z 1.4 na 1.6. Nejde o změnu minima agenta 2, který je podporovaný od řady 4.4.

V konfiguraci agenta (i agenta 2) přibývají AllowKeyRegexp a DenyKeyRegexp. Dosud šlo klíče povolovat jen zástupnými znaky, teď jde napsat pravidlo jako PCRE2 výraz, který musí odpovídat celému klíči. Všechna pravidla AllowKey, DenyKey, AllowKeyRegexp a DenyKeyRegexp se skládají do jednoho seznamu v pořadí, v jakém jsou v souboru, a rozhoduje první shoda:

AllowKeyRegexp=^vfs\.fs\.(size|inode)\[/(var|opt)(/[^,]*)?,.*\]$
DenyKey=system.run[*]

Omezení uživatelů na konkrétní proxy

Pro poskytovatele služeb, kteří na jednom Zabbixu obsluhují více zákazníků, je určený Proxy access list v uživatelské skupině: seznam proxy a proxy skupin (allow nebo deny), ke kterým smí uživatelé skupiny přiřazovat hosty a které vidí v discovery. Nově vytvořené skupiny mají výchozí režim allow list, takže bez explicitního povolení uživatel na cizí proxy nedosáhne; hosty monitorované nepřístupnou proxy vidí jako Inaccessible proxy.

Doplňuje je oprávnění uživatelské role Select „Server“ for monitoring and discovery. Určuje, zda uživatel může přiřazovat monitoring přímo serveru. V prostředí s více zákazníky tak můžete omezit nejen výběr proxy a proxy skupin, ale i možnost toto omezení obejít volbou serveru. Proxy access list neurčuje sám o sobě oprávnění ke všem hostům; ta se dál řídí přístupem ke skupinám hostů.

Identita serveru

Každý server má nově Zabbix server ID (UUID), zobrazené v System information spolu s tlačítkem Export, které vyexportuje přehled systému včetně HA uzlů. ID používá mobilní aplikace k rozlišení instancí a hodí se všude tam, kde se sbírají informace z více Zabbixů, například v supportu nebo v inventáři.

Co to znamená v praxi

Před upgradem projděte role a integrace, které API používají, a připravte allow listy metod. Zvažte přechod Vault tokenu na AppRole, u agentů převeďte složité AllowKey masky na regulární výrazy a v prostředích s více týmy nastavte feature flags a proxy access listy dřív, než uživatelé začnou instalaci osidlovat.

Údržby a suppression: ad-hoc údržba z problému, potlačení zapsané v události

Údržby v Zabbixu dosud znamenaly plánování: dopředu založit maintenance na skupinu hostů, nastavit okno a doufat, že nikdo nezapomene. Zabbix 8.0 přidává druhou cestu, ad-hoc údržbu spuštěnou přímo z problému na pár kliknutí, rozšiřuje cíle údržby o triggery a názvy událostí a hlavně zapisuje potlačení údržbou do historie události, takže otázka „proč mi nepřišla notifikace“ má konečně odpověď v UI.

Ad-hoc údržba přímo z Problems

Kontextové menu problému má novou sekci Maintenance se čtyřmi volbami: Suppress host, Suppress trigger, Suppress by event name a Suppress by tags. Každá otevře formulář údržby už předvyplněný podle vybraného problému: název Ad-hoc: název události, začátek teď, konec za výchozí periodu a jako cíl host, trigger, název události nebo tagy problému. Stačí zkontrolovat a uložit.

Stejný odkaz Suppress trigger je i v dialogu Update problem, a při hromadné aktualizaci více problémů se z něj stane Suppress triggers s odpovídajícím počtem triggerů. Délku okna určuje nové pole Default maintenance period v profilu uživatele (výchozí 1 hodina), takže operátor, který typicky řeší incidenty do 30 minut, si nastaví 30m a ad-hoc údržba se za něj nikdy nezapomene ukončit. Volby se zobrazí jen uživatelům, kteří mají v roli povolené vytváření údržeb a mají editační práva na daný host nebo trigger.

Údržba na trigger a na název události

Formulář údržby má vedle skupin a hostů nový cíl Triggers a novou podmínku Event name (Contains / Does not contain). Operátory tagů se rozšířily o Does not equal a Does not contain. Dá se tak potlačit jen jeden konkrétní trigger na hostu, u kterého se čeká na výměnu disku, a zbytek monitoringu nechat běžet, nebo potlačit všechny problémy s „certificate expires“ v názvu napříč hosty, dokud se nevyřídí obnova certifikátů. V API k tomu patří parametry triggerids a event_names u maintenance.create / maintenance.update a selectTriggers, selectEventNames u maintenance.get:

{
  "jsonrpc": "2.0",
  "method": "maintenance.create",
  "params": {
    "name": "Ad-hoc: certificate renewal",
    "active_since": 1788080400,
    "active_till": 1788084000,
    "groupids": ["2"],
    "event_names": [{"operator": 2, "value": "certificate expires"}],
    "timeperiods": [{"timeperiod_type": 0, "period": 3600}]
  },
  "id": 1
}

Potlačení údržbou je vidět v historii události

Doteď údržba problém tiše skryla a po jejím skončení nezbyla žádná stopa, proč konkrétní událost nevyvolala akci. Server v 8.0 zapisuje každé potlačení i odpotlačení údržbou jako záznam v historii události, spolu s údržbou, která ho způsobila, a časem, do kdy potlačení platilo. V Event details se objeví v sekci Actions jako ikona přeškrtnutého oka s nápovědou Suppressed till … / Maintenance: …, po skončení údržby přibude Unsuppressed by maintenance. Stejná informace je v API: event.get s selectAcknowledges vrací záznamy s action 512 (potlačeno) nebo 1024 (odpotlačeno), maintenanceid a suppress_until. Součástí změny je i přesnější zpracování překrývajících se údržeb a úprav běžící údržby.

Podmínka Proxy group v discovery a autoregistraci

Akce síťového discovery a autoregistrace mají nový typ podmínky Proxy group (equals / does not equal). Kdo provozuje proxy skupiny per lokalita nebo per zákazník, může teď napsat akci „hosty přihlášené přes skupinu DC Prague zařaď do skupiny Prague a přilinkuj šablonu X“ bez vyjmenovávání jednotlivých proxy, a při přidání proxy do skupiny se nic nemusí měnit. Zároveň byla opravena podmínka Proxy v autoregistraci tak, aby se chovala stejně jako v discovery.

Co to znamená v praxi

Nastavte uživatelům rozumnou Default maintenance period a naučte operátory používat Suppress trigger místo vypínání triggerů, které se pak zapomenou zapnout. Při auditu incidentů si zvykněte otevřít Event details: záznam o potlačení údržbou je nový zdroj pravdy pro otázku, proč se neposlal alert. A v prostředích s proxy skupinami přepište discovery a autoregistrační akce z výčtu proxy na podmínku Proxy group.

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é klíče agenta net.if.get a vfs.dev.get

Agent dostává dva nové klíče pro discovery: net.if.get vrátí síťová rozhraní a vfs.dev.get bloková zařízení (Linux a AIX) jako jeden JSON se všemi atributy, bez skládání z několika položek. Šablony Linux a AIX by Zabbix agent jsou na ně už přepsané a hodí se i pro vlastní LLD pravidla.

vfs.fs.get navíc dostává parametry mode a mountpoint pro výběr režimu výstupu a konkrétního přípojného bodu. Šablony operačních systémů jej používají pro sběr filesystemů; z jednoho JSON výstupu lze získat data pro discovery i navazující závislé položky.

DNS přes c-ares s cache a failoverem

Server, proxy i agent umí DNS dotazy řešit knihovnou c-ares s cache a failoverem mezi resolvery (volba při buildu, funguje i pro agenta na Windows). Výpadek nebo zpomalení jednoho DNS serveru už nezastaví polling hostů zadaných jménem.

Cache engine ID u SNMPv3

SNMPv3 si po prvním zjištění cachuje engine ID zařízení a nepotřebuje tak před každým dotazem úvodní výměnu. U velkých SNMP sítí to znamená znatelně méně paketů a rychlejší polling.

SNMP: Retries a makra pro Max repetition count

Na SNMP rozhraní přibývá Retries pro počet opakování nativních bulk požadavků. Max repetition count nově přijímá uživatelská makra. Chování pollingu tak můžete přizpůsobit pomalejším nebo omezeným zařízením a velikost bulk dotazů spravovat přes makra místo ručního nastavování každého rozhraní.

Monitoring cache trendových funkcí

Interní položka zabbix[tcache,cache,paccessed] ukazuje podíl záznamů cache trendových funkcí použitých za posledních 24 hodin. Spolu s pitems a pmisses ji sbírají health šablony serveru. Health šablony serveru i proxy nově sledují také vytížení Telemetry query pollerů, což pomůže rozpoznat úzké místo při zpracování APM položek.

HTTP agent a LLD: volnější vstupy

HTTP agent přijme v těle požadavku i formálně nevalidní JSON nebo XML, discovery pravidlo typu HTTP agent má volbu převodu odpovědi na JSON a LLD makra se resolvují i ve vnořeném JSONu v prototypech. VMware položky *.alarms.get vracejí detaily entit a skutečné jméno hosta.

Agent 2: Oracle přes TLS, Ceph jako loadable plugin

Oracle plugin agenta 2 podporuje TCPS (TLS), Ceph plugin je nově loadable a MySQL plugin používá SHOW REPLICA STATUS vedle staršího SHOW SLAVE STATUS, takže funguje i na aktuálních verzích MySQL.

HTTP přesměrování a profilování agenta 2

Klíče web.page.get, web.page.perf a web.page.regexp mají nový volitelný parametr redirect_limit, který řídí počet následovaných HTTP přesměrování. Agent 2 zároveň přidává pprof profiler pro diagnostiku spotřeby CPU a paměti; jde o nástroj pro hledání provozních problémů agenta, ne o profilování aplikací v APM.

Nové funkce jsonpath, xmlxpath, contains a substring

Historické a makro funkce dostávají jsonpath() a xmlxpath() pro vytažení hodnoty z JSON nebo XML obsahu, contains() a substring() pro práci s textem. JSONPath a XMLXPath v trigger výrazech pracují s řetězcovými typy položek (Character, Text a Log). Nový úložný typ JSON tím nezískává přímou podporu triggerů; potřebné hodnoty lze dále získat preprocessingem do závislých položek.

Diagnostika preprocessingu a stránka po přihlášení

Server a proxy poskytují podrobnější diagnostický výstup preprocessingu, který pomůže při hledání úzkých míst ve zpracování položek. V uživatelské roli lze také vynutit stránku po přihlášení, například společný provozní dashboard. Výchozí pohled týmu tak nemusí záviset na osobním nastavení každého uživatele.

Inline validace formulářů

Prakticky každý formulář ve frontendu prošel přepisem na inline validaci: chyby se ukážou u pole hned, ne až po odeslání. Discovery pravidla a host prototypy se otevírají v modálním okně jako zbytek konfigurace, přibyl odkaz Skip to main content pro čtečky a klávesnici a filtr tagů v Problems přišel o nadbytečné přepínače (prázdný seznam tagů = všechny tagy).

Inverze hodnot v grafu

Widget Graph má u datové sady volbu Invert values: metrika se vykreslí zrcadlově pod osou, takže se do jednoho grafu vejde příchozí a odchozí provoz nebo čtení a zápis disku bez překrývání.

Patterny položek ve widgetu Top items

Sloupce widgetu Top items přijímají patterny názvů položek místo výběru konkrétních položek. Například Checkout:* zahrne položky, jejichž název začíná Checkout:, napříč vybranými hosty. Pattern se vztahuje k názvu, nikoli ke klíči položky. Výběr můžete dále omezit tagy položek a nastavit řazení i počet zobrazených položek.

Slideshow dashboardu vypnutá ve výchozím stavu

Nově vytvořené dashboardy mají Start slideshow vypnuté a slideshow se dá zapnout parametrem v URL (&slideshow=1). Hodí se pro sdílené odkazy na obrazovky v dohledovém centru, kde má jeden odkaz rotovat a druhý stát.

Import a export globálních regulárních výrazů

Globální regulární výrazy mají Import a Export ve stejném YAML/JSON/XML formátu jako šablony, takže je lze verzovat a přenášet mezi instancemi stejně jako zbytek konfigurace.

Create proxy in Cloud a menu Subscriptions

Stránka proxy dostala tlačítko Create proxy in Cloud pro instalace propojené se Zabbix Cloud a v menu nápovědy nahradila zastaralou položku Support položka Subscriptions.

E-mailová vlákna pro problém a recovery

E-maily ze Zabbixu mají hlavičku Message-ID a správně vyplněné In-Reply-To, takže se problém a jeho recovery v poštovním klientovi sbalí do jednoho vlákna. Makro {EVENT.RECOVERY.TAGS} se nově resolvuje i při ručním uzavření problému.

Housekeeper: mazání událostí a odložené mazání

Housekeeper při smazání triggeru odstraní i jeho události, ne jen problémy, a mazání velkých objemů historie po smazání položek běží přes tabulku odložených úloh, takže samotné smazání položky v UI nečeká na databázi.

Na co si dát pozor při upgradu

Upgrade nejprve ověřte na kopii databáze a konfigurace; kromě dostupnosti ověřte integrace, vlastní moduly a očekávané chování rolí. APM vyžaduje další provozní komponenty jen tehdy, když tuto funkci chcete používat. Verze komponent uvedené níže odpovídají podporovanému rozsahu Zabbixu 8.0, nikoli doporučení používat starší nepodporovanou databázi.

Minimální verze

Podporované rozsahy jsou PHP 8.2–8.5, MySQL a Percona 8.4–9.7, MariaDB 10.11–12.3, PostgreSQL 15–18 a TimescaleDB 2.20–2.29. Jde o podporované verze, ne o spodní technický limit, při kterém se server ještě spustí. Volitelný ClickHouse backend pro běžnou historii položek má rozsah 25.8.22–26.4; toto nastavení je oddělené od telemetrického úložiště APM. Pro produkci vybírejte podporované stabilní verze a ověřte také vzájemnou kompatibilitu PostgreSQL a TimescaleDB.

Odstraněné API metody

Metody host.massupdate, template.massupdate, hostgroup.massupdate, templategroup.massupdate a hostinterface.replacehostinterfaces jsou odstraněné, nahrazují je běžné *.update a massadd / massremove. Nové uživatelské role mají přístup k API vypnutý (viz kapitola o bezpečnosti).

Odstraněná makra

Končí dlouho deprecated {ACK.DATE}, {ACK.TIME}, {ACK.MESSAGE}, {EVENT.ACK.HISTORY}, {IPADDRESS}, {HOSTNAME}, {TRIGGER.KEY}, {TRIGGER.COMMENT}, {STATUS}, {PROFILE.*} a {USER.ALIAS}. Před upgradem projděte media typy, akce a skripty a nahraďte je aktuálními ekvivalenty ({EVENT.UPDATE.*}, {HOST.IP}, {HOST.NAME}, {ITEM.KEY}, {TRIGGER.DESCRIPTION}, {TRIGGER.STATUS}, {INVENTORY.*}, {USER.USERNAME}).

Protokoly

Odstraněna je podpora legacy textového a XML protokolu z dob před Zabbixem 1.6. Prověřte velmi staré agenty a vlastní sendery; pro běžné instalace s aktuálním Zabbix protokolem nejde o změnu formátu odesílaných hodnot.

Minimální kompatibilní verze klasického Zabbix agenta se tím posouvá z 1.4 na 1.6. Nejde o změnu minima agenta 2, který je podporovaný od řady 4.4.

Nové a aktualizované šablony

Vedle nových integrací přibývají šablony pro OpenTelemetry. Umožňují začít s hotovými položkami, discovery a triggery místo skládání každého telemetrického dotazu ručně.

Nové šablony:

• OpenTelemetry: Generic OpenTelemetry by OTLP (obecný přehled traces, metrik a logů), Proxmox VE by OTLP (metriky virtualizačních uzlů), Envoy Proxy by OTLP (traces, metriky a logy proxy), OpenRouter traces by OTLP (průběh a chybovost požadavků na modely).
• Cloud a náklady: Oracle Cloud Costs by HTTP, GCP Cost monitoring by HTTP, Google Cloud Storage by HTTP, GCP Cloud Run Service by HTTP, GCP Application Load Balancer by HTTP, Oracle Cloud Load Balancer by HTTP, Azure Container Apps by HTTP, Azure Sentinel by HTTP
• Databáze: MariaDB by Zabbix agent / agent active / by ODBC, Percona by Zabbix agent / agent active / by ODBC
• Kontejnery a virtualizace: Kubernetes Cluster by HTTP, Podman by Zabbix agent / agent active / by HTTP, Microsoft Hyper-V by SSH (cluster i standalone)
• Aplikace a AI: OpenAI Platform by HTTP, Claude API by HTTP, GitHub organization by HTTP (včetně Copilotu), GLPI by HTTP
• Síť: Ribbon SBC Edge / SWe core / SWe CE by HTTP, VeloCloud SD-WAN Edge by HTTP, Huawei AR600 by SNMP, Cradlepoint NCM v2 by HTTP a Cradlepoint NCM v2 device by HTTP
• Ostatní: Domain expiration by RDAP, webhook pro IBM Maximo (zakládání service requestů)

Aktualizované šablony:

• Linux, Windows a AIX: sběr filesystemů přes vfs.fs.get; Linux navíc nové dashboardy, net.if.get a vfs.dev.get, AIX sběr blokových zařízení přes vfs.dev.get.
• MySQL by Zabbix agent a by ODBC (nové metriky, discovery tabulek a replik, nové dashboardy, podpora nové syntaxe), PostgreSQL by Zabbix agent a by ODBC
• Proxmox VE by HTTP (nested LLD, mapování SMART statusu), VMware (discovery alarmů), Veeam Backup & Replication a Veeam Backup Enterprise Manager by HTTP (aktualizace pro Veeam 13.1).
• Microsoft 365 reports by HTTP (Copilot), GitHub repository by HTTP
• Zabbix server health (cache trendových funkcí) a health šablony serveru i proxy (vytížení Telemetry query pollerů).
• SNMP šablony (lepší trigger na uptime zařízení), Cisco (regex verze), Meraki (mapování stavů, nový trigger), Ciena 3906 by SNMP (filesystem, CPU load), Vyatta Virtual Router by SNMP
• AWS Cost Explorer a Azure Cost Management by HTTP (nové dashboardy), společné multicloud dashboardy pro virtuální stroje i náklady.
• Redis by Zabbix agent 2 (makra pro autentizaci), Ceph by Zabbix agent 2 (native connection mode)
• Nextcloud by HTTP, NetApp AFF A700 by HTTP, MSSQL, Stormshield SNS by SNMP, RabbitMQ (drobné opravy)

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

• Zabbix 8.0 LTS ke stažení: oficiální balíčky Zabbixu.
• Sestavení ze zdrojů: zdrojové balíčky Zabbixu.
• Dokumentace novinek: What’s new in Zabbix 8.0.

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.