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

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), takže se dají číst i jinými nástroji.

Zpracování: item typu Telemetry query

Nový typ itemu Telemetry query spojuje svět OTel s klasickým Zabbixem. Místo klíče se skládá dotaz: kategorie (Traces, Metrics, Logs), u metrik typ bodů (Sum, Gauge, Histogram, 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 dohledávat chybějící data).

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 checkout za posledních 5 minut 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.

Ukázka: od traces k triggeru

Vyzkoušeli jsme celý řetězec na testovací instalaci: do ClickHouse tečou traces fiktivního e-shopu (služby frontend, checkout, payment, inventory) ve formátu OpenTelemetry ClickHouse exporteru a Zabbix server nad nimi počítá Telemetry query itemy. Item pro 95. percentil latence služby checkout vypadá takto: kategorie Traces, agregované sloupce percentile(Duration, 95), avg(Duration) a count, podmínka ServiceName equals checkout, granularita 1 minuta, interval 30 s.

Server dotaz přeloží do ClickHouse SQL a vrátí jednu hodnotu za bucket jako JSON, například {"columns":{"p95":217264910,"avg":186257520,"cnt":29}} (Duration je v nanosekundách). Zbytek je klasický Zabbix: preprocessing JSONPath $.columns.p95 a Custom multiplier 1.0E-6 udělají z hodnoty milisekundy, item má jednotku ms. Stejným způsobem vznikly itemy pro průměrnou latenci, počet požadavků za minutu, p95 platební brány a počet HTTP 5xx chyb na /api/checkout (podmínka nad SpanAttributes s klíčem http.route).

Nad itemy fungují triggery jako u čehokoli jiného: last(/Zabbix server/apm.checkout.latency.p95)>800 hlídá latenci, last(/Zabbix server/apm.checkout.errors)>=3 počet chyb za minutu. Když se v testovacím provozu zvedla chybovost platební brány, trigger vystřelil a v Problems je problém s tagy service: checkout, ze kterých se dá rovnou skočit do filtru v pohledu Traces.

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ý povinný stavební kámen, 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ž trigger vystřelí.

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ý, a to pro všechny typy rolí včetně Super admin. Kdo API potřebuje (integrace, skripty, náš Zabbix MCP server), musí ho v roli zapnout a ideálně rovnou omezit allow listem metod. Stávající role při upgradu zůstávají, jak jsou, změna se týká rolí vytvořených v 8.0. Je to konec doby, kdy měl každý účet s heslem automaticky i plný programový přístup.

Feature flags: co v instalaci vůbec nesmí být

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;   // žádné moduly a widgety třetích stran
$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ů

Po vypnutí modulů zmizí položka Administration > General > Modules a nikdo, ani Super admin, ji přes UI nezapne. Zamýšlené použití je zřejmé: managed a regulovaná prostředí, kde má o rozsahu instalace rozhodovat provozovatel, ne každý administrátor zvlášť.

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

Trapper serveru a proxy přestal přijímat starší, ne-JSON varianty protokolu z dob před Zabbixem 4.x. Kdo má někde zapomenutého velmi starého agenta nebo vlastní skript, který posílá data v původním textovém formátu, musí ho před upgradem převést na JSON protokol; vše novější se nemění.

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.

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.

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.

Monitoring cache trendových funkcí

Nová interní položka zabbix[tcache,cache,paccessed] ukazuje využití cache trendových funkcí a health šablony Zabbix server a proxy ji rovnou sbírají. Proxy navíc lépe škrtí odesílání dat, když je její history cache pod tlakem, místo aby server zahltila.

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.

Nové funkce jsonpath, xmlxpath, contains a substring

Trigger výrazy a makro funkce dostávají jsonpath() a xmlxpath() pro vytažení hodnoty z JSON nebo XML položky a contains() a substring() pro práci s textem. Spolu s novým typem hodnoty JSON se tak dá s komplexní odpovědí pracovat přímo v triggeru bez preprocessing kroků.

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 položek místo výběru konkrétních položek. Jeden sloupec tak pokryje třeba všechny vfs.fs.size[*,pused] napříč hosty a limit Top N se aplikuje na každý pattern zvlášť.

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

Minimální verze

PHP 8.2 (podporováno až PHP 8.5), MySQL a Percona 8.4, MariaDB 10.11 (server se s MariaDB pod 10.5 vůbec nespustí), PostgreSQL 15, TimescaleDB/TigerData 2.20. Nejvyšší podporované verze jsou MySQL 9.7, MariaDB 12.3, PostgreSQL 18 a TimescaleDB 2.29.

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

Trapper serveru a proxy nepřijímá starší ne-JSON varianty protokolu z dob před Zabbixem 4.x. Staré agenty a vlastní sendery je potřeba převést na JSON protokol před upgradem.

Nové a aktualizované šablony

Build 8.0 obsahuje 380 šablon.

Nové šablony:

• 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 by Zabbix agent / agent active (nové dashboardy, nové klíče agenta včetně net.if.get a vfs.dev.get), Windows by Zabbix agent, AIX by Zabbix agent (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
• Microsoft 365 reports by HTTP (Copilot), GitHub repository by HTTP
• Zabbix server a proxy health (cache trendových funkcí, oprava zpracování chyb ODBC polleru)
• 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), globální multicloud VM dashboard
• 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 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.