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

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

StartAPMCollector=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 lze uložit do HashiCorp Vault (vault_path=). Oficiální proxy balíčky pro Debian 12+ a Ubuntu 24.04+ obsahují podporu APM, není nutné kvůli ní automaticky překládat Zabbix. U RHEL 10 a odvozených systémů se používá samostatný APM balíček a odpovídající repozitáře. Pokud sestavujete proxy ze zdrojů, zůstává volba --enable-proxy --with-apm a knihovny gRPC/protobuf. Podporu ověřte pro konkrétní distribuci a balíček.

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 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í. První snímek ukazuje seznam traces modelového nákupu itemMAX PRO na webu initMAX a následující snímek 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.

Trace bez kořenového spanu

Trace může dorazit nekompletní, například kvůli chybějící instrumentaci vstupní služby nebo ztracené exportní dávce. Zabbix ho zobrazí s označením No root span found. V našem syntetickém příkladu záměrně chybí první span z webu; zbývá pět spanů e-shopu, portálu a testovací platby. Chybějící část si Zabbix nedomýšlí a naměřený úsek nelze vydávat za úplnou odezvu od vstupu zákazníka.

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.

Globální konfiguraci APM může využívat i server a proxy. Pokud proces nemá vlastní TelemetryProvider, použije globální nastavení telemetrické databáze; lokální TelemetryProvider má přednost. U oddělených prostředí proto zkontrolujte, do kterého ClickHouse proxy zapisuje a odkud čtou položky Telemetry query i frontend. Samotný ClickHouse history backend a jeho tabulky history* telemetrické úložiště 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.

APM filter: přístup podle atributů služby

V Users > User groups přibývá záložka APM filter. Omezení pracuje s Resource attributes, například service.name=initMAX e-shop, a lze ho nastavit pro Traces, Metrics, Logs nebo všechny signály. Nejde jen o filtr tabulky: podmínky se uplatňují také v příslušném APM API. Oprávnění k běžným hostům tím nenahrazujeme.

Filtry ze skupin uživatele se spojují logikou OR. Přidání skupiny s přístupem k portálu tedy zpřístupní e-shop i Portal, nikoli průnik obou podmínek. Pokud uživatel nemá žádné APM filtry, toto atributové omezení se neuplatní; Super admin je obchází. Proto nepovažujte samotné přidání jednoho řádku za hotovou izolaci zákazníků a prověřte všechna členství i oprávnění role.

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 se ukládá jako hodnota itemu. Pro číselný graf nebo trigger je třeba z vráceného JSON vybrat požadované číslo, například p95 latence služby initMAX e-shop v minutových intervalech. Dotaz vykonává server nebo proxy nad globální APM konfigurací, případně nad vlastním TelemetryProvider. Pro tyto dotazy je 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.

Telemetry query lze použít také v LLD pravidlech a discovery prototypech. Namísto ručního zakládání položek pro každou službu tak lze služby objevit z telemetrie a pomocí maker vytvořit odpovídající položky. Podmínky dotazu podporují uživatelská makra a v prototypech i LLD makra; číselné podmínky zahrnují také >= a <=. Pole výsledků obsahuje vybrané sloupce přímo v jednotlivých objektech, což je důležité i pro mapování LLD maker.

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 přeloží dotaz do ClickHouse SQL a vrátí JSON pole výsledných intervalů. Každý řádek má clock a agregace přímo ve svém objektu, například [{"clock":1793452094,"p95":1438000000,"avg":1386000000,"cnt":29}]. Při dohánění starších intervalů může pole obsahovat více řádků. Pro náš číselný item vybíráme JavaScriptem hodnotu p95 z řádku s nejvyšším clock; prázdný výsledek zahodíme:

var rows = JSON.parse(value);
if (rows.length === 0) return null;
var latest = rows[0];
for (var index = 1; index < rows.length; index++) {
    if (Number(rows[index].clock) > Number(latest.clock)) latest = rows[index];
}
if (latest.p95 === null) return null;
return latest.p95;

Duration je v nanosekundách. Následující Custom multiplier 1.0E-6 převede p95 na milisekundy a item používá jednotku ms. Pro další položky vybíráme alias avg nebo cnt. Jedno pole s více intervaly se samo nerozpadne na více bodů číselné historie. Náš příklad ukládá poslední vrácený interval jako aktuální hodnotu položky. Pro analýzu všech intervalů lze uchovat i nezpracovaný JSON v textovém itemu.

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.

V Monitoring > Latest data už vidíme výsledky jako běžné hodnoty položek: p95 a průměrnou latenci v milisekundách a počty objednávek za vyhodnocený interval. Nejde o seznam surových spanů; ty zůstávají v APM.

V Monitoring > Hosts otevřeme grafy našeho demonstračního hosta. Graf porovnává p95 přípravy objednávky a testovací platební služby. Nejprve je objednávka vyřízená přibližně za 300 ms, během simulovaného zpomalení p95 přesáhne 1,4 s a hranici triggeru 800 ms; po zotavení se vrátí pod tuto hranici. Křivky jsou výsledkem stejných položek Telemetry query, nikoli ručně vložených hodnot.

V historii pohledu Monitoring > Problems vidíme vznik obou demonstračních problémů i jejich automatické vyřešení po zotavení. Jde o stejné časové okno jako v grafu; sloupce Recovery time a Status ukazují čas obnovy a stav RESOLVED.

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. Pro APM počítejte s ClickHouse 26.8.17.4 nebo novějším v podporovaném rozsahu a se synchronizovaným časem komponent. Ve zdrojích jsou skripty database/clickhouse/otel_all.sh a dílčí schémata pro traces, metriky a logy. Vytvoří potřebné telemetrické tabulky; nenahrazují návrh retence, kapacity ani migraci již uložených dat. Citlivé atributy omezujte 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ů.

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í CEP pravidla.

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 vybírá způsob práce v čase: None zpracuje event bez okna. U Simple (multiple) může event zpracovat více odpovídajících pravidel; Simple (once) ho předá jen prvnímu odpovídajícímu pravidlu tohoto režimu. Cause and symptoms grouping seskupuje příčinu a symptomy, Pattern match vyhodnocuje vzor událostí pomocí JavaScriptu v poli Script. Seskupování podle tagů se nastavuje samostatně v Group by.
• 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ží. Pokud přidání eventu překročí kapacitu okna, je právě přidaný 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 patří k režimu Cause and symptoms grouping. Zabbix ho doplňuje na příčinu a aktualizuje v něm počet jejích symptomů. V našem příkladu tedy cep.count=5 znamená jednu příčinu a pět navázaných symptomů, nikoli pět událostí včetně příčiny.
• 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 Execute when, tedy okamžik spuštění operace. Následující Conditions rozhodují, zda se operace v dané situaci vůbec vykoná. Vedle tagů mohou kontrolovat například to, jestli je problém otevřený, potlačený nebo označený jako symptom, případně zda jde o první či poslední event v okně. Teprve níže vybíráme samotnou akci a její cílové události.

• 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ří.
• Event closed se spustí při uzavření události v časovém okně. Je to jiný okamžik než uzavření celého okna; operace může reagovat například na skončení příčiny incidentu.
• 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 > Event closed > Window closed > Pattern matched a operace v pravidle musí být takto seřazené. Jejich nabídka závisí na typu okna: u None je jen Event occurred, zatímco Pattern matched patří pouze k Pattern match. Discard slouží k vyřazení právě vznikající události při Event occurred; není to nástroj pro dodatečné mazání eventů, které už jsou v okně.

Applies to odděluje podmínky spuštění od výběru událostí, které operace změní:

• Current event: operace pracuje s aktuální událostí.
• Other events: pracuje s ostatními událostmi v témže okně, nikoli s aktuální.
• All events: zahrne všechny události v okně včetně aktuální.

U Other events a All events lze zapnout samostatný Filter. Ten vybírá cíle operace, nikoli události vstupující do pravidla. V ukázce reagujeme na uzavření příčiny a souvisejícím symptomům doplníme tag cep.cause=resolved. Podmínka operace vylučuje symptom jako spouštěcí událost; filtr rozsahu naopak vybírá právě symptomy. Event closed nenabízí operaci Close pro uzavření dalších problémů a ukončení příčiny samo neznamená jejich vyřešení. Close (window) uzavírá časové okno, nikoli automaticky všechny jeho problémy.

Část Operation určuje konkrétní akci. Podle jejího typu se zobrazí další pole, například nový název eventu, cílová severity nebo název a 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 uzavře vybrané otevřené problémy. Discard při Event occurred odmítne právě vznikající událost; již uložené eventy dodatečně nemaže.
• 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, Set a Set value doplní nebo upraví tagy. To je užitečné pro další filtrování, notifikace, dashboardy i návaznou automatizaci.
• Increase value a Decrease 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 a Remove 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, Event closed, 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,
• tag service rozlišuje web, portál, e-shop, gateway, databázi a API,
• 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 jsou problémy propojené jako jedna příčina a pět symptomů. V ukázce vznikl databázový problém jako první, a proto ho režim Cause and symptoms grouping zvolil za příčinu. Nejde o automatické odhalení skutečné technické příčiny: kdyby jako první vznikl aplikační timeout, vedl by skupinu on. V pohledu Problems jsou ostatní problémy rozbalené pod příčinou a tag cep.count=5 udává počet jejích symptomů.

• 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ří.

Příklad: společná databáze webu, e-shopu a portálu

Před korelací

Po korelaci

Web, e-shop i portál běží na různých hostech, ale používají stejnou databázi. Samotná databázová hláška ještě nemusí znamenat výpadek zákaznických služeb. Zajímá nás až kombinace problému databáze a chyby alespoň jedné aplikace.

• Vstup: databázové i aplikační eventy mají dependency=payments-db a environment=production. Tag component rozlišuje hodnoty database a application.
• Pravidlo: Pattern match, Duration 5m, Group by podle tagů dependency a environment. Seskupení podle Host nezapínáme, protože potřebujeme spojit různé hosty. Skript ověří, že jsou v okně současně otevřené oba typy problémů:

var events = cep_get_events();
function hasComponent(component) {
    return events.some(function(event) {
        return event.is_open && event.tags.some(function(tag) {
            return tag.tag === 'component' && tag.value === component;
        });
    });
}
return hasComponent('database') && hasComponent('application');

Výsledek: při Pattern matched nastavíme otevřeným eventům přes All events a filtr Problem is open společný tag cep.context=shared-db-incident a severity High. Operací Close (window) poté ukončíme toto vyhodnocení.

Samostatný databázový problém podmínku nesplní. Závažnost se zvýší až po potvrzení dopadu do aplikace. Tento příklad události společně klasifikuje; režim Pattern match jim sám nevytváří vztah příčina–symptom a uzavření okna neuzavře jejich problémy.

Příklad: služba opakovaně vypadává a zase se obnovuje

Před korelací

Po korelaci

Portál se třikrát během deseti minut odmlčí, ale první dva výpadky se rychle obnoví. V aktuálním seznamu tak může zbýt jediný problém, přestože opakování ukazuje na nestabilní službu.

• Vstup: eventy konkrétní kontroly dostupnosti mají například service=portal-api a check=availability. Trigger používá běžné vytváření jednoho problému při přechodu do stavu PROBLEM, ne opakované generování během jednoho trvajícího výpadku.
• Pravidlo: Pattern match, Duration 10m, Group by podle Host a tagu service. Počítáme nové problémové eventy v okně, včetně těch, které se už obnovily. Kopie eventů do počtu nezahrnujeme:

return cep_get_events().filter(function(event) {
    return !event.is_copied;
}).length >= 3;

Výsledek: po třetím eventu nastavíme přes Pattern matched právě otevřeným problémům severity High a tag cep.pattern=repeated-outage. Následné Close (window) zabrání opakování stejných operací nad již vyhodnocenou skupinou.

Jeden desetiminutový výpadek není totéž jako tři nové výpadky. Stejně tak nesčítáme chyby různých služeb nebo hostů. Starší obnovené události zůstávají součástí historie; neotevírají se znovu a změna severity sama o sobě neposílá notifikaci bez odpovídající konfigurace akcí.

Příklad: očekávané hlášky během noční zálohy

Před korelací

Po korelaci

Během zálohy pravidelně vznikají krátké problémy konkrétní kontroly, které nechceme řešit stejně jako neočekávaný výpadek přes den. Nechceme ale vypnout monitoring celého hosta.

• Vstup: přesně vybraná skupina hostů a eventy se štítkem component=backup-verification. Podmínka Time period omezí pravidlo například na 1-7,02:00-02:15; rozhoduje čas vzniku eventu a časová zóna serveru.
• Pravidlo: Time window None. Při Event occurred nastavíme tag cep.context=backup-window a použijeme Suppress s Duration 15m.
• Výsledek: odpovídající problémy zůstanou dohledatelné, ale jsou dočasně potlačené a označené jako součást zálohovacího provozu. Jiný typ problému ani stejná hláška mimo daný časový interval tímto pravidlem potlačené nebudou.

Doba potlačení běží od každé operace, ne od začátku plánovaného intervalu. Event z 02:14 tedy může zůstat potlačený přibližně do 02:29. Po vypršení potlačení se nevyřešený problém automaticky neuzavře. Pro plošnou plánovanou odstávku je vhodnější Maintenance; CEP zde cíleně upravuje jen vybraný druh událostí.

Příklad: databáze už běží, ale aplikace se neobnovila

Před obnovou příčiny

Po obnově příčiny

Vraťme se ke skupině příčiny a symptomů z New Yorku. Databáze se obnoví, ale portál stále hlásí chybu připojení. Právě takový zbytek incidentu je potřeba zvýraznit: obnova příčiny ještě neznamená obnovu všech služeb.

• Vstup: příčina a její symptomy stále patří do stejného okna režimu Cause and symptoms grouping. Uzavření příčiny musí nastat, dokud je toto okno aktivní.
• Pravidlo: Execute when Event closed, podmínka Problem is symptom = No. Operace Set nastaví cep.cause=resolved; v Applies to zvolíme Other events a ve Filter vybereme Problem is symptom = Yes a Problem is open = Yes.
• Výsledek: otevřené symptomy dostanou informaci, že příčina už skončila. Pokud je pravidlo předtím potlačilo, může nad stejným výběrem provést i Unsuppress. Operátor tak může dohledat služby, které potřebují samostatný zásah, například obnovení databázového spojení.

Neprovádíme hromadné uzavření symptomů. Portál se musí skutečně obnovit a jeho trigger vyhodnotit OK. Eventy z jiného okna se touto operací nezmění. Jakmile okno skončí, nelze od tohoto pravidla očekávat dodatečné zpracování pozdější obnovy příčiny.

Co zohlednit při nasazení CEP

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

O délce okna a tagu pro seskupení rozhoduje konkrétní služba, ne univerzální hodnota. Příliš široké pravidlo může spojit nesouvisející incidenty. V prostředí s více zákazníky oddělte také tenant; u produkce a testu alespoň environment. Notifikační akce musí respektovat zvolenou severity, tagy a potlačení. Korelace sama nenahrazuje konfiguraci notifikací ani skutečnou obnovu služby.

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áší serverovou část pro připravovanou oficiální mobilní aplikaci a nový typ media type Push. Samotná aplikace zatím není vydaná. Ve frontendu jsou již dostupné formuláře pro správu zařízení, jejich oprávnění v uživatelských rolích a konfiguraci media type Push. Připravované řešení má doručovat notifikace o problémech přímo do telefonu, bez e-mailu, SMS brány nebo webhooku třetí strany.

Ukázky připravované oficiální mobilní aplikace Zabbix: přehled problémů, seznam a detail problému.

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.

Připravovaná mobilní aplikace Zabbix Mobile App má fungovat jako 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 instalujeme vedle Zabbix serveru nebo na samostatný stroj. Propojuje vlastní Zabbix s centrálně provozovanou službou Zabbix Bridge, přes kterou komunikuje mobilní aplikace. Nezprostředkovává jen push: požadavky aplikace předává místnímu Zabbix API a vrací jeho odpovědi. Mobil tak nemusí přistupovat přímo na veřejně vystavený frontend. Adaptér, mobilní aplikace a centrální Bridge jsou samostatné komponenty s vlastní EULA; nejde o součást otevřeného kódu Zabbix serveru.

Lokální Bridge Adapter patří do důvěryhodné části infrastruktury. Zabbix server mu předává titulek, tělo zprávy a metadata události spolu s veřejným šifrovacím klíčem telefonu. Není tedy správné předpokládat, že adaptér text problému nevidí. Šifrování pro mobilní zařízení a TLS mezi komponentami jsou různé vrstvy ochrany; podle nasazení použijte i vzájemné ověřování certifikáty. Mobilní přístup k API používá DPoP, který váže token na klíč zařízení a kontroluje podpis i opakované použití požadavku.

Konfigurace serveru

EnableMobileDevices má výchozí hodnotu 1. To ale samo o sobě nezprovozní párování ani push: server potřebuje nakonfigurovaný a dostupný adaptér. V zabbix_server.conf nastavíme jeho adresu:

EnableMobileDevices=1
BridgeAdapterURL=https://bridge.example.com:10054/rpc

BridgeAdapterURL je adresa našeho místního adaptéru, nikoli centrální služby Zabbix Bridge. Adaptér nemusí běžet na stejném stroji jako server; zvolené jméno musí vést na jeho dostupné HTTPS rozhraní. Parametr BridgeAdapterConnectTo aktuální server nepodporuje. Pro jinou síťovou cestu použijte odpovídající DNS a směrování při zachování ověřitelného jména v TLS certifikátu.

HA Zabbix serveru neznamená automaticky HA Bridge Adapteru. V clusteru musí mít každý serverový uzel nakonfigurovaný a dostupný endpoint adaptéru. Jeho dostupnost a obnovu řešte samostatně, včetně uchování DataDir se stavem registrace a klíči. Ztráta tohoto stavu může zabránit opětovné registraci stejného serveru.

Při EnableMobileDevices=0 nejsou funkce zařízení dostupné. Bez nakonfigurovaného a dostupného adaptéru nelze dokončit párování ani doručovat push notifikace.

Bridge Adapter: konfigurace a přístup k API

Samostatný balíček zabbix-bridge-adapter používá konfiguraci /etc/zabbix/zabbix_bridge_adapter.conf. Potřebuje zejména ServerId z Reports > System information a ZabbixAPIURL vedoucí na vlastní API. Server komunikuje s adaptérem standardně přes TCP 10054; adaptér potřebuje spojení k místnímu API a odchozí komunikaci k Zabbix Bridge. Vnější dostupnost portu 10054 z telefonu není podmínkou.

AllowedAPIMethods omezuje metody, které adaptér smí přeposlat. Pro mobilní práci s problémy zahrnuje například problem.get, event.get a event.acknowledge; párování využívá device.onboard a device.offboard. Seznam nenahrazuje oprávnění uživatele v Zabbixu. Zároveň je třeba rozlišit prázdné nastavení, které metody nepovolí, od distribuovaného konfiguračního souboru s předvyplněným seznamem pro aplikaci.

Pro spojení server–adaptér slouží TLSConfig adaptéru, pro adaptér–API samostatné ZabbixAPITLSConnect. V produkci ověřujte certifikát i hostname; režim required bez ověření certifikátu není totéž jako verify_full. Zálohujte také jeho DataDir se stavem a klíči a před instalací projděte EULA i síťové požadavky.

Párování zařízení

Telefon si přidáme přes User settings > Devices > Add device. S nakonfigurovaným adaptérem se otevře QR kód s platností 10 minut; po naskenování v aplikaci a dokončení párování přejde zařízení do stavu Active. Jako správce můžeme použít také Users > Devices > Add device: nejdřív vybereme uživatele a tlačítkem Add vytvoříme QR kód. Ukázka zachycuje oba kroky. V přehledu na prvním obrázku jsou zařízení čekající na dokončení párování ve stavu New.

V Users > Devices přidáte zařízení tlačítkem Add device.

Vyberte uživatele, ke kterému bude zařízení přiřazené, a potvrďte Add.

QR kód načtěte v oficiální mobilní aplikaci Zabbix; platí 10 minut.

QR kód používá deep link zabbix://v1/link_device. Obsahuje identifikátor a název serveru, ID zařízení, enrollment URL centrálního Zabbix Bridge, dva jednorázové tokeny pro párování a veřejný klíč adaptéru. Nejde o přímou adresu místního adaptéru nebo frontendu, kterou by bylo nutné zpřístupnit telefonu z internetu. Zabbix server ID je viditelné v Reports > System information a rozlišuje jednotlivé Zabbix instalace.

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

Push notifikace využívají mobilní aplikaci a dostupnost Zabbix Bridge i internetového spojení. Zařízení jsou centrálně evidovaná a lze jim odebrat přístup. Při nasazení proto ověřte nejen přidání zařízení, ale i doručení problému, jeho aktualizace a recovery na skutečný telefon. Citlivé údaje neposílejte do textů notifikací bez promyšleného posouzení celé přenosové cesty.

SMS a hlasové upozornění jako nezávislý kanál

Push notifikace potřebují funkční datovou cestu přes internet. Pokud lokalitě se Zabbixem vypadne internetové připojení a nemá záložní cestu, zpráva se z ní k centrálnímu Zabbix Bridge nedostane. Mobilní data na telefonu operátora tento výpadek nevyřeší. Připojený musí být i přijímající telefon; push proto není nezávislý kanál pro hlášení výpadku konektivity.

Pokud bezpečnostní politika nepovoluje přenos monitorovacích dat přes externí službu, je potřeba zvolit jinou notifikační cestu. Mobilní aplikace komunikuje přes centrální Zabbix Bridge mimo vlastní infrastrukturu. Ani šifrování nenahrazuje posouzení toho, jaká data a metadata organizace předává provozovateli služby a za jakých podmínek. Místní adaptér proto sám o sobě neznamená čistě on-premise řešení.

Pro tyto situace lze využít vlastní hardwarovou bránu SMSEagle. Funkční Zabbix jí předá upozornění v lokální síti a SMS nebo hlasový hovor pak odchází přes SIM a mobilní síť, bez internetového připojení, Zabbix Bridge a cloudové SMS brány. Hodí se tak i do uzavřených sítí bez přístupu na internet, pokud jejich bezpečnostní politika dovoluje komunikaci přes mobilního operátora. Brána potřebuje napájení, signál, aktivní SIM a dostupné lokální spojení se Zabbixem; nevyřeší výpadek samotného serveru nebo celé LAN.

SMS není end-to-end šifrovaný kanál a její obsah stále zpracovává mobilní operátor. Do zprávy proto patří jen nezbytné údaje. Možnosti nasazení, modely a ceny najdete v našem přehledu SMSEagle.

Jako oficiální partner SMSEagle vám pomůžeme s výběrem brány, nasazením, integrací i servisní podporou. Připravili jsme také vlastní integraci Zabbixu pro SMS a hlasová upozornění. Najdete ji včetně návodu na našem GitHubu.

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.

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

V instalačním průvodci frontendu je v kroku Configure DB connection nový přepínač Vault authentication type: Token / AppRole. AppRole lze využít také pro načtení hesla k ClickHouse z Vaultu v konfiguraci serveru nebo proxy pomocí 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 nepovoluje žádnou API metodu: při jeho použití nestačí API pouze zapnout, je třeba vybrat i potřebné metody. Existující role si při upgradu zachovají nastavení přístupu k API. Do dosud prázdných allow listů upgrade doplní *, aby zachoval původní přístup ke všem metodám. Po upgradu proto tyto role projděte a wildcard nahraďte konkrétními metodami, které integrace skutečně používá.

Oficiální Zabbix MCP server

Zabbix MCP server propojuje AI asistenta se Zabbix API. Není to model AI ani součást automaticky spuštěná instalací Zabbix serveru. Instaluje se jako samostatný balíček zabbix-mcp-server z oficiálního repozitáře, případně se sestaví ze samostatných zdrojů. Běží jako vlastní služba; v /etc/zabbix/zabbix_mcp_server.conf se nastaví adresa API FrontendURL, povolení klienti AllowedIP a TLS.

Oficiální implementace je zaměřená hlavně na čtení monitoringu a obsluhu incidentů:

• Načítá hosty, skupiny, šablony, položky, LLD pravidla, rozhraní, makra, triggery, problémy, údržby a historii položek kromě binárních dat.
• U problémů umí potvrzení a jeho zrušení, komentář, změnu závažnosti, potlačení a jeho zrušení nebo ruční uzavření, pokud ho trigger dovoluje.
• U údržeb nabízí vytvoření, změnu a smazání. Nejde o plné administrační pokrytí Zabbix API: tyto nástroje nenahrazují například zakládání hostů, správu šablon či dashboardů.

Klient musí podporovat Streamable HTTP. Samostatný starší SSE transport ani lokální stdio tato implementace nenabízí. Autentizace používá přímo Zabbix API token v každém požadavku, nikoli OAuth přihlášení. Platí oprávnění vlastníka tokenu. Pro historii je navíc omezený rozsah dotazu a výchozí konfigurace některé čtecí nástroje z bezpečnostních důvodů zakazuje.

Dostupné nástroje omezují AllowTool a DenyTool. Schválení zápisu závisí na klientovi: při podpoře form elicitation čeká změna na potvrzení, jinak se povolený zápis provede rovnou. Začněte účtem s omezenými právy a zapněte jen potřebné operace. Podrobnosti uvádí oficiální dokumentace.

Pro širší práci se Zabbixem přes AI doporučujeme náš initMAX Zabbix MCP server. Pokrývá 100 % veřejných API metod Zabbixu 8.0, nejen čtení monitoringu a obsluhu incidentů. Umožňuje také správu hostů, položek, triggerů, šablon a dashboardů. Vedle připravených nástrojů nabízí přímé volání dalších API metod; dostupné operace vždy omezují oprávnění účtu a nastavená pravidla přístupu.

Podporuje OAuth 2.1, více instancí Zabbixu a transporty Streamable HTTP, starší SSE i lokální stdio. Součástí je webový administrační portál, ve kterém lze naklikat servery, uživatele, tokeny a přístupová pravidla. Nabízí scopes, režim pouze pro čtení, dvoukrokové potvrzení řízených zápisů, souhrnné pohledy, analýzu dat, grafy a reporty. Oficiální MCP tak může stačit pro užší obsluhu incidentů; naše implementace nabízí podstatně širší možnosti správy a automatizace.

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;               // omezí správu modulů
$ZBX_FEATURE_FLAGS['http_auth_enabled'] = false;                    // vypne HTTP autentizaci
$ZBX_FEATURE_FLAGS['media_type_denylist'] = ['script', 'webhook'];  // zablokuje editaci těchto typů médií
$ZBX_FEATURE_FLAGS['banners_enabled'] = false;                      // vypne informační bannery

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.

Správa modulů: vlevo povolená (true), vpravo blokovaná (false).

Pokud se někdo pokusí obejít omezení přímým otevřením URL stránky Modules, Zabbix mu přístup odepře a zobrazí tuto hlášku:

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

Zabbix server ID je trvalý identifikátor instalace ve formátu UUIDv7. Server ho při prvním spuštění vytvoří a uloží do hlavní databáze. Najdete ho v Reports > System information, odkud lze zkopírovat celou hodnotu. V HA mají všechny uzly společné server ID; nezaměňujte ho s ID jednotlivého HA uzlu.

Mobilní aplikace ho používá k rozlišení instalací a je součástí párovacího QR kódu. Slouží také při ověřování podepsaných API požadavků zařízení (DPoP), které se vážou na konkrétní instanci i volanou metodu. API serverinfo.get podle zadaného ID ověří instanci a vrátí čas posledního kontaktu serveru; v HA jde o aktivní uzel. Tlačítko Export uloží systémový přehled do JSON včetně server ID a případných HA uzlů. Samotné ID není přístupový token.

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.

Údržba otevřená přes Suppress trigger má předvyplněný trigger vybraného problému, název i časové okno. Délka se přebírá z nastavení Default maintenance period v profilu uživatele; v této ukázce je to jedna hodina. Před uložením lze údaje upravit.

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.

Odkaz Suppress trigger v dialogu Update problem.

Příklad nastavení výchozí doby údržby na jednu hodinu v uživatelském profilu pomocí pole Default maintenance period:

Možnost nastavení údržby na trigger nebo název události pomocí API

Údržby bylo možné přes API vytvářet už dříve. Zabbix 8.0 nově přidává cílení na triggery a podmínky podle názvu události. U maintenance.create a maintenance.update se nastavují pomocí triggers a event_names; při čtení přes maintenance.get slouží selectTriggers a selectEventNames. Tyto možnosti vyžadují údržbu se sběrem dat (maintenance_type=0).

Můžete tak potlačit jediný trigger disku a ostatní monitoring hosta ponechat aktivní, nebo omezit údržbu na problémy s „certificate expires“ v názvu. Stejné volby najdete i ve formuláři údržby. Operátory tagů navíc rozšiřují Does not equal a Does not contain. Následující příklad kombinuje vybraný trigger s podmínkou na název události; ID triggeru a časové údaje nahraďte vlastními:

{
  "jsonrpc": "2.0",
  "method": "maintenance.create",
  "params": {
    "name": "Ad-hoc: certificate renewal",
    "maintenance_type": 0,
    "active_since": 1788080400,
    "active_till": 1788084000,
    "triggers": [
      {
        "triggerid": "12345"
      }
    ],
    "event_names": [
      {
        "operator": 2,
        "value": "certificate expires"
      }
    ],
    "timeperiods": [
      {
        "timeperiod_type": 0,
        "start_date": 1788080400,
        "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ů.

Typy historie lze rozdělit mezi ClickHouse, Elasticsearch a hlavní SQL databázi. V následujícím příkladu používáme stejné rozdělení ve frontendu i na serveru:

• ClickHouse: uint, dbl, log, text a json.
• Elasticsearch: str, tedy typ Character.
• Hlavní SQL databáze: binární historie bin; konfigurace Zabbixu v ní zůstává i při použití externích history providerů.

Jde o příklad, nikoli povinné rozdělení. Typy zvolte podle zátěže a požadavků na provoz; každý typ historie přiřaďte nejvýše jednomu externímu provideru.

Frontend konfigurace (Zabbix UI / frontend)

Konfigurace ve frontendu je definovaná v /etc/zabbix/web/zabbix.conf.php pomocí pole $HISTORY_PROVIDERS. Každý backend tvoří samostatnou položku pole; bloky jsou proto oddělené čárkou podle standardní PHP syntaxe.

V této ukázce je jako první ClickHouse pro uint, dbl, log, text a json. Následuje Elasticsearch pro str, tedy typ Character. Jde o zvolené rozdělení, nikoli omezení backendů: oba umějí i ostatní uvedené typy, ale jeden typ nelze současně přiřadit dvěma providerům. Stejné rozdělení musí být nastavené i na Zabbix serveru.

Binární hodnoty (bin) nelze ukládat přes tyto providery do ClickHouse ani Elasticsearch. Zůstávají v primární SQL databázi Zabbixu. Formát přenosu RowBinary u ClickHouse není podporou binárního typu položky.

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.

HistoryProvider=clickhouse;value_types="uint,dbl,log,text,json",url=http://clickhouse:8123,db=zabbix,username=zabbix,password=CHANGE_ME
HistoryProvider=elasticsearch;value_types=str,url=http://elasticsearch:9200

Použití externího backendu ověřte také v Zabbix server logu. Při startu server vypíše název history provideru a detekovanou verzi, například pro ClickHouse následující zprávy. Rozdělení datových typů porovnejte s value_types v konfiguraci a ověřte skutečný zápis i čtení dat; samotný záznam v logu takový test nenahrazuje.

retrieving history provider "clickhouse" information
history provider "clickhouse" version "26.8.17.4"

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

ClickHouse podporuje i clusterové schéma. Schema skripty přijímají --cluster a vytvářejí lokální tabulky a nad nimi Distributed tabulky. Běžná historie se rozděluje podle itemid; u APM traces je shardovací klíč odvozený od TraceId, aby spany jednoho trace směřovaly společně. Zabbix umí zjistit TTL i přes distribuovanou tabulku. Dostupnost Keeperu, replikace, stabilní přístupový bod a zálohování ale zůstávají součástí návrhu databáze, nikoli automatickým důsledkem přepínače --cluster.

ClickHouse zde není v dokumentaci označený jako experimentální integrace. Jde o jiné úložiště než Elasticsearch. Podporovaný rozsah běžné historie je 26.3.0.0–26.9.x.x; pro APM telemetrii je minimum přísnější, 26.8.17.4. ClickHouse nenahrazuje hlavní konfigurační databázi Zabbixu.

Elasticsearch

Zabbix 8.0 podporuje Elasticsearch 8.0 až 9.5.x pro ukládání historie. Tato podpora již není experimentální. Při upgradu ověřte, že verze backendu odpovídá aktuálním požadavkům Zabbixu, a zkontrolujte konfiguraci připojení.

Elasticsearch backend upravuje síťovou komunikaci a více využívá opakované použití spojení (connection reuse). Tím snižuje režii navazování spojení; skutečný dopad na výkon závisí na dotazech, objemu dat a konkrétním nasazení.

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 DBHost ví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.

DBHost=pg-primary.example.com:5432,pg-secondary.example.com:5432
DBName=zabbix

Více databázových uzlů umí použít i frontend. V $DB['SERVER'] lze uvést seznam host:port; při více adresách přidává PostgreSQL backend frontendu target_session_attrs=read-write a timeout připojení. Je tedy potřeba rozlišovat přímé připojení k PostgreSQL od připojení přes pooler.

Pokud frontend používá lokální PgBouncer s transaction poolingem, musí správný zapisovatelný uzel vybrat i PgBouncer. Samotná změna Zabbixu tento krok nevyřeší. Sledujeme proto upstream PR #1534: podpora target_session_attrs v PgBounceru, který výběr backendu řeší. Návrh zatím není sloučený ani vydaný; do té doby je třeba zachovat funkční směrování na primary, například přes VIP, load balancer nebo odpovídající HA integraci.

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

Zabbix nově ukládá hodnoty položek také v typu JSON, na serveru i proxy. JSON už nemusí být jen řetězec v textové položce. Neplatný JSON se odmítne; podporované jsou položky a prototypy položek s výjimkou typu Calculated. U TimescaleDB je při upgradu potřeba ručně nakonfigurovat hypertabulku history_json. Podporu ukládání JSON má také Elasticsearch.

Typ JSON lze použít u master i závislých položek. Z jednoho masteru tak můžete uchovat celý dokument a zároveň vybrat jednotlivé hodnoty do dalších položek.

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 nelze nad položkou typu JSON vytvářet přímo triggery. Potřebné hodnoty vyberte preprocessingem do závislých číselných nebo textových položek; nad těmito položkami už lze triggery používat.

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

Při importu globálních dashboardů se hosty dohledávají podle technického názvu a položky podle hosta a klíče, nikoli podle původních ID. Nenalezené odkazy na hosty a položky import vynechá. Pokud projde ostatními kontrolami, dashboard se uloží, platné vazby zůstanou zachované a Zabbix zobrazí upozornění na vynechané reference.

V naší syntetické ukázce odkaz míří na neexistující DEMO NYC app-01 RENAMED. Import se skutečně dokončil a zobrazil hlášku na následujícím obrázku. Dotčené widgety zůstaly bez vazby na položky a je nutné je překonfigurovat; nestačí tedy zkontrolovat jen zelené potvrzení úspěchu.

Neznamená to, že projde libovolný chybný import. Neplatný formát nebo nedostatečná oprávnění jej mohou dál zastavit. Dashboardy uvnitř šablon se navíc importují jinou cestou a chybějící reference nadále odmítají.

Clustering v GeoMap widgetu

Ve widgetu GeoMap lze nastavit shlukování hostů. Režim Auto seskupování řídí automaticky; v režimu Zoom level určujeme úroveň přiblížení, od které se shlukování vypne. Při hodnotě 8 se od zoomu 8 zobrazují jednotlivé markery. Snížení hodnoty na 5 je tedy rozbalí dříve, už při menším přiblížení. Vyšší hodnota naopak zachová shluky déle.

Video: shlukování 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

Na podporovaných stránkách můžete pomocí Customize table v pravém horním rohu zobrazovat a skrývat sloupce, měnit jejich pořadí i šířku. Sloupec Tag value zobrazí hodnotu konkrétního tagu a umožňuje vlastní název. Sloupec Tags lze duplikovat a kopii přejmenovat, takže si vedle sebe připravíte několik odlišných pohledů na tagy.

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)

Rozložení se ukládá do uživatelského profilu; je osobní a ostatním uživatelům se nepřenese. Pro správu a sdílení uložených filtrů nabízíme také userfilterMAX. Uložený filtr a rozložení sloupců jsou dvě různé věci.

V ukázce přidáváme přes Customize table sloupec Tag value. Do Tag name zadáme brand a sloupec pojmenujeme Brand. U našich demonstračních hostů pak zobrazuje hodnotu initMAX, nikoli celý seznam jejich tagů. Červené rámečky označují nastavení i nový sloupec.

V Data collection > Hosts přidáme tagový sloupec Brand, skryjeme Status, nový sloupec přesuneme doleva a zvětšíme jeho šířku.

Video: úprava tabulky Hosts.

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í

Operational data u triggeru podporuje až 2048 znaků. Do provozních údajů se tak vejde delší kontext problému; není to změna limitu samotného názvu eventu.

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=on). 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 26.3–26.9; 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

Odstraňují se metody host.massupdate, template.massupdate, hostgroup.massupdate, templategroup.massupdate a hostinterface.replacehostinterfaces. Pro hromadné změny hostů, šablon a skupin použijte jejich aktuální API. U hostinterface.* zůstává veřejně dostupná pouze hostinterface.get; hostinterface.update není náhradou. Zápisy síťových rozhraní je třeba převést na podporované operace host API s polem interfaces a zachovat ID existujících rozhraní. Nové role mají přístup k API vypnutý.

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.HOST}, {ITEM.KEY}, {TRIGGER.DESCRIPTION}, {TRIGGER.STATUS}, {INVENTORY.*}, {USER.USERNAME}).

Odstranění se týká i číslovaných variant {HOSTNAME1} až {HOSTNAME9} a {IPADDRESS1} až {IPADDRESS9}. U názvu hosta používejte {HOST.HOST}, nikoli {HOST.NAME}: první makro vrací technické jméno, druhé zobrazovaný název. Historii aktualizací události získáte pomocí {EVENT.UPDATE.HISTORY} místo {EVENT.ACK.HISTORY}.

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

Existující šablony se upgradem Zabbixu automaticky nepřepíšou. Nové verze je potřeba naimportovat a porovnat s vlastními úpravami. HTTP šablony nyní standardně ověřují TLS certifikát cíle; u interní certifikační autority nejprve vyřešte její důvěryhodnost. Aktualizované OS šablony s vfs.fs.get[short] a vfs.fs.get[full,{#FSNAME}] vyžadují Zabbix agenta 8.0 nebo novějšího.

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 a logy proxy), OpenRouter traces by OTLP (průběh a chybovost požadavků na modely).
• Cloud a náklady: AWS Backup Vault by HTTP, Oracle Cloud Costs by HTTP, GCP Cost Monitoring by HTTP, GCP Cloud Storage Bucket 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 Failover Cluster by SSH a Microsoft Hyper-V Standalone by SSH
• Aplikace a AI: OpenAI Platform by HTTP, Claude API by HTTP, GitHub organization by HTTP (včetně Copilotu), GLPI by HTTP
• Síť: Aruba CX 8300s by SNMP, Cisco Secure Firewall Threat Defense by HTTP, Ciena 3906 by SNMP, Stormshield SNS by SNMP, Vyatta Virtual Router by SNMP, 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 RDAP by HTTP, webhook pro IBM Maximo (zakládání service requestů)

Aktualizované šablony:

• AIX, FreeBSD, HP-UX, Linux, macOS, OpenBSD, Solaris a Windows: 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 a GitHub organization 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)
• 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, RabbitMQ (drobné opravy)
• Aktualizované dashboardy: Kubernetes Cluster a Node by HTTP, Podman by HTTP a Proxmox VE by HTTP. Zabbix server health má přepracovaný přehled stavu serveru a jeho procesů. Linux by SNMP upravuje discovery filtry EtherLike-MIB.

Windows by Zabbix agent a agent active rozšiřují monitoring o naplánované úlohy, profily Windows Firewallu a svazky chráněné BitLockerem. Linux by Prom a Linux by SNMP mají také upravené dashboardy.

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.

The post Nový Zabbix 8.0 LTS je zde! appeared first on initMAX s.r.o..

Nejdůležitější praktická informace je ale jiná: centrální komponenty Wazuh 4.x se na Wazuh 5.x neupgradují přímo na místě. Přechod znamená čerstvou instalaci nového prostředí vedle původního, ruční přenos či nové nastavení kompatibilní konfigurace a postupné přepojení agentů. Nejde tedy o běžnou aktualizaci balíčků, ale o migrační projekt.

Pozor: historická data z Wazuhu 4.x do nového Wazuhu 5 nepřenesete podporovaným migračním postupem. V novém systému začínáte se sběrem událostí a nálezů od nuly. Pro popisovanou verzi 5.0.0 Beta 5 výrobce neposkytuje podporovaný přenos těchto dat ani přes snapshot/restore či reindex. Viz oficiální omezení migrace.

Stará data tím sama o sobě nezmizí, ale pro jejich dohledávání je nutné zachovat původní indexer a dashboard 4.x jako oddělené prostředí pro čtení. Staré indexy ani potřebné 4.x prostředí proto při přechodu nemažte.

Šest změn, které jsou pro správce a analytiky nejdůležitější

Srovnání vychází z celé řady Wazuh 4.x včetně 4.14.7, nikoli jen z původního vydání 4.0. U známých funkcí rozlišujeme, co pětka skutečně přidává a kde mění jejich implementaci, konfiguraci nebo způsob používání.

• Správa událostí a incidentů přímo ve Wazuhu. Case Management přidává k nálezu stav, prioritu, popis a komentáře. Pro tento základní workflow už není nutné otevírat samostatný ticket v jiném systému.
• HTTPS a důvěra mezi agentem a managerem. Nový transport mění požadavky na konfiguraci obou stran. Serverový certifikát je nutný, ale ověřování protistrany nelze automaticky předpokládat: v Beta 5 má agent bez konfigurace <ssl> výchozí režim none. Bezpečný přechod vyžaduje připravit důvěru a ověřování, případně klientské certifikáty, podle zvoleného režimu.
• Nová instalace bez přenosu historie: v systému 5.x začíná sběr dat od nuly. Podle migračního postupu pro Beta 5 se přenáší kompatibilní konfigurace, nikoli historická indexovaná data. Původní indexer a dashboard 4.x zachovejte pro čtení historie; nové prostředí 5.x vybudujte vedle nich.
• Nové psaní a testování vlastních pravidel. XML dekodéry a pravidla se nepřenesou pouhým přejmenováním souborů. Mění se syntaxe, normalizovaná pole i workflow: YAML dekodér, Sigma kompatibilní pravidlo a oddělené prostory Draft → Test → Custom. Je nutné ověřit parsování i pozitivní a negativní detekční scénář.
• Plánovaný reporting v nové reportovací vrstvě. Plán a notifikace zjednodušují předávání výsledků, ale odkaz na report není totéž co hotové PDF v e-mailové příloze. Samotný PDF/CSV export není novinkou pětky; přestavuje se reportovací workflow a jeho konfigurace. U Beta 5 navíc výrobce uvádí chybu chybějící patičky ve výsledném PDF.
• Manager pracuje jako cluster i s jediným uzlem. Sjednocuje se výchozí provozní model. V initMAX tento přístup používáme dlouhodobě; jeden uzel ovšem sám o sobě nezajišťuje vysokou dostupnost.

Wazuh 5.0 se blíží. Článek popisuje změny ve verzi 5.0.0 Beta 5. Finální vydání může přinést další úpravy; předběžná verze není určena pro produkční nasazení.

S nasazením a přechodem na novou verzi vám pomůžeme od návrhu architektury po ověření vlastních pravidel. Praktické ukázky připravujeme také do našich webinářů.

Proč je Wazuh 5.0 skutečně nová generace

V hlavní alertové cestě Wazuh 4.x manager přijímá data od agentů, dekóduje je, porovnává s pravidly a vytváří alerty. Filebeat následně čte soubor s alerty a posílá dokumenty do indexeru pro zobrazení v dashboardu. Ne všechna data však ve 4.x procházejí Filebeatem: indexer connector už existuje například pro stavová data zranitelností a novějšího inventáře. Pětka zásadně mění právě cestu bezpečnostních událostí a místo, kde se nad nimi vyhodnocují pravidla.

Ve Wazuh 5.0 je tok rozdělen do dvou hlavních analytických vrstev:

• Normalizační engine ve Wazuh manageru přijme surovou událost, vybere správnou integraci a dekodéry, rozparsuje data, převede je do Wazuh Common Schema a případně je obohatí o GeoIP, ASN nebo IOC kontext.
• Detekční engine ve Wazuh indexeru vyhodnotí normalizovaná data pomocí Sigma kompatibilních pravidel a detektorů. Pokud podmínky odpovídají, vytvoří finding – bezpečnostní nález, který v nové architektuře přebírá roli alertu z Wazuh 4.x.

Základní tok tedy vypadá takto:

Rozdělení není jen interní refaktoring. Ovlivňuje formát pravidel, indexy, názvy polí, provozní metriky, retenci dat, vlastní dashboardy i způsob reakce na incident. Skript, který ve 4.x četl alerts.json, dashboard postavený nad wazuh-alerts-* nebo automatizace závislá na číselné hodnotě rule.level se bez úprav do nové architektury nepřenese.

Událost a finding už nejsou totéž

Wazuh 5.0 důsledně odděluje událost od výsledku detekce. Událost je normalizovaný záznam toho, co se ve sledovaném prostředí stalo. Finding vznikne až tehdy, když detektor najde shodu s pravidlem. Jedna událost může projít více aktivními politikami a vytvořit více nálezů, pokud odpovídá více detekčním pravidlům.

Toto rozdělení zlepšuje dohledatelnost. Analytik může pracovat s kompletním normalizovaným proudem událostí, ale současně má oddělenou datovou vrstvu pro bezpečnostní nálezy. Finding obsahuje původní událost, informace o pravidle, závažnost, vazby na MITRE ATT&CK a compliance a případně také data pro správu případu.

Provozní dopad je významný: při hledání v Discoveru nebo při návrhu dashboardu je potřeba vědět, zda chceme procházet všechny události, nebo pouze nálezy. Dotaz nad wazuh-events* odpovídá na jinou otázku než dotaz nad wazuh-findings*.

Co to znamená v praxi

• Týmy získají čistší hranici mezi sběrem a detekcí.
• Pravidla pracují nad normalizovaným schématem místo nad různorodými poli jednotlivých produktů.
• Vlastní integrace, dekodéry a pravidla se spravují jako obsah s řízeným životním cyklem.
• Detekce běží v indexeru, takže návrh a výkon indexerového clusteru budou mít přímý vliv i na rychlost tvorby findings.
• Migrace se musí testovat jako celek – nestačí ověřit pouze spojení agentů s managerem.

Wazuh 5.0 není běžný upgrade balíčků. Pokud potřebujete zjistit, co změna znamená právě pro vaše vlastní dekodéry, pravidla, integrace, retenci a automatizaci, kontaktujte nás. Společně připravíme inventář závislostí a realistický plán přechodu ještě před prvním zásahem do produkce.

Filebeat končí, události posílá nativní indexer-connector

Jednou z nejviditelnějších architektonických změn je odstranění Filebeatu z výchozího toku dat. Wazuh 4.x typicky zapisuje alerty na manageru do JSON souboru a Filebeat je odesílá do indexeru. Wazuh 5.0 používá nativní spojení Wazuh manageru s indexerem prostřednictvím indexer-connector.

Nový tok odstraňuje samostatnou shipper vrstvu a související konfiguraci filebeat.yml, moduly i frontu založenou na čtení alerts.json. Manager zároveň podle dokumentace Wazuh 5.x už alerty z endpointů lokálně neukládá stejným způsobem jako dříve. Normalizované události předává přímo do odpovídajících datových proudů indexeru.

Technická zajímavost: Filebeat v C++? Funkčně je toto přirovnání v oblasti odesílání dat výstižné: Filebeat je napsaný v Go, zatímco nativní indexer-connector je knihovna v C++. Oba řeší dávkování přes Bulk API, frontování, časované odesílání a vyhodnocování položek items v bulk odpovědi. Při HTTP 413 konektor rozdělí dávku nebo sníží její limit podle použitého režimu; dočasné chyby řeší opakováním s prodlužovanou prodlevou. Nejde však o doložený přepis či převzetí kódu Filebeatu ani o shodné garance doručení. Konektor byl součástí už Wazuh 4.x; změnou v pětce je rozšíření jeho role a odstranění samostatného Filebeatu z hlavního toku událostí. Srovnání vychází z implementace a dokumentace konektoru, Go klienta Beats pro Bulk API a konektoru ve Wazuh 4.14.7.

To zjednodušuje počet centrálních komponent, ale mění provozní diagnostiku. Při výpadku dat už administrátor nebude kontrolovat jen stav manageru, velikost alerts.json a Filebeat registry. Bude sledovat:

• dostupnost indexerových uzlů z manageru;
• TLS certifikáty a oprávnění účtu používaného konektorem;
• logy indexer-connector včetně kontextu volajícího modulu;
• stav front a interní watermarks manageru;
• indexovací chyby, mapping konflikty a stav datových proudů v indexeru;
• metriky komunikace a normalizačního enginu na dashboardu.

Beta 5 pro spojení manageru s indexerem definuje služební účet wazuh-manager s omezenou rolí wazuh_manager. Při migraci zkontrolujte účet uložený v manager keystoru a jeho skutečná oprávnění pro nové datové proudy. Přihlašovací údaje administrátora z původní konfigurace není vhodné mechanicky přenášet do běžného sběru dat.

Zdrojový kód ukazuje také provozní rozměry fronty. Výchozí event queue má 131 072 slotů a limit 32 MB, zatímco fronta konektoru do indexeru má 64 MB. Bulk dávka má 8 MB a výchozí flush interval 20 sekund. Orchestrátor samostatně měří zaplnění počtem položek i bajty, počítá zahozené vstupy a po desetiminutové souvislé kontenci nad 90 % zapisuje varování. Tyto hodnoty jsou fallbacky ve zdrojovém tagu, nikoli univerzální sizing; balíček nebo interní konfigurace je mohou přepsat. Pro monitoring jsou podstatné především metriky zaplnění fronty, zahozených událostí a EPS za 1, 5 a 30 minut.

Co se stane s vlastními výstupy

Odstranění Filebeatu neznamená, že Wazuh 5.0 zakazuje integraci s jinými analytickými platformami. Znamená však, že dosavadní konfiguraci nelze automaticky považovat za kompatibilní. Pokud organizace používá upravený Filebeat pipeline, Logstash, vlastní ingest pipeline, kopii alerts.json nebo externí archivaci, musí přesně popsat současný tok a navrhnout jeho nový ekvivalent.

Při návrhu doporučujeme oddělit tři potřeby:

• Provozní data Wazuh 5.0, která zapisuje nativní konektor do nových datových proudů.
• Historická data Wazuh 4.x, pro jejichž dohledávání zůstává původní 4.x prostředí jako oddělený archiv.
• Externí export, například do dlouhodobého archivu, datového jezera nebo dalšího SIEMu, který musí mít vlastní jasně podporovanou cestu.

Wazuh Engine a nový systém Security Analytics

Nová analytická architektura rozděluje práci mezi více komponent. Wazuh Engine v manageru normalizuje a obohacuje události; Security Analytics v indexeru nad nimi vyhodnocuje detekční pravidla. Content Manager spravuje jejich obsah. Nejde tedy o jeden engine přesunutý na jiné místo ani o prosté přepsání původního analysisd. V dashboardu se správa normalizace a detekce soustřeďuje pod Security Analytics.

Bezpečnostní obsah se skládá z několika typů prostředků:

• Integration seskupuje obsah pro konkrétní produkt nebo zdroj logů.
• Decoder rozpozná vstup, rozparsuje jej a namapuje hodnoty do Wazuh Common Schema.
• Rule popisuje detekční podmínky v Sigma kompatibilním YAML formátu.
• Detector propojí pravidla s konkrétním indexem nebo aliasem a spouští jejich vyhodnocování podle plánu.
• KVDB poskytuje seznamy a mapování typu klíč–hodnota pro normalizaci a obohacení.
• Filter rozhoduje, které události projdou do dalších fází pipeline.
• Policy určuje pořadí a chování jednotlivých fází zpracování.

Content Manager: standardní i vlastní obsah na jednom místě

Content Manager je plugin Wazuh indexeru, který udržuje pravidla, dekodéry, integrace, KVDB, filtry a IOC obsah. Stahuje standardní obsah z Wazuh CTI, vystavuje API pro vlastní obsah a synchronizuje změny s managerem, kde běží normalizační část enginu.

Oddělení vlastních pravidel od pravidel výrobce není novinka. Ve 4.x už slouží adresáře etc/rules a etc/decoders pro vlastní obsah, odděleně od dodaného ruleset; správně uložené úpravy proto nemusí upgrade přepsat. Změnou v 5.0 je správa obsahu přes Content Manager a explicitní pracovní cyklus Draft → Test → Custom. Místo přímé editace produkčních XML souborů připravujete nový formát obsahu, ověřujete jeho vazby a řídíte jeho aktivaci.

Content Manager podle současného návrhu pravidelně kontroluje nové verze obsahu. Zároveň umožňuje ruční aktualizaci a instalace indexeru obsahuje snapshoty rulesetu, vulnerability feedu a IOC feedu, aby čerstvě nasazený cluster měl výchozí obsah i bez okamžitého spojení ven.

Co ve skutečnosti probíhá při aktualizaci obsahu

Nejde o prosté přepsání souborů. Výchozí synchronizace Content Manageru běží po 120 sekundách, zatímco IOC a GeoIP obsah se kontrolují po 360 sekundách. Manager nejdřív porovná SHA-256 hash vzdálené politiky s právě nasazenou verzí. Pokud se hash nezměnil, neprovádí žádný reload.

Při změně se obsah stáhne do dočasného namespace, zvaliduje a teprve potom se aktivní route atomicky přepne na novou verzi. Kód obsahuje rollback při chybě importu i při neúspěšném hot-swapu. Synchronizace se navíc vyhne stažení ve chvíli, kdy vzdálený consumer není ve stavu idle, aby nevytvořila snapshot napůl provedené aktualizace.

Obsah lze aktivovat bez restartu celého manageru, ale změna není nutně okamžitá. Samotný hot reload není novinka pětky: analysisd jej pro pravidla, dekodéry a CDB seznamy získal už ve Wazuh 4.13. V 5.0 se mění správa a distribuce obsahu přes Content Manager, jeho validace v oddělených prostorech a přepínání politik normalizačního enginu. Při diagnostice kontrolujte hash, stav consumeru, poslední úspěšnou synchronizaci a skutečně aktivní namespace, nikoli pouze to, že se pravidlo už zobrazuje v dashboardu.

Čtyři spaces: Draft, Test, Custom a Standard

Wazuh 5.0 zavádí čtyři logické prostory:

Vlastní změna prochází cestou Draft → Test → Custom. Content Manager při povýšení zpracuje změny a aktualizuje cílový space. Připravenost normalizačního obsahu je nutné ověřit v enginu; distribuce a aktivace vlastního obsahu nejsou totéž jako zobrazení změny v seznamu. Průběžnou detekci nad uloženými událostmi zajišťuje samostatně nakonfigurovaný detektor. Standardní a vlastní politika zůstávají oddělené, takže lze u každé události identifikovat, zda ji zpracoval standardní nebo vlastní obsah.

Tento workflow je výrazně bezpečnější než přímá editace XML souboru na produkčním manageru. Neodstraňuje ale potřebu verzování a peer review. Doporučujeme vlastní YAML obsah dál uchovávat v Gitu, každou změnu svázat s testovacím logem a do Custom ji povýšit teprve po kontrole očekávaných i negativních scénářů.

Integrace určují vlastnictví a kategorii dat

Integration je nejvyšší organizační jednotka pro související dekodéry, pravidla a pomocný obsah. Každý dekodér patří právě do jedné integrace. Integrace zároveň dostává kategorii, která určuje, do jakého datového proudu se normalizovaná událost zařadí.

Aktuální kategorie jsou:

• access-management pro autentizaci, autorizaci, identity a přístupy;
• applications pro webové servery, databáze, middleware a aplikace;
• cloud-services pro AWS, Azure, GCP a další cloudové služby;
• network-activity pro firewally, proxy, DNS a síťové toky;
• security pro EDR, SIEM feedy, skenery a další bezpečnostní nástroje;
• system-activity pro operační systémy, audit a syslog;
• other pro události, které se nevejdou jinam.
• unclassified pro události, které přijal pouze kořenový dekodér a žádný konkrétní dekodér je nezařadil.

Kategorie se zapisuje do wazuh.integration.category a ovlivňuje routing do datového proudu, například wazuh-events-v5-cloud-services. Nesprávná volba tedy není jen kosmetický problém v seznamu integrací. Promítne se do indexů, detektorů, dashboardů, retence i oprávnění.

Dekodéry přecházejí z XML na YAML a WCS

Ve Wazuh 4.x jsou vlastní dekodéry typicky XML soubory v manageru. Wazuh 5.0 používá YAML assety a malý doménově specifický jazyk. Dekodér má tři hlavní části:

• check ověří, zda má dekodér událost zpracovat;
• parse rozebere vstup pomocí parserových vzorů a odpovídajících parserů; nejde automaticky o regulární výraz;
• normalize namapuje získané hodnoty do polí Wazuh Common Schema.

Na konkrétním SSH logu je dobře vidět, proč nestačí změnit příponu souboru. Standardní dekodér decoder/system-auth/0 převezme výsledek syslog parsování, rozpozná zprávu sshd a nastaví normalizovanou akci. Následující výřez pochází z jeho části normalize; nejde o samostatný importovatelný dekodér:

normalize:
  - check: $_system.auth.ssh.event == Invalid OR $_system.auth.ssh.event == Failed OR $_system.auth.ssh.event == failures OR $_system.auth.ssh.event == fatal OR $_system.auth.ssh.event == exceeded OR $_system.auth.ssh.event == Disconnecting
    map:
      - event.action: authentication-failure
      - event.category: array_append(authentication)
      - event.outcome: failure
      - event.type: array_append(info)

Například SSH zpráva Failed password for invalid user demo-admin from 203.0.113.10 port 51234 ssh2 se standardním dekodérem normalizuje na event.action: authentication-failure, event.outcome: failure, user.name: demo-admin a source.ip: 203.0.113.10. Nad těmito poli pracuje detekční pravidlo. Dočasné pole _system.auth.ssh.event do výsledného dokumentu nepatří — pomocné hodnoty s podtržítkem slouží při dekódování, nikoli jako veřejné schéma události.

Přímý převod starého XML do YAML není pouze syntaktická změna. U každého dekodéru je nutné znovu rozhodnout:

• který vstup skutečně přijímá;
• do jaké integrace a kategorie patří;
• která pole mají WCS ekvivalent;
• co zůstane pouze v event.original;
• zda má událost dostat GeoIP nebo IOC obohacení;
• která pravidla a dashboardy jsou na původních názvech polí závislé.

Log Test ověřuje normalizaci i detekci

Nový Log Test je rozdělený podle skutečného toku dat. Nejdřív ukazuje, jaké dekodéry přijaly nebo odmítly vstup a jak vypadal normalizovaný dokument. Poté lze ověřit pravidla a výslednou detekci. Test pracuje s obsahem v Test, Custom a Standard space, takže před nasazením vidíme nejen syntaktickou validitu, ale také interakci s již aktivním obsahem.

K dobrému testu nepatří pouze jeden vzorový log, který musí projít. Pro každou integraci doporučujeme připravit:

• platné události pro všechny důležité varianty formátu;
• neplatné nebo nesouvisející události, které dekodér přijmout nesmí;
• hraniční hodnoty, chybějící pole a neobvyklé kódování;
• očekávaný normalizovaný JSON;
• očekávaná pravidla a závažnost findings;
• regresní vzorky pro dříve opravené false positive a false negative případy.

Vlastní dekodér a pravidlo: od textového logu k nálezu

Na jednoduchém přihlášení do vlastní aplikace je vidět celý nový postup. Schopnost napsat vlastní dekodér a pravidlo měl už Wazuh 4.x. V pětce se mění syntaxe, normalizovaná pole a práce s obsahem v Draft, Test a Custom; průběžnou detekci navíc propojuje s datovým zdrojem samostatný detektor. Následující ukázka odpovídá rozhraní 5.0.0 Beta 5.

Použijeme dvě zprávy se stejným formátem. První popisuje neúspěšné přihlášení, druhá úspěšné. Obě mají být dohledatelné jako události, ale nález má vzniknout pouze pro result=failure. Jednotlivé neúspěšné přihlášení samo o sobě není důkaz útoku ani detekce brute force.

Sep 10 12:00:00 app01 initmax-auth: user=alice src=192.0.2.10 result=failure
Sep 10 12:00:00 app01 initmax-auth: user=alice src=192.0.2.10 result=success

Příprava integrace a dekodéru v Draft

V Security Analytics → Overview vyberte Draft a v seznamu Integrations otevřete vytvoření integrace. Zadejte název initmax-auth-demo, kategorii access-management, autora a ponechte integraci zapnutou. V Normalization → Decoders vytvořte dekodér přiřazený k této integraci a vložte následující definici:

name: decoder/initmax-auth/0
enabled: true
metadata:
  title: initMAX authentication decoder
  author: initMAX
  description: Parses the user, source IP and result from an example application log.
  references: []
check:
  - event.original: contains(initmax-auth:)
parse|event.original:
  - '<_tmp.header> initmax-auth: user=<user.name> src=<source.ip> result=<event.outcome>'
normalize:
  - map:
      - '@timestamp': get_date()
      - event.kind: event
      - event.category: [authentication]
      - event.action: user-login

check vybírá zprávy obsahující initmax-auth:. Blok parse|event.original používá parserový vzor Logpar s pojmenovanými poli — nejde o regulární výraz ze starého XML dekodéru. Výsledkem jsou user.name, source.ip a event.outcome. Normalizace doplní event.action: user-login a kategorii authentication; pomocné pole _tmp.header se do výsledného dokumentu nepřenáší.

Příklad záměrně předpokládá pevné pořadí polí. Funkce get_date() nastavuje čas zpracování, nikoli čas ze syslog hlavičky. Pro skutečnou aplikaci doplňte zpracování jejího timestampu a variant vstupu; tento krátký dekodér není univerzální parser všech autentizačních logů.

V Overview → Draft → Actions → Edit musí být zapnutá politika space a nastavený kořenový dekodér. Tato samostatná ukázka používá jako Root Decoder decoder/initmax-auth/0. V existující instalaci nepřepisujte její kořenovou politiku tímto příkladem: jde o nastavení společné pro space, ne jen pro jednu položku v seznamu. Nový dekodér je potřeba začlenit do stávajícího stromu a při povyšování zkontrolovat i ostatní změny.

Pravidlo nad normalizovanými poli

V Security Analytics → Detection → Rules ponechte Draft, zvolte vytvoření pravidla, integraci initmax-auth-demo a YAML editor. Níže je vlastní definice; automaticky spravované identifikátory a data vytvoření se mezi instalacemi liší a nejsou součástí detekční podmínky. Pokud editor obsahuje pole id, ponechte identifikátor svého pravidla.

enabled: true
status: experimental
metadata:
  title: initMAX application login failure
  author: initMAX
  description: Detects a failed login to the example application. A single failure is not proof of an attack.
  references: []
logsource:
  product: initmax-auth-demo
detection:
  selection:
    event.action: user-login
    event.outcome: failure
  condition: selection
level: low

Pravidlo nekontroluje původní řetězec result=failure, ale pole vytvořená dekodérem. Musí současně odpovídat akce user-login i výsledek failure. Závažnost low odpovídá jednoduchému nálezu, který může být i běžnou chybou uživatele; pravidlo nepočítá opakované pokusy ani časové okno.

Povýšení do Test a pozitivní i negativní kontrola

V Overview otevřete Actions → Promote pro Draft, prohlédněte celý seznam změn a potvrďte povýšení do Test. Poté v Log Test vyberte Test a integraci initmax-auth-demo. Vkládejte vždy jednu zprávu a kontrolujte nejen normalizovaný dokument, ale také výsledek detekce:

• result=failure: pole se rozparsují a odpovídá jedno pravidlo — initMAX application login failure.
• result=success: pole se rozparsují, ale vlastní pravidlo neodpovídá.
• Zpráva s jiným názvem aplikace: vlastní dekodér ji nepřijme.
• src=not-an-ip: parser neprojde a nevznikne odpovídající nález. Samotná úspěšná odpověď API není důkaz úspěšné normalizace.

Po úspěšné kontrole povyšte změny z Test do Custom. Náhled musí obsahovat právě zamýšlenou politiku, integraci, dekodér a pravidlo. Počkejte na aktivaci vlastního obsahu a zopakujte pozitivní i negativní Log Test v Custom. Výsledek v Log Testu ještě sám o sobě nedokazuje, že běží průběžná detekce nad daty od agentů.

Aktivní detektor a skutečný sběr z agenta

V Security Analytics → Detection → Detectors → Create detector vytvořte detektor s těmito parametry:

• Name: initMAX authentication demo.
• Data source: wazuh-events-v5-access-management — datový proud odpovídající kategorii integrace.
• Space / Integration: Custom / initmax-auth-demo.
• Selected rules: pouze initMAX application login failure.
• Run every: 1 minute. Pro tuto ukázku nejsou nastavené notifikace ani Active Response.

Po vytvoření ověřte stav Active a seznam aktivních pravidel. Na agentovi musí být nastavený běžný sběr aplikačního logu. Pro soubor v této ukázce je to následující blok uvnitř ossec_config v lokálním ossec.conf; při centrální správě patří do příslušné sdílené konfigurace skupiny. Soubor musí existovat a být pro sběrač čitelný. Není nutné kvůli samotné tvorbě dekodéru přepisovat celé nastavení agenta.

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/initmax-demo.log</location>
</localfile>

Do sledovaného souboru nyní nechte aplikaci zapsat nové zprávy s výsledkem failure a success. Detektor je vyhodnocuje podle svého intervalu, takže nečekejte nález synchronně s odesláním logu. V této ukázce zůstaly v datovém proudu dvě události a vznikl jeden nález pro neúspěšné přihlášení. Nález odkazuje na původní dokument pomocí event.index a event.doc_id a zachovává identitu agenta i event.original. Úspěšné přihlášení vlastní nález nemá.

V Threat Hunting → Findings výsledek omezíte dotazem wazuh.integration.name : "initmax-auth-demo". Pro kontrolu úspěšné zprávy je potřeba prohlédnout také proud událostí, nikoli pouze Findings. Tím se uzavírá celý řetězec: sběr logu → vlastní dekodér → WCS událost → naplánovaný detektor → finding.

Podrobnosti k ovládání jednotlivých částí: normalizace a práce se spaces a pravidla a detektory v dokumentaci Beta 5.

Wazuh Common Schema: nový společný jazyk pro bezpečnostní data

Wazuh Common Schema, zkráceně WCS, je základ nové datové vrstvy. Staví na ECS a ve Wazuh 5.0 se připravuje na ECS 9.1.0. Cílem je, aby stejné informace měly stejné názvy a datové typy bez ohledu na to, zda pocházejí z Windows Event Logu, firewallu, cloudové služby nebo vlastní aplikace.

Příklad je jednoduchý: zdrojová IP adresa nemá být v jednom produktu srcip, v jiném source_address a ve třetím client.ip. Dekodér ji namapuje do standardního pole source.ip. Díky tomu může stejné Sigma pravidlo, vizualizace nebo IOC enrichment pracovat nad více integracemi.

WCS se neomezuje na síťová pole. Obsahuje normalizované oblasti pro událost, proces, soubor, uživatele, hostitele, cloud, DNS, registry, zranitelnosti, compliance i Wazuh metadata. Pro původní log je určené event.original. Jeho zachování však závisí na dekodéru a dalších transformacích; nejde o bezpodmínečnou garanci archivu. Rozdíl mezi běžnou normalizací, raw sběrem a helperem discard_events() popisujeme níže.

Nové názvy polí ovlivní dotazy i dashboardy

Wazuh metadata se přesouvají pod namespace wazuh.*. Některé změny jsou přímočaré, jiné mění i typ hodnoty. Migrační dokumentace uvádí například:

U rule.groups neexistuje univerzální náhrada. Podle účelu filtru se používá například wazuh.integration.name nebo jiná WCS metadata. Závažnost rule.level se navíc mění z čísla 0–16 na slovní úroveň: informational, low, medium, high nebo critical.

Nejnebezpečnější je změna rule.level. Dotaz rule.level >= 10 nemá v 5.x přímý ekvivalent, protože úroveň je kategoriální. Je potřeba přepsat filtry, alertovací podmínky, severity mapování i vlastní vizualizace podle nového modelu.

Datové proudy podle kategorie a účelu

Místo jednoho hlavního index patternu přichází několik rodin datových proudů. Mezi nejdůležitější patří:

• wazuh-events-v5-{category} pro normalizované události;
• wazuh-findings-v5-{category} pro výsledky detekce;
• wazuh-events-raw-v5 pro volitelnou indexaci surových událostí;
• wazuh-active-responses pro požadavky na aktivní reakci;
• wazuh-metrics-* pro telemetrii agentů, komunikace a normalizace;
• wazuh-states-* pro stavová data, například inventář, SCA, FIM a zranitelnosti.

Časové řady používají data streams s index templates a Index State Management politikami. Setup plugin je při startu indexeru vytváří spolu s výchozími rolemi a nastavením. ISM se stará o rollover a odstranění starých dat podle stáří nebo velikosti. Pro indexy vytvářené Wazuh pluginy je připravený výchozí zstd kodek, který má snížit nároky na úložiště za cenu určitého výpočetního overheadu.

Oddělení kategorií umožňuje nastavit jinou retenci nebo oprávnění pro cloudové události, systémovou aktivitu a bezpečnostní nálezy. Současně ale zvyšuje význam dobrého indexového návrhu. Široký pattern wazuh-events* je pohodlný pro průzkum, ale u náročných dashboardů je vhodné dotaz zúžit na skutečně potřebné kategorie.

Výchozí retence ze sestavených index templates

Kontrola hotových JSON artefaktů ve zdrojovém tagu Wazuh Indexer Plugins Beta 5 odhaluje důležitý detail: výchozí retence se mezi proudy výrazně liší.

Rollover má v těchto politikách práh velikosti primárního shardu 20 GB nebo 200 milionů dokumentů; u AI sessions také podmínku stáří jeden den. Jde o podmínky vyhodnocované plánovačem, nikoli o přesný časovač. Akce mají tři pokusy s exponenciálním backoffem začínajícím na jedné minutě.

Tyto hodnoty nejsou TTL jednotlivých událostí. ISM nejdříve dokončuje akce aktuálního stavu a až potom vyhodnocuje přechod do dalšího stavu. Pokud index čeká na objemový rollover, samotné uplynutí jedné hodiny nemusí spustit jeho smazání. Stáří indexu navíc není totéž jako stáří každého dokumentu. Efektivní doba uchování proto závisí na rolloveru, stáří backing indexu, intervalu plánovače a úspěchu akcí. Před produkcí ověřte aktivní politiku i stav přes ISM Explain a nastavte časový rollover a retenční cíle podle požadavků organizace. Krátká podmínka pro events je varování pro forenzní návrh, nikoli důkaz, že všechny logy automaticky zmizí přesně za hodinu. Jak ISM vyhodnocuje akce a přechody.

Stejně zajímavá je struktura mapování. Template pro events obsahuje 2 299 dynamických field šablon a findings 2 345, přesto mají mapping.total_fields.limit nastavený na 1 000. Není to rozpor: konkrétní mapping se vytvoří líně až při prvním použití pole a staticky zůstává jen základní objektová kostra. Tím Wazuh drží široké WCS pod limitem jednoho indexu, ale současně vzniká důvod sledovat skutečný počet použitých polí a zabránit nekontrolované field explosion z vlastních integrací.

Hotové templates dále nastavují jeden primární shard, auto_expand_replicas v rozsahu 0-1, kodek zstd a refresh interval dvě sekundy pro events a findings. To jsou rozumné instalační defaulty, nikoli automaticky správný návrh pro víceuzlový produkční cluster. Počet shardů, replik, refresh interval i ISM se musí odvodit od EPS, velikosti dokumentu, retenčního cíle a požadovaného RPO.

Surové a zahozené události

Archivace vstupních logů ani filtrování nejsou nové schopnosti. Ve 4.x už existují archivy řízené například logall/logall_json a rozpoznávání událostí pomocí parent, prematch, regex a pravidel. V 5.0 se mění jejich zapojení do normalizační pipeline: samostatné filtry mohou rozhodovat před dekódováním i po obohacení a politika řídí také zacházení s událostmi označenými jako discarded.

Pokud událost neprojde pre-filtrem, dekodéry se pro ni vůbec nespustí. Post-filter rozhoduje až po dekódování a obohacení, zda smí pokračovat do výstupů. To není totéž jako rodičovská vazba dekodéru: ta vybírá rozpoznávání vstupu, zatímco filtr omezuje průchod celou danou politikou.

Rozdíl je vidět na vlastní integraci initmax-auth-demo z předchozí ukázky. Dekodér převádí result=failure na event.outcome: failure. Při stejném vstupu a jediném aktivním filtru v dané fázi vychází:

• Pre-filter $event.outcome == failure: zprávu nepustí k dekodéru, protože toto pole před dekódováním ještě neexistuje. Z této vlastní politiky nevznikne normalizovaná událost ani nález.
• Post-filter $event.outcome == failure: po dekódování podmínka platí. Událost se uloží a navazující detektor vytvoří jeden nález podle vlastního pravidla.
• Post-filter $event.outcome == success: dekodér zprávu zpracuje, ale filtr ji nepustí do výstupu. Událost ani nález z této politiky nevzniknou, a to ani při index_discarded_events: true.

Raw sběr je samostatný. Pokud je aktivní engine.index_raw_events, může vstup zůstat v wazuh-events-raw-v5 i při odmítnutí pre-filtrem nebo post-filtrem. Není však automaticky plnotextově prohledávatelný: výchozí šablona raw streamu v Beta 5 ukládá event.original do dokumentu, ale má pro něj index: false a doc_values: false. Záznam proto nejprve omezte podle času, agenta nebo ID události a potom otevřete jeho původní obsah.

index_discarded_events není záchranná síť pro všechny zahozené logy. Hodnota false zastaví po dekódování událost označenou wazuh.space.event_discarded: true; hodnota true jí dovolí pokračovat. Neobchází však pre-filter ani post-filter a nezaručuje přijetí dokumentu indexerem. Rozhodující je pořadí fází normalizační pipeline i platnost výsledného dokumentu.

Úskalí Beta 5: helper discard_events() není pouhé nastavení příznaku. Při index_discarded_events: true odstraní dosavadní pole dokumentu a nastaví discarded. Pokud ho v uvedeném dekodéru použijete na konci normalizace, zmizí i @timestamp a původní log. Následné automatické doplnění údajů o integraci čas neobnoví: indexer takový dokument odmítne kvůli chybějícímu povinnému timestampu. Samotným zapnutím volby proto archiv zahozených událostí nevytvoříte; zachování původního vstupu řeší oddělený raw sběr.

Log Test není potvrzení zápisu ani vzniku nálezu. V Beta 5 může vrátit shodu pravidla i tehdy, když trace ukazuje neúspěšný post-filter nebo zastavení discarded události. Testovací služba vyhodnocuje normalizovaný výstup samostatně; při průběžném sběru se odmítnutý dokument k detektoru nedostane. Kontrolujte proto celý trace a po aktivaci politiky také skutečnou událost a nález v indexeru.

Před zapnutím raw sběru nebo ukládání discarded událostí spočítejte EPS, velikost průměrné zprávy, retenci a dopad na počet shardů. Diagnostická funkce bez omezené retence se může rychle změnit v problém s diskem.

Nejste si jistí sizingem a retencí? Návrh Wazuh 5.0 se musí opřít o skutečné EPS, velikost dokumentů a požadovanou dobu dohledatelnosti. Ozvěte se nám a připravíme kapacitní návrh i bezpečné výchozí politiky pro vaše prostředí.

Nová pravidla: Sigma kompatibilní YAML místo XML

Wazuh 5.0 přesouvá detekční pravidla k Sigma formátu. Pravidlo obsahuje standardní bloky detection a logsource, Wazuh metadata, závažnost a volitelné mapování na MITRE ATT&CK a compliance. Podporované jsou běžné Sigma operátory i Wazuh rozšíření, například dynamické dosazení polí z události do výsledného nálezu.

Detekční podmínka musí odpovídat skutečnému výstupu dekodéru. Následuje zkrácený výřez standardního pravidla pro neúspěšnou autentizaci; plná definice navíc obsahuje mapování na compliance a MITRE ATT&CK:

id: 42532ad3-3951-57ee-a3a3-bc6a1b9e6e72
status: stable
level: low
logsource:
  product: wazuh-generic-1
  service: authentication
metadata:
  title: "Failed authentication attempt - {{user.name}} from {{source.ip}}"
detection:
  selection:
    event.action: authentication-failure
    event.category: authentication
    event.kind: event
  condition: selection

Jde o shodu s jednou událostí, nikoli o důkaz brute-force útoku. Opakování v časovém okně, počet pokusů a vazbu na konkrétní IP nebo účet je nutné vyhodnotit samostatně. I proto má toto standardní pravidlo závažnost low; překlep v hesle sám o sobě není kritický incident.

Konkrétní pole musí existovat ve WCS. Pokud pravidlo odkazuje na neplatné pole, engine ho při validaci odmítne a vrátí strukturovanou chybu. To je důležitý posun proti pravidlům, která se sice načetla, ale nikdy nemohla odpovídat kvůli překlepu nebo jinému názvu pole.

Wazuh implementace podporuje například modifikátory contains, startswith, endswith, cidr, exists, porovnání lt, lte, gt, gte a práci se seznamy. logsource organizuje pravidlo podle produktu, kategorie a služby, ale samotnou shodu určuje blok detection.

Závažnost už není číslo 0 až 16

Pravidla používají slovní úrovně informational, low, medium, high a critical. Je to čitelnější pro analytiky a lépe kompatibilní s novým schématem, ale jde o breaking change pro automatizace založené na numerické hranici.

Pohled initMAX: na slovní úrovně jako interní reprezentaci závažnosti se po zkušenostech se Zabbixem díváme skepticky. Pro výpočty, porovnávání a návazné automatizace nám dává větší smysl číselná hodnota se srozumitelným názvem ve frontendu. Odhadujeme, že se Wazuh může časem k číselné reprezentaci vrátit; jde ale pouze o náš názor a odhad, nikoli o oznámený plán Wazuhu. Současné integrace je nutné navrhovat podle dnes používaných slovních úrovní.

Při migraci nestačí mechanicky prohlásit například všechny staré úrovně 10 až 12 za high. Je vhodné zohlednit účel pravidla, spolehlivost detekce, dostupný kontext a reakci, která na nález navazuje. Stejnou mapu pak musí používat dashboardy, notifikace, SLA a případné napojení na ticketovací systém.

Detektory oddělují pravidlo od datového zdroje

Pravidlo popisuje, co hledáme. Detector určuje, nad jakým indexem nebo aliasem se pravidla vyhodnocují a jak často. Wazuh dodává standardní detektory. Pro vlastní obsah lze vytvořit detektor nad vybraným datovým proudem a sadou pravidel.

Detektory běží v naplánovaných intervalech, takže dokumentace hovoří o detekci v téměř reálném čase, nikoli o synchronní shodě přímo při příjmu logu. Skutečnou latenci ovlivní interval, indexační zpoždění, počet pravidel, objem dat a zatížení indexeru.

Detektor může pracovat buď se Standard, nebo s Custom space; obě sady nelze v jednom detektoru míchat. Aktuální plugin také používá konfigurovatelné limity počtu pravidel na detektor a počtu uživatelských detektorů. Při návrhu větší knihovny proto dává smysl seskupovat pravidla podle logsource a kategorie a měřit čas jednotlivých běhů.

Findings nahrazují alerty

Výsledkem shody je finding. Obsahuje plnou zdrojovou událost a metadata pravidla pod wazuh.rule, například ID, titul, úroveň, stav, MITRE a compliance. Enriched findings se ukládají do wazuh-findings-v5-{category}.

Je důležité rozlišit dva kroky. Security Analytics nejdřív vytvoří interní záznam o shodě a poté ho asynchronně obohatí o zdrojový dokument a pravidlo. Obohacení nemá blokovat primární detekční cestu. Při diagnostice chybějícího detailu je proto nutné kontrolovat nejen samotný detector, ale i následnou enrichment a bulk-indexaci do Wazuh findings streamu.

CTI, GeoIP a IOC enrichment přímo v analytické pipeline

Wazuh CTI slouží jako zdroj vulnerability feedu už od přepracování Vulnerability Detection ve Wazuh 4.8; není to nově připojený katalog zranitelností. V 5.0 se jeho role rozšiřuje na distribuci standardního detekčního obsahu a IOC přes Content Manager v indexeru. Pro správce se mění hlavně cesta aktualizací a obsah, který je nutné synchronizovat do analytické pipeline.

Normalizovaná událost může před uložením projít obohacením. GeoIP vrstva doplní k source.ip nebo destination.ip zemi, region, město, souřadnice, časové pásmo a ASN. IOC vrstva porovná podporovaná pole s feedem známých indikátorů – IP adresami, doménami, URL nebo hashi – a přidá kontext pod wazuh.threat.

Obohacení nevzniká pro každý vstup. U interní nebo dokumentační IP nemusí být země ani reputační kontext k dispozici. V našem SSH scénáři používáme dokumentační adresy, takže jejich přítomnost v nálezu není ukázkou skutečné GeoIP ani IOC shody.

IOC enrichment je augmentace, ne samostatný verdikt. Shoda s feedem přidá kontext, ale událost dál prochází pravidly. Detekce tak může kombinovat reputaci indikátoru s typem aktivity, aktivem, uživatelem a dalšími poli. Pro analytika je současně důležité vidět poskytovatele, první a poslední výskyt a konkrétní pole, které shodu vyvolalo.

Vulnerability Detection používá indexer jako autoritativní zdroj

Agent dál sbírá inventář operačního systému, balíčků a hotfixů a komunikuje s managerem. Ani ve 4.x nepotřeboval kvůli Vulnerability Detection přímý přístup k CTI. Změna v 5.0 je na centrální straně: CVE obsah z CTI spravuje indexer a manager na něj navazuje. Synchronizace rozlišuje první scan, změny inventáře a aktualizace feedu. Internetový přístup jednotlivých endpointů tím není novou podmínkou.

Konkrétní novinkou proti 4.14.7 je zpracování skóre CVSS 4.0: dřívější scanner vybíral mezi CVSS 3.1, 3.0 a 2.0; implementace 5.0 upřednostňuje dostupnou metriku 4.0. Datový model CVE 5 přitom existoval už ve 4.x — pětka ho rozšiřuje o další pole, nezavádí ho od nuly. U vlastních exportů ověřte verzi použitého skóre, vazbu na balíček a změny stavu po aktualizaci inventáře; samotný počet zranitelností změnu nevystihuje.

Active Response se konfiguruje v dashboardu

Spouštění reakcí na agentech existovalo už ve 4.x. Mění se jejich řízení: místo bloků <command> a <active-response> v konfiguraci manageru definujete reakci v Explore → Active Responses a připojíte ji ke spouštěcí podmínce monitoru typu Active Response v Alertingu. Monitor vytvoří požadavek v indexeru, manager z něj připraví úlohu pro agenta a wazuh-execd na cílovém endpointu spustí místní program. Dashboard ani indexer tento program za agenta nevykonává.

Při vytvoření reakce se vybírá:

• název a popis;
• spustitelný soubor a volitelné argumenty;
• umístění – agent, který událost vytvořil (Local), konkrétní ID (Defined agent), nebo všichni agenti (All);
• typ – jednorázový stateless, nebo stateful, u kterého musí skript umět provedení i následné odvolání akce;
• timeout u stateful reakce;
• následně v Alertingu podmínku a trigger, který vybranou reakci vyvolá.

Vytvoření reakce v dashboardu nedistribuuje její skript. Spustitelný soubor musí na cílovém agentovi už existovat v adresáři pro Active Response; jeho nasazení, oprávnění a závislosti dál zajišťuje vaše automatizace nebo správa balíčků. To není podmíněné kopírováním starých XML bloků do manageru 5.x. Vlastní skript navíc musí zpracovat nový JSON kontrakt s metadaty wazuh.active_response a odpovídající pole události.

Vlastní skripty používající JSON kontrakt 4.x vyžadují úpravy. V 5.0 Beta 5 dostanou přes standardní vstup JSON s příkazem enable pro provedení a disable pro odvolání; dříve šlo o add a delete. Údaje čtou z WCS polí, například source.ip, nikoli ze starého parameters.alert.data.srcip. Volitelné argumenty jsou v wazuh.active_response.extra_arguments, ne v argumentech příkazové řádky. Podrobnosti uvádí migrační kontrakt Active Response.

Volba All je stejně riziková jako dříve: chybný skript nebo příliš široká podmínka může zasáhnout celé prostředí. Nejprve proto ověřte detekci monitorem s pouhou notifikací, bez připojené aktivní reakce. Potom vyzkoušejte reakci na konkrétním testovacím agentovi. U stateful akce musí skript správně obsloužit příkazy enable a disable; timeout sám neumí vrátit libovolnou změnu. Ověřte také opakovanou shodu během aktivního zásahu.

U stateful skriptu záleží také na protokolu check_keys: agent vrací continue nebo abort. Pokud skript klíče neodešle, wazuh-execd jej nezařadí do seznamu pro pozdější odvolání. Opakovaný stejný klíč během aktivního zásahu zabrání opětovnému provedení a obnoví začátek timeoutu. Návrat proto neodvozujte pouze od času prvního nálezu. Toto chování řídí lokální daemon agenta.

Co to znamená v praxi

Provozní cesta je nyní definice v dashboardu → trigger v Alertingu → požadavek v indexeru → Task Manager na manageru → HTTPS řídicí kanál agenta → místní wazuh-execd. Musí fungovat všechny tyto části, nejen samotný skript. Běžný e-mailový či webhookový kanál Notifications není podmínkou aktivní reakce: v triggeru jde o samostatnou akci Add active response, odlišnou od Add notification. Podrobnosti ukazuje zapojení Active Response do monitoru.

Stav úlohy delivered není potvrzení úspěšné reakce. Znamená předání agentovi; skript přesto může skončit chybou. Úspěch potvrďte až podle jeho logu, skutečného účinku na endpointu a u stateful akce také následného odvolání.

AI Assistant přichází přímo do Wazuh dashboardu

Wazuh AI Assistant přidává konverzační rozhraní nad daty, která analytik může procházet také pomocí existujících dashboardů a vyhledávání. Novinkou tedy není možnost najít odpojeného agenta nebo zranitelnost, ale zadání dotazu přirozeným jazykem, navazující práce s kontextem a slovní shrnutí výsledků. Odpověď je potřeba ověřit proti zdrojovým dokumentům, například v Discoveru.

Nejde pouze o obecný chat vložený do iframe. Assistant má nástroje pro dotazování nad Wazuh datovými plochami a při odpovědi pracuje s kontextem konkrétního prostředí. Konverzace se ukládají, lze se k nim vracet a pokračovat ve vyšetřování. Aktuální implementace rozšiřuje práci s agentovým inventářem, findings, agregacemi, časovým rozsahem a předáním dotazu do Discoveru.

Assistant nemění zdroj pravdy. Zdrojovým důkazem zůstává dokument v indexeru, jeho timestamp, index, pravidlo a původní událost. Vygenerované vysvětlení je pomůcka pro orientaci, nikoli automaticky potvrzený incident.

AI je volitelná a cloudový model není podmínkou provozu Wazuhu. Při použití externího providera mu asistent předává obsah potřebný pro odpověď — dotaz a kontext získaný jeho nástroji; neznamená to automatický export celého indexeru. Pokud požadujete, aby AI data neopouštěla infrastrukturu, asistenta nepřipojujte k externí službě. Alternativou je vlastní kompatibilní model na interním endpointu; jeho podporu nástrojů, provoz a odchozí komunikaci je nutné ověřit.

Podporovaní poskytovatelé

Vývojová dokumentace uvádí následující typy providerů:

• Wazuh AI Assistant Brain;
• Anthropic;
• OpenAI kompatibilní endpoint, kam mohou patřit služby OpenAI, Gemini, Ollama nebo LM Studio podle kompatibility konkrétního API a modelu.

Formulář Beta 5 nabízí dvě volby: OpenAI-compatible a Anthropic. Wazuh AI Assistant Brain se objevuje ve vývojové dokumentaci, nikoli jako samostatná třetí volba tohoto formuláře. U OpenAI-compatible endpointů záleží na kompatibilitě konkrétního API a modelu, zejména na podpoře volání nástrojů.

Administrátor nastavuje jméno providera, endpoint, model a API klíč. Klíče vyžadují šifrované úložiště. Před produkčním nasazením je nutné ověřit, jaký poskytovatel data zpracovává, v jakém regionu, zda je používá pro trénování a jaká platí retenční politika.

Samotné označení „OpenAI compatible“ neznamená, že každý model poskytne stejné výsledky. Model se musí umět držet nástrojového rozhraní, pracovat s tabulkami a vrátit finální odpověď i po více tool calls. Lokální model může být vhodný pro citlivá data, ale jeho přesnost a hardwarové nároky je potřeba změřit na reálných analytických otázkách.

Privacy mode a field policies

Privacy mode je ve výchozím nastavení Beta 5 vypnutý. Administrátor jej může zapnout jako výchozí, nastavit odlišnou volbu pro jednotlivé providery a zakázat uživatelům změnu v konverzaci. Při zapnutém režimu volba Anonymize nahrazuje hodnoty ve výsledcích nástrojů vratnými pseudonymy, například HOST_1 nebo IP_1. Nejde o nevratnou anonymizaci. Never send má jiný význam: vyloučí dané pole z předávaného výsledku i při vypnutém Privacy mode. Neodstraňuje však automaticky tutéž informaci ze všech ostatních polí a volného textu. Původní data v indexeru ani místní tabulka výsledků se tím nemění.

Pozor na ručně vložené údaje. Zapnutý Privacy mode rozpoznává například IP adresy a plné doménové názvy. Krátký hostname demo-node07 nebo uživatelské jméno, které uživatel napíše poprvé a pro které ještě neexistuje mapování, ale může odejít beze změny. Dříve známé identifikátory lze nahradit i v dalších dotazech. Při přepnutí ochrany do zapnutého stavu se z předávané historie vynechávají dřívější nechráněné výsledky nástrojů a odpovědi asistenta; uživatelské dotazy se zachovávají a procházejí textovou kontrolou. Nejde tedy o univerzální filtr citlivých informací. Viz pravidla ochrany polí a zpracování zpráv pro providera.

Toto je zásadní bezpečnostní kontrola, ne jen uživatelská volba. Findings mohou obsahovat uživatelská jména, hostname, IP adresy, názvy procesů, cesty, příkazové řádky, cloudová ID, e-mailové adresy i původní log v event.original. Pokud organizace používá externí model, musí definovat minimální sadu polí potřebnou pro každý analytický scénář.

Doporučený postup:

• Začít s privacy mode vynuceným pro všechny uživatele.
• Zakázat odesílání event.original, secrets, tokenů, command line a volného textu, pokud nejsou pro dotaz nezbytné.
• Pseudonymizovat identity agentů, hostname, uživatele a interní adresy.
• Otestovat pseudonymizaci a její omezení také v historii konverzace a v opakovaných dotazech.
• V logu nebo síťové inspekci ověřit skutečný payload odesílaný providerovi.
• Nastavit retenci historie konverzací a zvlášť ověřit ISM politiku backing indexů. Hodnota 0 podle současné dokumentace vypíná aplikační časový limit, ale výchozí ISM artefakt v Beta 5 současně obsahuje sedmidenní podmínku stáří indexu pro přechod do delete po rolloveru. Efektivní retenci proto určuje kombinace obou vrstev a skutečný průběh ISM.

Co AI Assistant dělat nemá

Assistant by neměl bez lidského potvrzení klasifikovat incident jako uzavřený, měnit důkazní data ani spouštět Active Response. Užitečná odpověď musí být reprodukovatelná: analytik má mít možnost otevřít odpovídající dokumenty v Discoveru a zkontrolovat časový rozsah, filtry a počet výsledků.

Pro přijetí do produkce doporučujeme vytvořit evaluační sadu. Obsahuje otázky se známou odpovědí, testy prázdného výsledku, pokusy o přístup k nepovoleným agentům, citlivá pole, prompt injection uložený v logu a dotazy vyžadující úplný seznam. Hodnotí se nejen jazyk odpovědi, ale hlavně správnost filtrů, úplnost, RBAC a to, zda assistant bezpečně zachází s nedůvěryhodným textem uvnitř událostí.

Case Management: triage findings bez externího ticketu

Wazuh 5.0 přidává k findings základní správu případů. Nález lze opatřit objektem wazuh.case a vést přes analytický workflow přímo v indexovaných datech. Podporována jsou pole:

• titul a podrobný popis;
• stav, například active, acknowledged nebo completed;
• severity a priorita;
• TLP klasifikace TLP:RED, TLP:AMBER, TLP:GREEN nebo TLP:CLEAR;
• tagy;
• komentáře s autorem a časem vytvoření či úpravy;
• uživatel a čas poslední změny.

Case Management nevytváří oddělenou kopii události. Rozšiřuje konkrétní finding o triage metadata. Analytik tak může z detailu nálezu založit případ, popsat vyšetřování, změnit stav a přidat komentáře. Pro API existuje bulk update endpoint s konfigurovatelným limitem počtu findings v jedné operaci.

Identita analytika a napojení na AD

Pole User není přidělený řešitel. V Beta 5 obsahuje wazuh.case.user.name jméno analytika, který případ naposledy změnil; při další úpravě se přepíše. Autor každého komentáře se eviduje zvlášť. Rozhraní dovoluje nejvýše 20 komentářů; jednotlivý komentář může upravit nebo odstranit jen jeho původní autor. Nejde však o neměnný auditní záznam. Samostatná akce vyčištění případu může při odpovídajících oprávněních odstranit všechna jeho metadata včetně komentářů ostatních autorů; původní finding zůstává zachovaný. Práva ke čtení, úpravám a vyčištění proto nastavujte odděleně podle potřeb týmu. Jde o chování dashboardové cesty správy případů, nikoli o samostatný systém přiřazování úkolů.

Identitu dashboard získává z account API přihlášeného uživatele, ne výběrem ze seznamu lokálních účtů. Case Management ale nesynchronizuje adresář AD ani nenabízí přiřazení případu libovolnému kolegovi z IDM. U přihlášení přes LDAP/AD či SSO je nutné ověřit jméno vracené autentizační vrstvou a mapování rolí pro čtení a změny findings. Samotné úspěšné přihlášení tato oprávnění nepotvrzuje.

Severity a priorita řeší dvě odlišné věci

Severity popisuje závažnost bezpečnostního problému. Priorita určuje, jak rychle se jím má tým zabývat. Kritický nález na izolovaném laboratorním stroji může mít nižší provozní prioritu než high nález na produkčním identity serveru. TLP naopak určuje pravidla sdílení informace.

Dobře navržený proces proto nemá kopírovat stejnou hodnotu do všech tří polí. Měl by zohlednit kritičnost aktiva, spolehlivost detekce, dopad, dostupný exploit, rozsah a to, zda jde o probíhající aktivitu.

Vestavěný workflow a stávající integrace

Základní evidenci a postup řešení nálezu nyní zvládne přímo Wazuh. Kvůli stavu, prioritě, popisu nebo komentářům už nemusíte nejprve zakládat ticket jinde. Stávající napojení na Jira, ServiceNow nebo jiný nástroj lze dál využívat podle vašich procesů; není však podmínkou použití nového Case Managementu. To je podstatný posun ve správě bezpečnostních událostí a jejich řešení přímo v platformě.

Incident Response: viditelnost nad provedenými zásahy

Incident Response soustřeďuje přehled vyvolaných aktivních reakcí: jejich název, program, typ, cílení a vazbu na původní nález. Nové workflow využívá záznamy wazuh-active-responses*. Záznam požadavku ale není automatickým potvrzením úspěšné změny na endpointu. Logy Active Response existovaly už ve 4.x; změnou je jejich nové řídicí workflow a přehled v dashboardu, nikoli první možnost reakci dohledat.

To uzavírá důležitou provozní smyčku:

událost → finding → rozhodnutí/monitor → Active Response → výsledek zásahu

Poslední krok je potřeba doložit na agentovi: přijetí a spuštění v ossec.log, výsledek v logu konkrétního skriptu a skutečný účinek na systému. Vestavěné skripty obvykle zapisují do active-responses.log, vlastní skript může používat jiný cíl. U stateful reakce ověřte také návrat po timeoutu. Dashboard sám tento důkaz nenahrazuje; stejné rozlišení popisuje dokumentace sledování reakcí.

Je vhodné sledovat alespoň poměr úspěšných a neúspěšných akcí, dobu do provedení, nejčastější spouštěcí pravidla, endpointy s opakovanými zásahy a stateful reakce, u kterých chybí potvrzený revert.

Alerting a Notifications se stávají centrální součástí platformy

Wazuh 5.0 staví upozornění a reakce na Wazuh variantách OpenSearch Alerting a Notifications pluginů. Monitor prohledává vybraný datový proud, vyhodnotí podmínku a spustí akci. Notification channel určuje, kam se výsledek odešle.

E-mail, Teams, Slack ani webhooky nejsou samy o sobě novinkami 5.0. Mění se jejich zapojení: monitor v Alertingu vyhodnotí data a akci naváže na kanál Notifications, místo aby se bez úprav přenesla stará konfigurace e-mailového daemonu nebo Integratoru. Při migraci je proto potřeba znovu nastavit a otestovat podmínku, cílový kanál a oprávnění, ne jen ověřit, že se v menu nachází název používané služby.

Praktický monitor může každou minutu kontrolovat wazuh-events-v5-system-activity, filtrovat event.action: authentication-failure a při překročení prahu pro konkrétní zdrojovou IP odeslat e-mail nebo zprávu do Teams. Počítáním původních událostí se vyhneme násobení pokusů, pokud nad jedním eventem vznikne více findings. Název normalizované akce ověřte proti používanému dekodéru. Standardní SSH dekodér používá authentication-failure.

Notifikace nejsou Active Response

Alerting monitor může odeslat informaci člověku nebo vytvořit požadavek pro Active Response. Notifikace přímo nemění stav endpointu, přesto může nesprávnému příjemci zpřístupnit citlivá data nebo zahltit obsluhu. Automatické blokování adresy či deaktivace účtu navíc může způsobit výpadek. Podmínky, příjemce i rozsah zásahu proto ověřujte odděleně.

Proto doporučujeme jeden detekční scénář zavádět ve třech fázích:

• pouze dashboard a měření false positives;
• notifikace s lidským potvrzením;
• automatická reakce s omezeným rozsahem, timeoutem a rollbackem.

Reporting: PDF a CSV z dashboardů a uložených hledání

Automatizovaný reporting je důležitý pro pravidelné předávání výsledků: definice reportu určuje datový zdroj, formát a plán generování, případně doručení podle použitého typu reportu a konfigurace. Samotný PDF/CSV export a plugin OpenSearch Reporting však existovaly už ve 4.x. Ve Wazuh 5.0 se odstraňuje původní vlastní generátor reportů uvnitř Wazuh pluginu a reportovací workflow přebírá Wazuh varianta OpenSearch Reporting. Nová je tedy změna používané reportovací vrstvy a její migrace, ne první možnost získat PDF.

Naplánovaný report není automaticky PDF příloha. U dashboardů a vizualizací v Beta 5 vzniká záznam reportu s vybraným časovým rozsahem; e-mailová notifikace může obsahovat odkaz vložený pomocí {{reportLink}}. Vizuální PDF se poté vykresluje a stahuje v prohlížeči uživatele. Záznam se stavem Success či Shared proto sám neprokazuje existenci uloženého PDF ani jeho úspěšné doručení. Pokud zákazník potřebuje bezobslužné ukládání hotových PDF nebo jejich odesílání v příloze, tento konkrétní proces je nutné řešit a ověřit zvlášť. Viz postup doručení odkazu a generátor vizuálního reportu.

Staré PDF soubory si ponechte jako archiv: nová reportovací vrstva je automaticky neimportuje. Nepřenáší se ani původní konfigurace brandingu. Hlavičku a případné logo nastavujte v definici konkrétního reportu přes Explore → Reporting → Create → Report definition → Add header, nikoli jen změnou loga samotného dashboardu.

Známá chyba v Beta 5: patička se do PDF nevygeneruje. Volba Add footer je v rozhraní dostupná, ale dokumentace výrobce výslovně upozorňuje, že výsledný report patičku neobsahuje. Zákazníkovi proto nelze slíbit převzetí původního vzhledu bez kontroly vygenerovaného PDF.

Ukázka ke stažení: PDF report Active Response s logem initMAX (666 kB). Nativní export z Wazuh 5.0.0 Beta 5 obsahuje pouze demo události a testovací endpointy, žádná zákaznická data. Hlavička uvádí časové období i časové pásmo; chybějící patička odpovídá výše popsanému omezení této beta verze.

Při validaci reportu kontrolujte nejen vzhled, ale i rozsah zpřístupněných dat, časové pásmo, time range, maximální počet CSV řádků a dostupnost e-mailového kanálu. Samostatně ověřte právo vytvořit definici, spustit report a přečíst zdrojová data při otevření odkazu. Funkční pohled administrátora neprokazuje, že příjemce uvidí stejná data nebo že soubor vznikne bez jeho přihlášení.

Nový dashboard, navigace a health checks

Wazuh dashboard 5.x je postavený na OpenSearch Dashboards 3.x a jako výchozí používá novou generaci tématu v9. Domovská stránka sjednocuje přehled endpointů, bezpečnostních nálezů, zranitelností a stavu centrálních komponent. Navigace je seskupena podle činností analytika místo historického rozdělení jednotlivých pluginů.

Mezi viditelné změny patří:

• Security Analytics pro normalizaci, pravidla, detektory a Log Test;
• AI Assistant v horní liště a Active Response pod Explore;
• Case Management a Incident Response;
• samostatné patterns pro events, findings, FIM, SCA, vulnerability a metriky;
• přepracovaný Health Check pro API, indexer, pluginy, certifikáty a výchozí monitory;
• centralizovaná aplikace Regulatory Compliance;
• nový přehled statistik pro komunikaci a normalizační engine;
• konfigurace indexeru dostupná z rozhraní podle oprávnění.

Compliance na jednom místě

Dashboard sjednocuje PCI DSS, GDPR, HIPAA, NIST 800-53 a TSC do jedné aplikace Regulatory Compliance. Release notes dále uvádějí nové moduly pro CMMC, FedRAMP, ISO 27001, NIS2 a NIST 800-171.

Dashboard není důkazem splnění regulace sám o sobě. Zobrazuje findings mapované pravidly na konkrétní požadavky. Pro audit je nutné prokázat rozsah agentů, pokrytí zdrojů, správnost vlastních pravidel, retenci, řízení přístupu a postup nápravy. Nové centralizované zobrazení ale zjednodušuje průřezovou kontrolu a porovnání stejného nálezu proti více rámcům.

Odstraněné aplikace a změněné názvy

Původní samostatné aplikace Rules, Decoders, CDB List a Ruleset Test nahrazuje nové workflow Security Analytics a Content Manageru. Odstraněný je také původní generátor reportů uvnitř Wazuh aplikace, nikoli možnost reportovat přes OpenSearch Reporting. Mění se staré obrazovky Statistics, Cluster a App Settings a mizí původní dashboardové moduly CIS-CAT a Osquery; odstranění obrazovky samo o sobě není důkazem odstranění každé možnosti sběru daných dat.

Z pohledu uživatele je důležité, že položka, která „zmizela z menu“, nemusí být zrušená bez náhrady. Často se přesunula do nového workflow nebo nyní čte data přímo z indexeru. Před migrací rolí a interní dokumentace proto projděte každou používanou obrazovku a určete její nový ekvivalent.

Wazuh agent: lokální stav, nový synchronizační model a vyšší limity

Wazuh 5.0 odstraňuje závislost stavových modulů na interní knihovně RSync a mění způsob uchovávání jejich pracovního stavu na agentovi. Lokální databáze existovaly už ve 4.x; novinkou je přepracovaná perzistence a synchronizace. FIM, Security Configuration Assessment a systémový inventář mají zachovávat pracovní stav také mezi restarty agenta. Nejde o odstranění linuxového programu rsync, ale interní knihovny Wazuhu, o jejíž přítomnosti správce často ani nevěděl.

Prakticky jde o zachování výchozího stavu pro další porovnávání změn, ne pouze o jeho uložení na centrálním serveru. Agent předává stav a změny přes manager do stavových indexů; nový protokol řeší verze dokumentů a obnovu konzistence. Perzistence však neznamená, že po restartu nikdy neproběhne nový scan nebo úplná synchronizace. U FIM je to konkrétní migrační změna: v Beta 5 se kontrola spouští při každém startu agenta a volba scan_on_start uvnitř syscheck už není platná. Ze staré konfigurace ji odstraňte; nepřenášejte toto omezení automaticky na SCA nebo Syscollector, které mají vlastní nastavení. Viz změny konfigurace agenta při migraci. Změnu popisuje návrh perzistence stavů a nový synchronizační model. Dopad na síť a zátěž závisí na konkrétním inventáři a četnosti změn.

Mezi další potvrzené změny patří:

• výchozí limit synchronizace FIM <synchronization><max_eps> roste z 10 zpráv/s ve 4.14.7 na 75 v Beta 5. Samostatný limit běžných FIM událostí <max_eps> zůstává 50; vyšší synchronizační limit tedy není příslibem vyšší celkové kapacity nasazení;
• konzistentnější první čtení souboru při rotaci logů;
• ve zdrojovém tagu 5.0.0-beta5 odesílá Windows Event Channel z agenta XML z EvtRender(), zatímco 4.14.7 sestavuje JSON; výsledný normalizovaný dokument v indexeru je nadále JSON. Vlastní dekodéry a pravidla nad Windows Event Viewerem proto znovu ověřte proti novému vstupu a normalizovaným polím.
• agent-start a buffer-status události používají JSON odpovídající WCS;
• zjednodušený rootcheck bez serverové databáze a starého sync/API povrchu;
• redukce zastaralých binárek a modulů;

Podpora distribuce není jedna společná funkce

MSI ani balíčky ARM64 WPK nejsou novinkou 5.0. Stejně tak nelze za novou platformu označit AlmaLinux: jeho podpora ve Vulnerability Detectoru přibyla už ve 4.6. Release notes 4.13 už uvádějí také rozpoznání AlmaLinuxu a Rocky Linuxu v upgrade modulu. Konkrétně jde o automatický výběr typu RPM při vzdáleném upgradu, ne o první možnost na těchto systémech agenta provozovat.

Pro přechod na 5.0 proto rozlišujte dostupnost instalačního balíčku, vzdálený upgrade, SCA politiky a pokrytí zranitelností. Jedno nepotvrzuje druhé. Matice Beta 5 je podkladem pro kontrolu konkrétního systému a architektury; samotná položka v instalační nabídce není důkazem funkčnosti všech těchto cest.

HTTPS komunikace a komprese

Wazuh 5.0 přináší novou HTTPS komunikační cestu mezi agentem a managerem včetně HTTPS enrollment endpointu. Současně zapíná na agentovi ve výchozím stavu kompresi zstd. Jde o provozně významnou změnu, jejíž finální podobu a výchozí nastavení je nutné při vydání znovu ověřit v dokumentaci.

Novinkou není samotná kontrola certifikátů ani existence firewallu, ale změna komunikační cesty. Agent 5.x používá HTTPS listener manageru, standardně na TCP 1517; zachovaný kanál 1514 slouží starším agentům 4.x. Ověření původní registrace proto samo nepotvrzuje, že agent po upgradu dosáhne na nový endpoint. Pokud před managerem skutečně provozujete vlastní reverse proxy nebo load balancer, zkontrolujte také směrování a identitu protistrany. Nejde o vestavěnou proxy Wazuhu ani o povinnou součást nasazení.

Do produkčního návrhu nepatří předpoklad, že „HTTPS“ automaticky vyřeší správu důvěry. Je potřeba stanovit vlastní CA, životní cyklus certifikátů, povolené šifry, rotaci a monitoring expirovaných certifikátů.

HTTPS není automaticky ověřená identita protistrany. Ve zdrojovém tagu v5.0.0-beta5 nastavuje agent při chybějícím bloku <agent><ssl> režim AGENT_VERIFY_NONE. Režim full ověřuje certifikační řetězec i hostname; potřebuje odpovídající důvěryhodnou CA a serverový certifikát. Hodnota system používá systémové úložiště důvěry. Rozdíl je vidět přímo v inicializaci agenta.

Na manageru je serverový certifikát povinný; balíček při instalaci vytvoří self-signed pár, pokud chybí. To ale nepředstavuje automatickou distribuci důvěry agentům. Ověřování klientského certifikátu řídí samostatně <remote><https><verification_mode>: referenční výchozí hodnota je none, při explicitním nastavení CA bez režimu se přepne na certificate. Požadavek na klientské certifikáty tedy nepřisuzujeme automaticky každé instalaci.

Dopad migrace: připravte konfiguraci serveru a důvěru na agentech před přepojením. Pokud vyžadujete vzájemné TLS, doplňte také klientské certifikáty a klíče. Samotné zachování ID, enrollment heslo ani vzdálená výměna balíčku tento krok neřeší; vypínání ověřování není doporučená náhrada.

Enrollment je chráněný sdíleným heslem

Dodaná konfigurace manageru nastavuje <auth><use_password>yes</use_password></auth>. Po registrujícím se agentovi tedy ve výchozí instalaci vyžaduje sdílené heslo. Parser má při vynechání této volby jiný fallback (no); výchozí instalaci a chování neúplné vlastní konfigurace proto nelze zaměňovat. Ochrana heslem sama o sobě existovala už ve 4.x.

Slabým místem zůstává uložení hesla v čitelném textu v /var/wazuh-manager/etc/authd.pass, nikoli v manager keystoru. Při tomto způsobu nasazení ho agent čte z /var/ossec/etc/authd.pass. Práva souboru omezují přístup, ale jeho obsah nešifrují. Kdo získá oprávnění soubor číst, získá i společné enrollment tajemství. Ochránit je potřeba také jeho zálohy a distribuci; samotný přesun do keystoru by nenahradil řízení přístupu.

Heslo patří masteru a distribuuje se workerům. Je-li ochrana zapnutá a soubor chybí či je neplatný, HTTPS enrollment nesmí přejít do nechráněného režimu. Heslo ovšem není povinné ve všech možných konfiguracích: HTTPS listener podporuje také ověřování klientským certifikátem. Kontrola certifikátu a požadavek na heslo jsou nezávislé; bez obou ochran by registrace zůstala otevřená. Tento článek nedoporučuje ochrany vypínat.

Cluster je výchozí i pro jediný manager

Tuto změnu vítáme: v initMAX používáme clusterové uspořádání i pro jedno managerové nasazení už dlouhodobě. Pětka tím sjednocuje provozní model jednoho i více uzlů. Jednouzlový cluster však sám o sobě neposkytuje vysokou dostupnost.

Každá instalace Wazuh serveru 5.0 běží jako cluster node. Odpadá rozlišení mezi klasickým standalone managerem a clusterovou instalací a volba cluster.disabled byla odstraněna. Jednouzlový systém je z pohledu management API a konfigurace stále cluster s jediným uzlem.

To sjednocuje kódové cesty a administraci, ale mění názvy API oprávnění, obrazovky dashboardu a očekávání automatizačních skriptů. Staré volání /manager/... může mít nový ekvivalent pod /cluster/{node_id}/.... Dashboard proto také odstranil část manager-specific logiky a používá clusterové akce.

Instalátor generuje náhodný cluster key pro nové nasazení. Při více manager uzlech musí být klíč bezpečně distribuován a uzly musí mít unikátní jména. U jednouzlové instalace má smysl clusterové metriky stále monitorovat; stejný provozní model se použije při případném rozšíření na více uzlů.

Bezpečnostní změny a princip minimálních oprávnění

RBAC, certifikáty ani zabezpečený enrollment nejsou novinkami pětky. Mění se konkrétní výchozí hodnoty a oprávnění pro nové komponenty:

• pro spojení manageru s indexerem definuje Beta 5 služební účet wazuh-manager s rolí wazuh_manager. Jeho oprávnění odpovídají novým datovým proudům a stavovým indexům; nejde o důvod používat pro běžný sběr administrátorský účet. Viz přehled účtů a rolí;
• vznikají předdefinované role odpovídající Content Manageru, Security Analytics, Alertingu, Notifications a Reportingu;
• API role mappings počítají s rolemi wazuh-admin, wazuh-readonly a wazuh-demo;
• cluster key je náhodný;
• dodaná výchozí konfigurace zapíná heslo pro enrollment;
• dashboard podporuje klientské certifikáty a kontrolu CA při spojení s manager API;
• část starých API a CLI nástrojů s širokým přístupem byla odstraněna;

U migrace bezpečnostních rolí je důležité nevycházet pouze ze souborů na disku. Efektivní konfigurace security pluginu je uložená v security indexu a soubory mohou být starší. Před migrací je nutné aktivní konfiguraci exportovat, zkontrolovat uživatele, role, role mappings a authentication domains a poté vytvořit jejich 5.x variantu.

Spuštění indexer-security-init.sh může obsah adresáře /etc/wazuh-indexer/opensearch-security/ nahrát do security indexu a přepsat změny provedené dříve přes dashboard nebo API. Tento krok proto patří do řízeného change postupu se zálohou a kontrolou diffu.

Odstraněné komponenty a kompatibilita

Odstranění komponenty je potřeba odlišit od přejmenování a změny její role. Manager 5.0 už neinstaluje původní wazuh-agentlessd a wazuh-maild. Autentizační a databázová služba ale nezmizely: Beta 5 obsahuje wazuh-manager-authd a wazuh-manager-db. Také manage_agents nelze označit za plošně odstraněný — instalační větev pro agenta ho stále obsahuje, zatímco manager používá nové nástroje a API. Samostatný agent-auth se již touto cestou neinstaluje. Rozdíl ukazuje instalační kód manageru a agenta.

Odstranění názvu neznamená vždy odstranění celé schopnosti. Enrollment například pokračuje novou manager službou a API, notifikace řeší Notifications plugin a detekční obsah Content Manager. Na druhou stranu agentless monitoring nebo vlastní integrace navázaná na zrušený daemon může vyžadovat úplně nový návrh.

Před migrací doporučujeme vytvořit inventář všech vazeb na Wazuh:

• soubory a adresáře pod /var/ossec;
• API endpointy volané automatizací;
• CLI příkazy v Ansible, skriptech a runboocích;
• vlastní rules, decoders, CDB lists a integrations;
• Filebeat a Logstash konfiguraci;
• alert e-maily z wazuh-maild;
• Active Response skripty;
• vlastní dashboardy, reporty a index patterns;
• účty, role a napojení LDAP/SAML/OIDC;
• systémy čtoucí alerts.json nebo staré indexy.

Tento seznam je inventář závislostí, nikoli seznam dat určených ke smazání. Staré indexy ani snapshoty při přechodu nemažte. Historické dokumenty se automaticky nepřevádějí na nové WCS events a findings; jejich čitelnost, retenci a možnost návratu ověřujte odděleně od nového toku dat.

Chcete vědět, jestli je vaše prostředí na Wazuh 5.0 připravené? Nabízíme technické posouzení současného Wazuh 4.x, mapu nekompatibilit a návrh pilotu i rollbacku. Domluvte si konzultaci. Samostatný praktický článek a webinář k migraci z 4.x na 5.0 právě připravujeme.

Minimální platforma a hardwarové nároky

Modelové tabulky kapacity nepřenášejte mechanicky mezi 4.x a 5.x. Nově se ukládají normalizované events a findings odděleně a datový objem ovlivní typ logů, audit policy, raw stream, discarded events, repliky, počet shardů i komprese. Započítejte také stavové indexy, CTI obsah, prostor pro snapshoty a rezervu pro obnovu. Rozhodující je měření vlastního reprezentativního pilotu, nikoli počet agentů sám o sobě.

Jak sizing ověřit

Nejpřesnější je změřit současnou instalaci:

• průměrné a špičkové EPS po jednotlivých zdrojích;
• denní přírůstek primárních dat bez replik;
• poměr events ku findings;
• velikost state indices a CTI obsahu;
• dobu detektorů při reálném počtu pravidel;
• heap pressure, CPU, fronty a indexační latenci;
• požadovanou retenci a recovery time po obnově snapshotu.

Na základě výsledku lze rozhodnout, zda má smysl all-in-one, oddělený indexer, nebo plně distribuované clustery.

Migrace z Wazuh 4.x na 5.x: nový systém vedle starého

Nejdůležitější breaking change celé verze je migrační model. Oficiální návrh říká: udržte původní Wazuh 4.x v provozu, nasaďte nové Wazuh 5.x prostředí a migrujte nebo znovu vytvořte pouze podporované části.

Centrální komponenty 4.x nelze povýšit in-place. Důvodem není jediný balíček, ale kombinace OpenSearch 3.x, nového schématu, data streams, Content Manageru, přesunu detekce a změn konfigurace. Upgrade existující VM přes package manager by neposkytl konzistentní výsledek ani bezpečný rollback.

Doporučená vysoká úroveň projektu:

inventář 4.x → zálohy → nový 5.x lab → převod obsahu → paralelní validace
→ zachování 4.x historie → registrace a skupiny agentů → pilotní agenti
→ porovnání událostí/findings → produkční cutover → 4.x archiv do konce retence

Co lze migrovat a co se musí vytvořit znovu

Skupinová konfigurace není totéž co členství agentů

Sdílená konfigurace skupin zůstává ve Wazuh 5.0 souborová: /var/wazuh-manager/etc/shared/<skupina>/agent.conf. Používá XML s kořenem <agent_config>. Lokální nastavení linuxového agenta je jiný soubor: /var/ossec/etc/ossec.conf s kořenem <ossec_config>. Tyto názvy nejsou zaměnitelné.

V běžícím manageru vytváří API skupinu jako adresář a soubor agent.conf; členství mění přes Wazuh DB. Zobrazení konfigurace v indexeru proto neznamená, že stačí přenést index. Zálohujte definice skupin i mapu agent → skupiny, do nového manageru přeneste pouze kompatibilní nastavení a členství obnovte proti importovaným ID. Runtime soubor merged.mg se vytvoří znovu. Přenos adresáře sám členství nezachová.

Historická data zůstávají oddělená

V novém systému Wazuh 5.x historii z Wazuhu 4.x mít nebudete: podporovaný migrační postup ji nepřenáší a nový sběr začíná od nuly. Ke starým datům se dál dostanete přes zachovaný indexer a dashboard 4.x. Oficiální migrační postup pro Beta 5 zahrnuje ruční přenos kompatibilní konfigurace, ne historických indexovaných dat. Výrobce pro ně nepodporuje přímý upgrade, snapshot/restore ani reindex ze 4.x do 5.x. Viz omezení migrace indexeru.

Pokud potřebujete dohledávat staré alerty, ponechte původní 4.x indexer a dashboard dostupné jako oddělené prostředí pro čtení. Po přesměrování sběru do 5.x zastavte zápis nových dat do 4.x a podle provozního návrhu nastavte historické indexy pouze pro čtení. Ověřte přístup, oprávnění a vyhledávání ve skutečném historickém časovém rozsahu.

Nové události a findings od okamžiku přechodu patří do 5.x; starší historii hledáte ve 4.x. Jednotný pohled přes obě generace není součástí tohoto migračního postupu. Vlastní export nebo převod dat by byl samostatný integrační projekt, nikoli podporovaný převod starých alertů na nové findings.

Staré indexy, zálohy ani potřebné 4.x prostředí neodstraňujte při samotném přepnutí agentů. Jejich odstavení plánujte až podle retenční politiky a požadavků na audit. Úspěšná obnova vybraného indexu v konkrétní technické kombinaci sama o sobě neprokazuje podporu migrace ani funkčnost historických dat v aplikacích Wazuh 5.x.

Manager má nový adresář a nový konfigurační soubor

Sjednocení pojmenování manageru vítáme: jeho hlavní soubor je nyní /var/wazuh-manager/etc/wazuh-manager.conf. Zůstává to XML, nikoli YAML. Kořen <ossec_config> se mění na <wazuh_config>. YAML dekodéry jsou samostatný detekční obsah, ne nový formát tohoto souboru.

Ukázka nové syntaxe pro manager:

<wazuh_config>
  <global>
    <agents_disconnection_time>15m</agents_disconnection_time>
    <agents_disconnection_alert_time>0</agents_disconnection_alert_time>
  </global>
  <remote>
    <https>
      <port>1517</port>
    </https>
  </remote>
</wazuh_config>

Jde o výřez, ne kompletní instalační konfiguraci. Do výchozího souboru konkrétní instalace přeneste potřebné podporované volby; ponechte jeho správnou clusterovou konfiguraci, certifikáty a indexer připojení. Pro starší agenty se listener 1514 konfiguruje samostatně pod <remote><legacy>, nikoli původními plochými volbami přímo pod <remote>.

Interní přepisy manageru patří do /var/wazuh-manager/etc/wazuh-manager-internal-options.conf ve formátu modul.volba=hodnota. Například následující volba nastavuje interval kontroly změny enrollment hesla v sekundách:

remoted.enroll_password_refresh_interval=10

Konfigurace REST API zůstává samostatným YAML souborem /var/wazuh-manager/api/configuration/api.yaml; dashboard používá /etc/wazuh-dashboard/opensearch_dashboards.yml. Nelze tedy říct, že se veškeré nastavení přesunulo do jednoho souboru. U vlastních šablon je potřeba rozlišit službu, cílový soubor i jeho syntaxi.

Dashboard se instaluje nově

Dashboard 4.x nelze upgradovat in-place. Konfigurace se přesouvá ze souboru:

/usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml

do:

/etc/wazuh-dashboard/opensearch_dashboards.yml

hosts nahrazuje wazuh_core.hosts, jednotlivé checks.* přebírá healthcheck.checks_enabled a staré cron.* a wazuh.monitoring.* volby mizí. Globální přepsání Advanced Settings se nastavuje pomocí uiSettings.overrides.

Vlastní saved objects lze exportovat a importovat. Výchozí Wazuh dashboardy 4.x se ale importovat nemají, protože by mohly přepsat nové objekty nekompatibilními patterns. Panel přenášený na nové findings potřebuje odpovídající datový zdroj a názvy polí. Panel určený pro historické alerty ponechte v původním 4.x dashboardu nad jejich původním patternem. Každý ověřte v časovém rozsahu s dostupnými daty.

V terminologii dashboardu je index pattern uložený výběr dat, například wazuh-alerts-*; není to Filebeat index template definující mappings. Nemusíte kvůli migraci měnit názvosloví indexů. Podstatné je rozlišit původní historické panely v zachovaném 4.x prostředí a vizualizace přenesené do 5.x nad novým proudem wazuh-findings-v5*. Samotný import saved object nepřenáší jeho podkladová data. Přejmenování pole a přesměrování datového zdroje jsou dva různé kroky.

Vlastní rules a decoders jsou samostatný projekt

XML pravidla a dekodéry nelze vložit do manageru 5.x. Každý balík je potřeba převést na integraci, YAML dekodéry, WCS mapování a Sigma pravidla. Doporučený pracovní balíček pro jednu integraci obsahuje:

• inventář starých souborů a jejich checksum;
• seznam typických i problematických logů;
• mapu starých a nových polí;
• nové dekodéry a pravidla v Draft space;
• pozitivní a negativní Log Test;
• porovnání počtu alertů 4.x a findings 5.x na stejném vstupu;
• seznam navazujících dashboardů, notifikací a Active Response;
• schválený promotion do Custom space.

Mechanický převod syntaxe bez paralelního replay testu může tiše změnit detekční pokrytí.

Migraci vlastních XML pravidel a dekodérů plánujte jako ruční převod obsahu. Migrační příručka výrobce výslovně požaduje ruční přepis pravidel; pro dekodéry popisuje mapování jednotlivých konstrukcí. Nestačí převést značky XML na YAML: mění se pole, normalizace i význam některých vazeb a korelací.

Kde je Draft: v dashboardu otevřete Security Analytics → Overview a nahoře zvolte Space: Draft. Zde vznikají a upravují se vlastní integrace, dekodéry, pravidla a KVDB. Draft není aktivní produkční obsah. Po přenosu do Test se obsah validuje v enginu; teprve následný přenos do Custom ho zařadí do produkčního vlastního obsahu. Standard obsahuje obsah dodaný Wazuhem, nikoli další schvalovací krok.

Agenty lze přeregistrovat se zachováním identity

Registrace agentů jsou ve 4.x uloženy v /var/ossec/etc/client.keys a manager databázi. Migrační postup importuje aktivní řádky přes API 5.x manageru, čímž zachová ID, název, IP omezení i autentizační klíč. Poté se na agentovi změní adresa manageru a agent se restartuje.

Wazuh 4.x agent se může k 5.x manageru připojit, ale FIM, SCA, System Inventory, Active Response a Vulnerability Detection nejsou plně podporované, dokud agent nepřejde na 5.x. Přechodový stav je tedy vhodný pro krátký pilot, ne jako trvalá architektura.

Aktualizace balíčku agenta není totéž co dokončená migrace. Odděleně řešte zachování identity, kompatibilitu konkrétního typu balíčku a přechod na HTTPS. Podporu DEB, RPM, MSI, PKG a vzdáleného WPK postupu nelze vzájemně zaměňovat. Centrální komponenty vyžadují nové souběžné nasazení.

Zachování identity není příprava nového spojení. Přenos client.keys zachová identitu a sdílený klíč, ale nevyřeší důvěru k serverovému certifikátu ani distribuci klientského certifikátu, pokud ho manager vyžaduje. Heslo authd.pass se týká enrollmentu; není důvod automaticky přeregistrovat každého agenta, jehož identita byla správně přenesena.

Pokud na endpointu není předem připraveno potřebné TLS nastavení a důvěra, bude před přepojením nutný samostatný zásah — ručně nebo prostřednictvím vaší správy konfigurací. Samotný vzdálený upgrade balíčku tuto přípravu nenahrazuje. Vypnutí ověřování certifikátů ani obcházení bezpečnostních kontrol není doporučený migrační postup.

Doporučený validační checklist před cutoverem

• Všechny centrální komponenty mají očekávanou verzi a sestavení a zdravý cluster.
• Manager zapisuje normalizované události do všech používaných kategorií.
• Standard i Custom policy jsou načtené a Content Manager hlásí konzistentní verzi.
• Replay reprezentativních logů dává očekávané WCS dokumenty a findings.
• Počet událostí a nálezů je vysvětlený; rozdíl není pouze „přibližně stejný“.
• FIM, SCA, inventář a vulnerability data se po upgradu agentů plně synchronizují.
• Vlastní dashboardy používají správná pole pro zamýšlená data: nové findings odděleně od historických alertů. Historické panely zůstávají v původním 4.x prostředí; jejich dostupnost je ověřena odděleně.
• Notification channels doručují zprávy a neodhalují citlivá data.
• Active Response je otestovaný včetně revertu a nouzového vypnutí.
• Pokud je AI Assistant zapojený, respektuje RBAC, pravidla ochrany dat a odkazuje na ověřitelné zdrojové dokumenty.
• Zálohy a obnova v kompatibilním prostředí jsou ověřené; přístup k historii funguje ve 4.x. Nejde o příslib restore 4.x indexů do 5.x.
• Staré 4.x prostředí zůstává dostupné po předem určenou rollback dobu.

Jak se na Wazuh 5.0 připravit

Podpora 4.x po vydání pětky

Technická podpora není automatický příslib dalších oprav pro každou starší verzi. Aktuálně odkazované podmínky placené podpory výrobce pracují s verzemi N a N−1; u N−1 negarantují vývoj patchů a oprava může vyžadovat přechod na aktuální verzi. Z toho nelze odvodit garantované opravy celé řady 4.x po vydání 5.0.

Konkrétní datum ukončení podpory 4.x zde bez potvrzení výrobce neuvádíme. Pro migrační plán si nechte potvrdit přesnou verzi, dobu podpory a dostupnost bezpečnostních oprav podle své smlouvy. Samotná dostupnost starého balíčku není zárukou jeho údržby.

Co připravit před přechodem

Dokud není vydána finální verze, patří Wazuh 5.0 do izolovaného labu. Produkční upgrade má smysl plánovat, ale neprovádět před vydáním finální verze a ověřením podporované upgrade/migrační matice.

Příprava může začít okamžitě:

• aktualizujte zdrojové prostředí na podporovanou 4.14.x větev;
• sepište všechny vlastní rules, decoders, lists, Filebeat pipelines a integrace;
• uložte reprezentativní anonymizované logy pro replay test;
• exportujte vlastní dashboardy včetně navázaných saved objects a zkontrolujte odkazy na wazuh-alerts-* a použitá pole; panel pro historii ponechte ve 4.x, panel přenesený do 5.x musí odpovídat novým findings;
• zmapujte API a CLI automatizaci;
• změřte EPS, datový přírůstek a retenci;
• ověřte podporu operačních systémů centrálních uzlů i agentů;
• navrhněte novou PKI a správu enrollment hesla;
• pokud chcete AI Assistant používat, nastavte jeho režim zpracování dat podle bezpečnostních omezení popsaných přímo v kapitole o AI;
• připravte paralelní 5.x lab a první vlastní integraci převeďte end-to-end.

Tím se největší rizika odhalí dřív, než je projekt svázaný s termínem produkčního cutoveru.

Chcete změny vidět naživo? Vedle pravidelných Wazuh webinářů připravujeme speciální ukázku Wazuh 5.0 a samostatný webinář o upgradu a migraci. Ukážeme nejen postup, ale hlavně místa, kde se běžná instalace 4.x při přechodu komplikuje. Sledujte termíny Wazuh webinářů.

Shrnutí: největší přínos i největší migrační skok

Wazuh 5.0 sjednocuje data do WCS, odděluje normalizaci od detekce a posouvá pravidla, detektory, reporting, notifikace a reakce blíže k indexeru. Content Manager a workflow Draft → Test → Custom přinášejí řád do vlastního detekčního obsahu. Sigma pravidla, IOC enrichment a nové findings zlepšují přenositelnost a kontext detekce. Case Management, Incident Response a AI Assistant zase posouvají dashboard od pouhého zobrazení alertů k analytickému pracovnímu prostředí.

Cena za tento posun je vysoká míra nekompatibility s 4.x. Podle migračního postupu pro Beta 5 potřebujete novou instalaci a ruční přenos kompatibilní konfigurace; historická data se nepřenesou a v novém systému začíná sběr od nuly. Původní 4.x prostředí proto zachovejte jako oddělený archiv po požadovanou retenční dobu. Přechod vyžaduje paralelní testování, převod vlastních pravidel a řízené přepojení agentů, nikoli jen aktualizaci balíčků.

Právě proto má smysl začít s inventářem a labem už nyní, ale produkční rozhodnutí opřít o aktuální release notes a výsledky vlastních testů.

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

• Testovací sestava: Wazuh 5.0.0 Beta 5
• Release notes: Wazuh 5.0.0 release notes v oficiální dokumentaci
• Nová datová analýza: Data analysis ve Wazuh dokumentaci
• Přechod z 4.x na 5.x: Wazuh migration guide
• Změny Wazuh indexeru: Wazuh Indexer Plugins – release notes
• Zdrojový kód ověřované verze manageru a Engine: wazuh/wazuh v5.0.0-beta5
• Zdrojový kód ověřovaných indexerových pluginů: wazuh/wazuh-indexer-plugins v5.0.0-beta5
• Wazuh CTI: Introducing Wazuh CTI
• Služby initMAX: Wazuh SIEM a XDR
• Školení initMAX: Wazuh školení

Jako specialisté na Wazuh, SIEM, infrastrukturu a automatizaci vám pomůžeme s posouzením připravenosti, návrhem architektury, převodem vlastního detekčního obsahu, pilotním prostředím i řízenou migrací. Pokud chcete Wazuh 5.0 vidět v praxi nebo porovnat možnosti s vaším současným Wazuh 4.x, kontaktujte nás.

The post Nový Wazuh 5.0 je téměř zde! appeared first on initMAX s.r.o..

Jediný Premium Delivery Partner v US s trenérskou licencí

V USA je momentálně několik Zabbix Premium Delivery Partnerů, ale my jsme z nich jediní, kdo zároveň drží licenci Zabbix Certified Trainer. V praxi to znamená, že kromě implementací a podpory umíme vést i oficiální Zabbix školení (Specialist, Professional, Expert) přímo pro americké zákazníky. Klient tak nemusí kombinovat dva dodavatele – implementaci řešíme my a školení také.

Co Premium Delivery Partner status znamená

Premium Delivery Partner je nejvyšší úroveň partnerství, kterou Zabbix uděluje za prokázanou schopnost dodávat enterprise nasazení. Partner musí splnit kombinaci požadavků na certifikace v týmu, počet úspěšně dokončených projektů a prokazatelnou zkušenost s rozsáhlými instalacemi.

• Certifikovaný tým – držíme aktuální certifikace na všech úrovních (Specialist, Professional, Expert)
• Prioritní kanál na Zabbix SIA – máme přímý přístup k vývojářům Zabbixu pro řešení komplikovanějších situací
• Reference z enterprise prostředí – desítky úspěšných nasazení od telco operátorů po finanční instituce

Co konkrétně umíme nabídnout v USA

• Implementace a migrace Zabbixu – od greenfield nasazení po migraci ze starších verzí nebo z jiných monitorovacích nástrojů (Nagios, PRTG, SolarWinds a mnoho dalších)
• Oficiální Zabbix školení – kurzy Zabbix Certified Specialist, Professional a Expert vedené naším Certified Trainerem, onsite i remote
• Audit a optimalizace – prověření stávající instalace, ladění výkonu, rework problematických šablon
• Technická podpora – SLA podpora pro produkční Zabbix prostředí, včetně oficiální Zabbix podpory
• Customizace na míru – vývoj vlastních widgetů a modulů pro Zabbix podle specifických potřeb zákazníka

Kde nás najdete

Vedle USA působíme také v České republice a na Slovensku. Pokud potřebujete Zabbix expertízu kdekoliv ve střední Evropě nebo v Severní Americe, jsme vám nablízku.

Kontakt v USA

Pro americké zákazníky máme samostatnou pobočku INITMAX, INC. se sídlem na Floridě:

• Adresa: 7901 4th St N, STE 300, St. Petersburg, FL 33702
• Telefon: +1 (727) 350-9332
• Email: info@initmax.com

Pokud řešíte cokoli kolem Zabbixu – nasazení, školení, audit nebo dlouhodobou podporu – ozvěte se. Můžete nám zavolat, napsat email nebo využít kontaktní formulář. Domluvíme nezávaznou konzultaci a probereme, co dává smysl ve vašem prostředí.

The post Jsme Zabbix Premium Delivery Partner v USA – jediní i s trenérskou licencí appeared first on initMAX s.r.o..

Co je MCP a proč na tom záleží

Model Context Protocol (MCP) je otevřený standard, který AI asistentům umožňuje používat externí nástroje. Místo toho, abyste ručně kopírovali data ze Zabbixu a vkládali je do chatu s AI, MCP server zpřístupní celé Zabbix API přímo AI asistentovi. Ten pak může sám dotazovat hosty, kontrolovat problémy, prohlížet triggery, vytvářet grafy nebo generovat reporty.

Jednoduše řečeno: AI asistent se stane plnohodnotným operátorem vašeho Zabbixu.

Co Zabbix MCP Server umí

Server pokrývá kompletní Zabbix API – 231 nástrojů ve všech 58 API skupinách. To znamená, že AI asistent může dělat vše, co byste dělali ručně ve webovém rozhraní Zabbixu:

• Monitoring – dotazování hostů, problémů, triggerů, eventů, historie a trendů
• Konfigurace – správa šablon, hostů, host groups, items, discovery rules
• Vizualizace – export grafů jako PNG, generování PDF reportů
• Analytika – detekce anomálií (z-score analýza), predikce kapacity (lineární regrese)
• Správa – uživatelé, role, skripty, maintenance, SLA, dashboardy

Příklady použití – na co se můžete AI zeptat

Jakmile je Zabbix MCP Server připojený k vašemu AI asistentovi, můžete se jednoduše ptát:

Ukaž mi všechny aktuální problémy se severity High nebo vyšší

Vygeneruj graf CPU utilizace serveru db-prod-01 za posledních 24 hodin

Vytvoř PDF report dostupnosti pro skupinu Web Servers za březen

Které triggery se spustily nejvíckrát za posledních 7 dní?

Vytvoř hosta switch1 s IP 10.10.1.10, SNMP komunita public - vygeneruj pro něj SNMP šablonu

Jaká je predikce zaplnění disku na serveru storage-01?

AI asistent si sám zavolá příslušné Zabbix API endpointy, zpracuje data a vrátí srozumitelnou odpověď – včetně grafů nebo reportů, pokud o ně požádáte.

Admin portál – webové rozhraní pro správu

Zabbix MCP Server obsahuje plnohodnotný administrační portál běžící na samostatném portu (výchozí 9090). Přes něj můžete spravovat vše potřebné bez editace konfiguračních souborů. Administraci lze také kompletně vypnout a řídit vše pouze přes konfigurační soubor config.toml.

Správa MCP tokenů

Každý AI klient se autentizuje vlastním tokenem. Tokeny můžete omezit na konkrétní:

• Scopes – které nástroje (API skupiny) token smí použít
• Zabbix servery – ke kterým instancím má token přístup
• IP restrikce – z jakých IP adres je přístup povolen
• Read-only režim – ochrana proti nechtěným změnám
• Expirace – automatické vypršení platnosti tokenu

Multi-server podpora

Připojte více Zabbix instancí současně – produkci, staging, testovací prostředí. Každý server má vlastní stav připojení s volitelným ověřením SSL.

PDF reporty a šablony

AI asistent může na požádání generovat PDF reporty přímo z dat Zabbixu. Generování PDF probíhá na straně serveru – samotné LLM totiž PDF vytvořit neumí. Díky tomu se zároveň šetří tokeny, protože server sestaví celý report bez nutnosti přenášet surová data přes AI. K dispozici jsou předdefinované šablony (Availability, Capacity, Backup a další) a můžete také vytvářet vlastní šablony.

Kompletní nastavení

Veškerá konfigurace – TLS, CORS, rate limiting, tool exposure, branding reportů – je dostupná přímo z webového rozhraní. Můžete nahrát vlastní logo, nastavit název firmy a další parametry brandingu. Po změně konfigurace stačí server restartovat jedním tlačítkem přímo z administrace.

K dispozici je také Compact output mode, který šetří tokeny. Namísto vrácení všech desítek polí z Zabbix API vrací server pouze klíčové údaje. AI asistent si může kdykoli vyžádat plný detail pomocí parametru extend. Příklad pro host_get:

Rozšířené nástroje (Extension tools)

Kromě kompletního pokrytí standardního Zabbix API server přidává 6 vlastních rozšiřujících nástrojů:

Bezpečnost

Bezpečnost je klíčová, když dáváte AI přístup k monitorovacímu systému. Zabbix MCP Server obsahuje řadu ochranných mechanismů:

• Read-only režim – per-server i per-token ochrana proti zápisům
• Dvoukrokové schvalování – akce action_prepare + action_confirm pro bezpečné zápisy
• Rate limiting – ochrana Zabbixu před zahlcením (výchozí 300 req/min)
• Token scopes – granulární kontrola, které API skupiny jsou přístupné
• IP restrikce – whitelist povolených IP adres
• TLS – podpora HTTPS s vlastními certifikáty (doporučujeme důvěryhodné – někteří AI klienti mají problém se self-signed certifikáty)
• Audit log – kompletní záznam všech akcí

Kompatibilní AI klienti

Zabbix MCP Server funguje s jakýmkoli MCP-kompatibilním klientem. Testováno s:

• Claude (Anthropic) – Claude Desktop, Claude Code
• ChatGPT (OpenAI) – přes MCP plugin
• GitHub Copilot – VS Code extension
• Cursor – AI-first editor
• OpenAI Codex – CLI agent
• n8n – workflow automation
• JetBrains AI – IntelliJ, PyCharm a další

Příklady konfigurace pro nejčastější klienty:

Claude Code (CLI):

# HTTP transport, s tokenem
claude mcp add zabbix -t http -e http://your-server:8080/mcp -h "Authorization: Bearer zmcp_your-token-here"

# HTTP transport, bez tokenu
claude mcp add zabbix -t http -e http://your-server:8080/mcp

Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "zabbix": {
      "type": "http",
      "url": "http://your-server:8080/mcp",
      "headers": {
        "Authorization": "Bearer zmcp_your-token-here"
      }
    }
  }
}

VS Code + GitHub Copilot (.vscode/mcp.json):

{
  "servers": {
    "zabbix": {
      "type": "http",
      "url": "http://your-server:8080/mcp",
      "headers": {
        "Authorization": "Bearer zmcp_your-token-here"
      }
    }
  }
}

Podrobné návody pro všechny podporované klienty (včetně Cursor, Codex, n8n, JetBrains a dalších) najdete v dokumentaci na GitHubu:

Rychlý start

Instalace na Linux server

git clone https://github.com/initMAX/zabbix-mcp-server.git
cd zabbix-mcp-server
sudo ./deploy/install.sh

Instalátor automaticky nainstaluje vše potřebné a na konci vypíše přístupové údaje:

✓ === Installation complete ===

  Next steps:
  1. Edit config:      sudo nano /etc/zabbix-mcp/config.toml
  2. Start service:    sudo systemctl start zabbix-mcp-server
  3. Enable on boot:   sudo systemctl enable zabbix-mcp-server

  Endpoints (listening on 0.0.0.0:8080):
    MCP endpoint:   http://192.168.1.50:8080/mcp
    Admin portal:   http://192.168.1.50:9090

  ╔══════════════════════════════════════════════════════╗
  ║              Admin Portal Credentials                ║
  ╠══════════════════════════════════════════════════════╣
  ║  URL:       http://192.168.1.50:9090                 ║
  ║  Username:  admin                                    ║
  ║  Password:  Xk9mP2vL4wQn7R8s                         ║
  ║                                                      ║
  ║  Save this password - it will not be shown again     ║
  ╚══════════════════════════════════════════════════════╝

Poté stačí spustit službu a přihlásit se do admin portálu, kde přes webové rozhraní přidáte Zabbix server, vytvoříte MCP tokeny a nakonfigurujete vše ostatní – bez nutnosti editovat konfigurační soubory.

sudo systemctl start zabbix-mcp-server
sudo systemctl enable zabbix-mcp-server

Aktualizace na novou verzi:

cd zabbix-mcp-server
git pull
sudo ./deploy/install.sh update

Instalace přes Docker

git clone https://github.com/initMAX/zabbix-mcp-server.git
cd zabbix-mcp-server
cp config.example.toml config.toml
nano config.toml                      # vyplňte URL a API token Zabbixu
docker compose up -d

Výchozí konfigurace naslouchá pouze na localhost. Pokud chcete změnit port nebo zpřístupnit server na všech rozhraních, vytvořte soubor .env:

cp .env.example .env
nano .env

V .env můžete nastavit:

• MCP_HOST=0.0.0.0 – naslouchání na všech rozhraních (výchozí: 127.0.0.1)
• MCP_PORT=8080 – port MCP endpointu
• ADMIN_PORT=9090 – port admin portálu

Po startu kontejneru můžete ověřit stav:

docker compose ps
docker compose logs -f

Upgrade na novou verzi:

git pull
docker compose up -d --build

Další příkazy instalačního skriptu

sudo ./deploy/install.sh generate-token claude   # vygeneruje nový MCP token
sudo ./deploy/install.sh set-admin-password       # reset hesla admin portálu
sudo ./deploy/install.sh test-config              # validace config.toml
sudo ./deploy/install.sh uninstall                # kompletní odinstalace
sudo ./deploy/install.sh install --with-reporting # instalace s PDF reporty
sudo ./deploy/install.sh install --without-reporting # instalace bez PDF reportů

Dokumentace a komunita

Veškerá dokumentace projektu je na GitHubu – najdete tam podrobný instalační návod, konfigurační referenci, příklady pro všechny AI klienty i bezpečnostní doporučení. GitHub repo je zároveň hlavní místo pro komunikaci s komunitou:

• README – kompletní dokumentace, konfigurace, seznam všech nástrojů
• INSTALL.md – podrobný instalační návod pro Linux i Docker
• CHANGELOG – přehled změn v každé verzi
• Issues – hlášení chyb a požadavky na nové funkce
• Discussions – nápady, otázky a sdílení zkušeností s komunitou

Server je open-source (AGPL-3.0), podporuje Zabbix 5.0 až 8.0 a je připravený pro produkční nasazení s TLS, rate limitingem a kompletním audit logem. Budeme rádi za jakýkoli feedback – ať už formou ticketu, nápadu v diskuzích, nebo hvězdičky na GitHubu.

The post Zabbix MCP Server – propojte AI asistenta s vaším Zabbixem appeared first on initMAX s.r.o..

Stali jsme se oficiálním partnerem společnosti SMSEagle – polského výrobce hardwarových SMS/MMS bran pro profesionální použití. Konkrétně jsme jako Silver Partner pro Českou republiku. Pro zákazníky, kteří potřebují spolehlivý kanál pro doručování notifikací nezávislý na cloudu, je to skvělá zpráva.

Co je SMSEagle

SMSEagle je hardwarové zařízení – dedikovaná SMS/MMS gateway, která umí odesílat a přijímat SMS, MMS a navíc i hlasové volání, a to přímo z vaší lokální sítě, bez závislosti na cloudových službách třetích stran. Umístíte ho do serverovny nebo prostě tam, kde ho potřebujete mít, vložíte SIM kartu a máte vlastní gateway pro doručování notifikací. Zařízení vyrábí zkušený a lety prověřený polský tým, který každý kus dělá se srdcem a pílí – není to anonymní masová produkce, ale poctivá hardware práce. SMSEagle je navíc Made in EU, ale podpora a fungování zařízení jsou celosvětové – bez ohledu na to, kde sedíte, máte za sebou stejný tým, certifikace i servis.

SMSEagle používá pro doručování notifikací třeba Alza, Allwyn (dříve Sazka) a řada dalších našich zákazníků – od retailu po loterijní operátory. Tam, kde nesmí SMS spadnout, dává smysl mít vlastní hardware.

Typické nasazení:

• Alerting z monitorovacích systémů – přímá integrace se Zabbixem, Nagiosem, PRTG a dalšími
• Dvoufaktorové ověřování (2FA) – odesílání ověřovacích kódů přes SMS
• Notifikace a hromadné SMS – automatizované zprávy pro zaměstnance, zákazníky nebo pacienty
• IoT a M2M komunikace – spolehlivé SMS pro průmyslové systémy
• Hlasové volání (Voice Calls) – SMSEagle umí kromě SMS také přímo zavolat a přečíst zprávu pomocí Text-To-Speech. Ideální pro kritické alerty, kde nechcete, aby zpráva zapadla mezi ostatní SMS. Srozumitelnost TTS napříč různými jazyky je pomerně unikátní a funguje i v mezinárodním prostředí

Co dalšího SMSEagle umí

• Záložní LTE modem – při výpadku internetu může zařízení sloužit i jako LTE modem a držet vám síť nahoře
• High Availability – modely s více modemy umí běžet v interním HA režimu, nebo můžete postavit kompletní HA cluster už od dvou zařízení, a to s jednoduchým nastavením
• Email-to-SMS – oblíbená funkce pro systémy, které umí jen posílat email – SMSEagle email automaticky převede na SMS
• API a webhooky – snadná integrace dalších systémů přes REST API nebo webhooky, takže si SMSEagle napojíte prakticky na cokoliv

Chcete si zařízení vyzkoušet nezávazně a hned? Máme na to formulář níže – vyplníte základní údaje a my vám obratem pošleme přihlašovací údaje do živé demo instance SMSEagle. Žádný sales call, žádné čekání, prostě se přihlásíte a vyzkoušíte.

Proč hardwarová SMS gateway

Jako specialisté na monitoring a infrastrukturu víme, jak důležité je mít spolehlivý a nezávislý kanál pro doručování kritických notifikací. Cloudové SMS služby mohou selhat právě ve chvíli, kdy je potřebujete nejvíce – třeba při výpadku internetového připojení nebo problému u providera.

SMSEagle tenhle problém řeší elegantně: zařízení sedí přímo ve vaší síti, komunikuje přes mobilní síť a funguje i při úplném výpadku internetu. To je rozdíl mezi „monitoring nám napsal SMSku“ a „monitoring nám měl napsat SMSku, ale zrovna padl SMS provider“.

Po posledních výpadcích providerů zájem o tahle zařízení výrazně vzrostl – pro firmy, které musí mít notifikace prokazatelně doručené nezávisle na cloudu, je to kombinace, která dává smysl. Stejně tak pro zákazníky řešící GDPR a požadavky NIS2 – SMS odchází přímo z vaší sítě, žádná data neutíkají do služby třetí strany.

Modely SMSEagle

SMSEagle nabízí tři produktové řady, které pokrývají od jednoduchého alertingu po enterprise nasazení s vysokým provozem:

Ceny výrobce byly ověřeny k 31. 10. 2026 a jsou uvedeny bez DPH, před uplatněním individuální slevy initMAX. U všech nových zařízení je od 12. 10. 2026 v ceně funkce Voice Calls (prozvonění a Text-To-Speech), dříve nabízená jako placený doplněk. Konkrétní zvýhodněnou nabídku vám připravíme na vyžádání.

Single Modem – NXS-9700

Vstupní řada s jedním modemem (4G nebo 5G). Ideální pro kritické alerty, malé a střední nasazení nebo retail. Kompaktní, bez pohyblivých částí, navržené pro 24/7 provoz.

Ceníková cena výrobce před slevou: €1 189 (4G) / €1 489 (5G), bez DPH. Přes nás individuální sleva až 20 % na vyžádání.

Dual Modem – NXS-9750-4G (doporučujeme)

Dva nezávislé modemy v jednom zařízení. Vyšší propustnost, redundance přes dva operátory, ideální pro nasazení kde nelze tolerovat výpadek SIM nebo sítě. Při výpadku nebo problému s jednou SIM se zařízení automaticky přepne na druhou – bez zásahu administrátora.

Ceníková cena výrobce před slevou: €1 389 bez DPH. Přes nás individuální sleva až 20 % na vyžádání.

Eight Modem PRO – MHD-8100-4G

Enterprise řada s osmi modemy v 1U racku. Pro vysoký provoz, telco nasazení, hromadné kampaně nebo failover napříč více operátory.

Ceníková cena výrobce před slevou: €2 789 bez DPH. Přes nás individuální sleva až 20 % na vyžádání.

Třešnička na dortu – příslušenství

Základní antény podle modelu a napájecí adaptér jsou již součástí balení zařízení. U modelu MHD-8100 jsou přibalené i montážní úchyty do racku. K zařízení si můžete dokoupit další příslušenství podle potřeb svého nasazení:

• Voice pro stávající zařízení – dodatečná licence pro starší zařízení zakoupená bez funkce Voice Calls. U nových zařízení je od 12. 10. 2026 prozvonění a Text-To-Speech již součástí ceny.
• Senzory prostředí – teplotní čidlo s 3m kabelem, senzor úniku vody a sada detektorů pohybu. Pro monitoring prostředí racku nebo serverovny a navazující SMS či hlasové notifikace.
• Antény – 4G antény s 3m nebo 10m kabelem, externí 4G anténa s 10m kabelem a Quad 5G/4G anténa se čtyřmi anténami v jednom pouzdře a 2m kabelem.
• Prodlužovací anténní kabel 10 m – samostatný kabel s konektory SMA-F/SMA-M pro umístění antény tam, kde je lepší signál. Kvůli útlumu výrobce doporučuje použít pouze jeden prodlužovací kabel a neřetězit je za sebou.
• Digital I/O Extender – rozšíření o 32 konfigurovatelných digitálních vstupů/výstupů, připojené přes USB. Pro napojení externích kontaktů, senzorů a automatizace; každý port lze nastavit jako vstup nebo výstup.
• Rack mount pro NXS – držák pro montáž zařízení řady NXS-97xx do standardního 19″ racku.
• Náhradní SIM tray – náhradní držák SIM karty pro zařízení řady NXS.
• Napájecí redukce pro NXS – redukce ze svorkovnice na DC konektor 5,5/2,5 mm pro alternativní nízkonapěťové napájení. Jde o konektorovou redukci; běžný napájecí adaptér je již v balení zařízení.

Kompatibilita příslušenství závisí na konkrétním modelu a hardwarové revizi zařízení. Pokud si nejste jistí, ozvěte se nám – poradíme s výběrem pro vaše nasazení. Kompletní nabídku najdete také v katalogu příslušenství SMSEagle.

Novinka: Zabbix acknowledgement přes SMS

Funkce, na kterou jsme se těšili možná nejvíc – obousměrný Zabbix acknowledgement přes SMS – je nově k dispozici: firmware SMSEagle 6.31 (vydaný 1. 6. 2026) přidal nativní integraci s Zabbix API ACK. V praxi to znamená, že když vám Zabbix pošle alert přes SMS, stačí odpovědět ve tvaru ACK <eventid> (volitelně s vlastní poznámkou) a problém se v Zabbixu automaticky potvrdí – žádné přihlašování do GUI v jednu ráno z mobilu. U nás už to máme nasazené a otestované, takže pokud vás to zajímá, neváhejte se nám ozvat.

Co od nás dostanete

• Konzultace a doporučení – pomůžeme vybrat správný model pro vaše potřeby (jednoduchý alerting vs. vysoký provoz vs. failover)
• Prodej se slevou – jako Silver Partner můžeme našim zákazníkům nabídnout zvýhodněné ceny oproti přímému nákupu
• Integrace se Zabbixem – jako Zabbix Premium Delivery Partner umíme SMSEagle napojit přesně tam, kde to dává smysl. Máme připravené i hotové Zabbix šablony: monitoring samotné gateway (stav modemu, signál, SIM, teplota) a notifikační media type pro odesílání SMS i hlasových hovorů přímo ze Zabbixu (včetně obousměrného ACK)
• Balíčky na klíč pro Zabbix a Wazuh – pokud plánujete SMSEagle používat se Zabbixem nebo Wazuhem, nabízíme zvýhodněné balíčky včetně kompletního nastavení a integrace na klíč
• Záruka a podpora v ceně – Každé nové zařízení má v ceně 24 měsíců hardwarové záruky, vzdálené technické podpory výrobce a přístupu k softwarovým aktualizacím, opravám chyb i bezpečnostním aktualizacím.
• Prodloužená záruka a podpora – K novému zařízení lze objednat prodloužení hardwarové záruky a podpory na celkem 3 nebo 5 let. S výběrem varianty vám pomůžeme; u již používaného zařízení ověříme dostupné možnosti podle modelu a aktuálního stavu záruky.
• Podpora pro stávající zařízení – Už SMSEagle máte a potřebujete pokračovat v podpoře? Také pro stávající zákazníky umíme zajistit Post-warranty Support Care Pack na další 1, 2 nebo 3 roky po skončení hardwarové záruky. Zahrnuje technickou podporu a softwarové i bezpečnostní aktualizace; neprodlužuje hardwarovou záruku a nezahrnuje bezplatné opravy nebo výměnu zařízení. Ve formuláři níže vyberte „Prodloužení záruky / podpory“ a uveďte model zařízení a požadovanou službu.
• Technická podpora – pomůžeme s konfigurací, řešením problémů i vlastními skripty

Webinář: Zabbix webhooks v praxi

Pokud chcete vidět SMSEagle v akci společně s dalšími integracemi, máme přesně na to webinář Zabbix webhooks v praxi: Slack, SMS/Voice (SMSEagle) a JIRA. Ukazujeme v něm reálné nasazení, konfiguraci a tipy z praxe.

Chcete si SMSEagle vyzkoušet

Vyplňte formulář níže a získáte přístup do živé demo instance SMSEagle. Formulář jde přímo na SMSEagle, kde vám zařídí přístup, a na zadaný email vám během chvíle dorazí přihlašovací údaje. Pak si celé webové rozhraní v klidu projdete, pošlete testovací SMS a zjistíte, jestli vám zařízení sedne. Žádný call, žádný tlak – jen reálný přístup do běžícího zařízení.

Máte otázku nebo chcete nacenění

Pokud chcete žádost o demo přístup do SMSEagle, použijte rozbalovací formulář výše – ten jde rovnou na SMSEagle. Pokud máte otázku na nás – třeba k nacenění, k integraci se Zabbixem nebo Wazuhem, k customizacím, nebo prostě k čemukoliv kolem SMSEagle – napište nám rovnou tady, do formuláře níže. Ozveme se vám obratem.

SMSEagle už používáte? Přes nás můžete poptat prodloužení záruky či podpory nebo dokoupení funkce Voice pro kompatibilní starší zařízení bez aktivního Voice Calls. Ve formuláři vyberte „Prodloužení záruky / podpory“ nebo „Aktivace Voice pro stávající zařízení“. U nových zařízení je Voice již v ceně.

The post Jsme oficiálním partnerem SMSEagle appeared first on initMAX s.r.o..

Všechny naše veřejné Zabbix šablony udržujeme na GitHubu v jednom centrálním repozitáři.
Pokud jste je zkoušeli hledat přímo na webu, tady je správný odkaz:

Jak šablony stáhnout

Varianta A: stáhnout jednu konkrétní šablonu

1. Otevřete repozitář a klikněte na složku konkrétní šablony.
2. Uvnitř najděte soubor *.yaml (nebo *.yml).
3. Otevřete soubor a použijte Raw / Download, uložte si ho do počítače.

Varianta B: stáhnout všechny šablony najednou

1. Na GitHubu klikněte na Code → Download ZIP,
2. nebo použijte git clone (pokud s Gitem pracujete).

Důležité: Než šablonu naimportujete, otevřete si prosím také README / popisek přímo ve složce dané šablony na GitHubu. Najdete tam prerekvizity (např. požadovanou verzi Zabbixu, jestli je potřeba Zabbix Agent 2 vs. SNMP, případné závislosti), nutná makra ({$…}) a postup nastavení i ověření funkčnosti. Bez těchto informací se může stát, že šablona po importu nebude měřit očekávané metriky.

Jak šablony importovat do Zabbixu

1. V Zabbixu otevřete: Data collection → Templates (nebo „Configuration → Templates“ podle verze).
2. Klikněte na Import.
3. Nahrajte stažený *.yaml soubor.
4. Po importu šablonu připojte k hostu a nastavte případné makra ({$…}) dle README v dané složce.

Tip: Každá šablona má ve své složce krátký popis a instrukce (README) – včetně požadavků, maker a doporučeného nastavení.

Přehled šablon v repozitáři

Repozitář je rozdělen do složek podle jednotlivých šablon. Níže je rychlý „katalog“ – kliknutím se dostanete přímo do složky šablony na GitHubu.

Bezpečnost

• CVE_zabbix_threats – vyhodnocení Zabbix CVE pro efektivní verzi + alerty
• CVE_2024_3094 – kontrola zranitelnosti CVE-2024-3094
• Fail2ban – discovery jailů, metriky + triggery a dashboard
• SELinux_by_Zabbix_Agent_2 – základní monitoring SELinuxu
• SSL_Labs_Certificate_Grade – kontrola veřejné SSL/TLS konfigurace přes Qualys SSL Labs API
• Multiple_Website_certificate_by_Zabbix_agent_2 – hromadné hlídání expirace více certifikátů (Agent 2)
• Windows_Defender_by_Zabbix_Agent – monitoring Microsoft Windows Defenderu přes Zabbix Agent (stavy ochrany, signatury, scany a bezpečnostní eventy z event logu)
• ClamAV_by_Zabbix_agent – monitoring ClamAV přes Zabbix Agent (běh clamd a freshclam, stáří a ověření databáze signatur, výsledky plánovaného skenu a nalezené infikované soubory z logu)
• Windows_Update_by_Zabbix_Agent – monitoring čekajících aktualizací Windows a nutného restartu přes Zabbix Agent (počet aktualizací, příznak restartu a kontrola sběru dat)

Zabbix & infrastruktura

• CVE_zabbix_threats – vyhodnocení Zabbix CVE pro efektivní verzi + alerty
• Zabbix_Server_version – kontrola verze Zabbix serveru
• Zabbix_DB_tables_size – monitoring velikostí tabulek Zabbix DB
• Open_Files – kontrola OpenFiles nastavení pro Zabbix procesy
• Not_Supported_Items – počty „Unsupported“ a „No longer discovered“ položek
• TCP_UDP_Sockets – standardní TCP/UDP socket checky
• Logstash – monitoring Logstash pipeline a zdraví node přes HTTP API (JVM, throughput, zpracování eventů)
• Proxmox_Backup_Server – bezagentní monitoring Proxmox Backup Serveru přes HTTP API (host metriky, datastores, garbage collection, stav a stáří záloh)

Identity / IAM

• FreeIPA_Server – healthcheck FreeIPA serveru (ipa-healthcheck JSON)
• FreeIPA_Client – monitoring FreeIPA klienta (včetně DNS resolver validace a odezvy)

Databáze

• FirebirdDB – monitoring Firebird DB (v3+)
• Zabbix_DB_tables_size – monitoring velikostí tabulek Zabbix DB

SNMP / zařízení / storage

• Synology_NAS – SNMP walk + dependent items a LLD
• Synology_Active_Backup_for_Business – monitoring Synology Active Backup for Business přes SSH a SQLite (úlohy, stav záloh, přenesená data)
• Net_Planet_Switch – monitoring Planet switchů
• SMSEagle_by_HTTP – monitoring SMSEagle SMS gateway přes HTTP API (stav modemů, signál, SIM, počítadla zpráv, teplota)
• Ubiquiti_UniFi_UAP_Access_Point – SNMP monitoring Ubiquiti UniFi access pointů (interfaces, CPU, paměť, rádia, klienti)
• Ubiquiti_UniFi_USW_Switch – SNMP monitoring Ubiquiti UniFi USW switchů (interfaces, CPU, paměť)
• Ubiquiti_UniFi_USW_Pro_Switch – SNMP monitoring Ubiquiti UniFi USW Pro switchů (interfaces, CPU, paměť, ventilátory, teplota)
• FS_Switch_S3270 – SNMP monitoring FS S3270 switche (interfaces, CPU, paměť, PSU, teplota)
• FS_Switch_S3400 – SNMP monitoring FS S3400 switche (interfaces, CPU, paměť, PoE porty, PSU)
• FS_Switch_S3900 – SNMP monitoring FS S3900 switche (interfaces, CPU, paměť, ventilátory, PSU)
• FS_Switch_S5810 – SNMP monitoring FS S5810 switche (interfaces, CPU, paměť, ventilátory, PSU, teplota)

Notifikace (Media types)

• Media_WhatsApp – integrace Zabbix notifikací do WhatsApp Cloud API (webhook)
• Media_HTML_Template – HTML email šablona (světlý/tmavý režim, barvy dle severity, akční tlačítka)
• Media_SMSEagle – notifikace přes SMSEagle: SMS i hlasové hovory (TTS), včetně obousměrného ACK (firmware 6.31+)

IoT / energie / „home lab“

• Solax_Solar_power_plant – monitoring Solax X3-Hybrid (Modbus)
• EHEIM_Digital – monitoring EHEIM Digital (akvárium zařízení) přes HTTP API
• Meter_ESP32_by_HTTP – ESP32 meter integrace přes HTTP
• Meter_ESP32_by_MQTT – ESP32 meter integrace přes MQTT (Agent 2)

3D tisk

• BambuLab – monitoring BambuLab tiskáren přes MQTT (Agent 2 plugin)
• PrusaLink_3D_Printer – základní šablona pro Prusa přes PrusaLink HTTP API

Chcete opravu / vylepšení nebo nový template?

Pokud vám v repu něco chybí, nebo máte nápad na vylepšení, vytvořte issue / pull request přímo na GitHubu.
Šablony průběžně sjednocujeme a přesouváme do jednoho centrálního místa, aby se daly jednoduše dohledat a udržovat.

The post Zabbix šablony (templates) – přehled, stažení a návod appeared first on initMAX s.r.o..

Podniková virtualizace s Proxmox Virtual Environment

initMAX je oficiální Proxmox Authorized Reseller. Pomůžeme vám vybrat předplatné, navrhnout infrastrukturu, převést aplikace a zajistit následný provoz. Máme zkušenosti z desítek reálných nasazení: od jednotlivých serverů přes clustery s vysokou dostupností a úložištěm Ceph až po prostředí ve více lokalitách.

Proberte s námi svůj Proxmox projekt

Co nabízíme jako Proxmox partner

Předplatné je jednou ze součástí fungujícího řešení. Pomůžeme propojit návrh infrastruktury, nasazení, monitoring, obnovu dat i znalosti lidí, kteří prostředí spravují.

• Konzultace a architektura — Kapacitní plánování, návrh úložišť a sítí, požadavky na dostupnost a konkrétní plán realizace.
• Nasazení na klíč — Instalace, konfigurace clusteru, ověření funkčnosti, dokumentace a předání.
• Migrace — Přechod z VMware, Hyper-V nebo stávající infrastruktury s přípravou, testováním a plánem návratu.
• Technická podpora — Pomoc s provozem a eskalace k výrobci podle zakoupeného předplatného a dohodnutého rozsahu služeb.
• Audit prostředí — Kontrola konfigurace, výkonu, zabezpečení a připravenosti na obnovu s doporučeními podle priorit.
• Upgrade — Plánování a provedení aktualizací včetně kontroly kompatibility a následného ověření.
• Školení — Kurzy a workshopy pro administrátory; formát a rozsah najdete na stránce konkrétního kurzu.

Prohlédněte si celou nabídku Proxmox služeb.

Produkty z portfolia Proxmox

Proxmox Virtual Environment

Proxmox Virtual Environment spojuje virtuální stroje KVM, linuxové kontejnery LXC, úložiště a sítě do jedné platformy spravované přes webové rozhraní.

• Clustery s vysokou dostupností a živá migrace pro plánovanou údržbu a obnovu provozu.
• Lokální úložiště ZFS nebo LVM-Thin, sdílená úložiště přes NFS, iSCSI či Fibre Channel, distribuované úložiště Ceph a hyperkonvergovaná infrastruktura.
• Integrované zálohování, obnova a replikace i propojení s Proxmox Backup Server.
• Softwarově definované sítě a integrovaný firewall.

Dostupnost navrhujeme podle aplikací a jejich závislostí. Samotný cluster nezaručuje nepřetržitý provoz aplikace.

Chcete se o Proxmox VE dozvědět víc a vidět ho v praxi? V našem téměř 2,5hodinovém webináři projdeme výběr hardwaru, instalaci, storage, sítě, předplatné i spuštění první virtuální stanice.

Podívejte se na záznam našeho webináře

Proxmox Backup Server

Proxmox Backup Server zálohuje virtuální stroje, kontejnery i fyzické hosty. Inkrementální zálohy a deduplikace šetří úložný prostor, webové rozhraní sjednocuje správu úloh, ověřování i obnovu. Vzdálená synchronizace umožňuje udržovat kopie v další lokalitě.

Pomůžeme naplánovat uchovávání záloh, oddělení oprávnění a testy obnovy pro případy poruch, chybných změn nebo útoku ransomware.

Proxmox Mail Gateway

Proxmox Mail Gateway filtruje poštu před jejím doručením na váš poštovní server. Nabízí antispam, antivirovou kontrolu, pravidla pro přílohy, karanténu a objektový systém pravidel. Administrátoři i uživatelé pracují přes webové rozhraní.

Pomůžeme se začleněním do vašeho poštovního prostředí i nastavením pravidel podle potřeb uživatelů a provozu.

Proxmox Datacenter Manager

Proxmox Datacenter Manager poskytuje společný přehled o více clusterech Proxmox Virtual Environment a systémech Proxmox Backup Server napříč lokalitami. Administrátorům usnadňuje sledování distribuovaných prostředků a koordinaci provozních úkonů.

Proxmox Datacenter Manager nemá samostatné předplatné. Pro přístup k jeho Enterprise Repository musí mít alespoň 80 % nakonfigurovaných vzdálených uzlů aktivní Basic, Standard nebo Premium. Tyto úrovně lze napříč spravovanými systémy kombinovat a pro výpočet se sčítají. Community se do hranice 80 % nezapočítává, přestože jde o placené předplatné.

Příklad: 50 uzlů Basic a 50 uzlů Standard znamená 100% pokrytí a podmínku splňuje. Nárok na podporu PDM vychází z předplatných spravovaných systémů. Uvnitř každého jednotlivého clusteru Proxmox VE musí mít všechny uzly stejnou úroveň předplatného; různé úrovně lze použít mezi clustery nebo samostatnými systémy.

Vyberte si předplatné a potřebnou podporu

Basic, Standard a Premium zahrnují tiketovou podporu výrobce. Předplatné se týká aktualizací a podpory; neodemyká různé funkční edice softwaru.

Porovnání předplatného a podpory podle produktů

The post Stali jsme se Proxmox Authorized Resellerem appeared first on initMAX s.r.o..

Nová verze Zabbix 7.4 přinesla řadu zajímavých novinek.

Widget Item card

Tento widget je ideální pro rychlý a detailní přehled vybraných kritických položek na dashboardech. Hodí se především pro technické a administrativní dashboardy, kde potřebuješ detailně sledovat stav klíčových metrik v Zabbixu.

Tento widget umožňuje zobrazit různé parametry vybraného itemu (např. „Value cache, % used“). Widget poskytuje následující informace:

Sekce nastavení widgetu

Zde uživatel definuje pořadí a výběr informací, které se v widgetu objeví:

• Metrics (základní metriky)
• Type of information (typ informace)
• Host interface (informace o host interface)
• Type (typ položky)
• Description (popis položky)
• Error text (chybové zprávy – místo zmíněné v prvním obrázku)
• Latest data (nejnovější data, poslední kontrola, poslední hodnota)
• Triggers (triggerované stavy)
• Host inventory (informace o inventáři hosta)
• Tags (tagy položky)

Sparkline (mini graf):

• Nastavení šířky, výplně a barvy mini grafu hodnot (sparklinu).
• Časové období, ze kterého sparkline zobrazuje hodnoty (např. poslední hodina).

History data:

• Možnost nastavit, zda se mají používat automaticky určená data, nebo specifická historická data či trendy.

Override host:

Možnost změnit hosta, pro kterého widget ukazuje data (užitečné v dynamických dashboardech).

Nový Zabbix Host Wizard – rychlé a jednoduché přidávání hostů

Nový Host Wizard je interaktivní průvodce v Zabbixu, který pomáhá jednoduše a rychle nastavit nové hosty, zejména začátečníkům a cloud administrátorům. Stávající pokročilé možnosti konfigurace jsou stále dostupné.

Wizard funguje v následujících krocích:

• Výběr libovolné kompatibilní šablony
  Můžete si vybrat jakoukoli kompatibilní dostupnou šablonu pro monitoring podle vlastních potřeb. Šablony jsou rozděleny do kategorií jako DB, OS, Cloud, Application, Device, Firewall a další. U šablony také ihned vidíte, pro jaký typ napojení je určena (např. Zabbix Agent 2 atd.).
• Automatický návrh interface
  Po výběru šablony Wizard automaticky zjistí a navrhne správný typ interface, který šablona vyžaduje, například SNMP. Následně je nutné vyplnit všechny povinné parametry. Díky tomu nemusíte ručně hledat správný typ interface a eliminujete chyby konfigurace.
• Pomoc s instalací a konfigurací agenta
  Pokud vybraná šablona vyžaduje instalaci Zabbix agenta, Wizard vám nabídne přehledný a srozumitelný návod pro jeho instalaci a základní konfiguraci, rozdělený podle operačních systémů (Linux, Windows a další).
• Shrnutí a uložení konfigurace
  Na závěr Wizard zobrazí přehledné shrnutí celého nastavení a umožní případné poslední úpravy. Potvrzením konfiguraci uložíte a hosta automaticky přidáte nebo aktualizujete v Zabbixu.

Výhody Host Wizardu:

• Snadné použití pro začátečníky.
• Omezení chyb při konfiguraci.
• Rychlé a jasné nastavení nových hostů.
• Dostupnost všech pokročilých možností nastavení pro zkušenější uživatele.

Dynamická aktualizace nastavení widgetů v reálném čase

Nová funkce umožňuje okamžité zobrazení změn prováděných v nastavení widgetů bez nutnosti jejich průběžného ukládání.

Při provádění změn v nastavení widgetů (například měníš pořadí zobrazených informací, zapínáš/vypínáš funkce, upravuješ časová období či vzhled), widget v dashboardu na pozadí se ihned aktualizuje.

To dramaticky zlepšuje přehled o tom, jak budou výsledné změny vypadat, a zrychluje proces konfigurace.

Celé okno pro konfiguraci widgetu lze nově snadno přesouvat po obrazovce uchopením a tažením.

Víceúrovňové Low Level Discovery

Zabbix 7.4 přináší dlouho očekávanou možnost „nested“ low-level discovery (LLD) přímo na úrovni hostů – tedy nejen jednorázové pravidlo, ale celou kaskádu závislých „objevovacích“ kroků, které můžete řetězit. Díky tomu můžete:

1. První discovery (např. TRAP nebo HTTP agent) vrátit čistý JSON s polem MAC adres ($.macs) a vytvořit pro každou z nich pouze makro {#MAC}.
2. Druhé (nested) discovery s parent_discovery_rule odkazujícím na první pravidlo, které pro každou MAC adresu spustí další dotaz (např. SNMP get, HTTP call, SQL) a z JSONu vytáhne detaily (vendor, typ, stav atp.) pomocí JSONPATH (např. $.deviceInfo) – zase vystaví další makra {#TYPE}, {#VENDOR} apod.
3. (Volitelně třetí a další) tam, kde potřebujete ještě detailnější členění (např. porty, senzory, tabulky), využijete další nested discovery s parentem na druhé pravidlo.

Snadnější kopírování výsledků v testování položek

Nyní lze jednoduše kopírovat výsledky testování položek a preprocessing kroků pomocí nového tlačítka „Copy to clipboard“. Hodnotu již nemusíte označovat a kopírovat ručně – jedním kliknutím ji snadno vložíte tam, kam potřebujete.

Nová sekce Notifications v uživatelském profilu

Správa notifikačních médií a frontendových zpráv byla přesunuta z uživatelského profilu do nové, přehlednější sekce Notifications. Díky této změně si nyní mohou i uživatelé s oprávněním Zabbix User sami jednoduše nastavovat a upravovat vlastní média pro zasílání notifikací.

Nezávislé řešení Vault maker přes Zabbix server a proxy

Nově lze nastavit, aby hodnoty Vault secret maker byly získávány nezávisle jak Zabbix serverem, tak jednotlivými Zabbix proxy servery. Stačí přepnout volbu Resolve secret vault macros by na možnost Zabbix server and proxy. Proxy servery tak mohou makra řešit samostatně bez nutnosti komunikace se Zabbix serverem.

Detailnější statistiky „History syncer“ transakcí

Detailnější statistiky „History syncer“ transakcí

Procesy History syncer nyní ve svém názvu zobrazují podrobné statistiky zpracovaných transakcí. Jednoduše tak můžete sledovat, kolik hodnot a triggerů bylo zpracováno a jak dlouho jednotlivé operace trvaly.

Údaje „A+B triggers“ znamenají:

• A: triggery zpracované na základě nových hodnot.
• B: triggery zpracované na základě časovačů.

V závorkách najdete detailní časování jednotlivých kroků v následujícím pořadí:

1. Čas zápisu hodnot položek do databáze
2. Čas aktualizace položek (stav, chyby, inventář hosta apod.)
3. Čas zápisu trendů do databáze
4. Čas výpočtu triggerů
5. Čas zpracování událostí a akcí

Tato podrobná diagnostika vám umožní rychle identifikovat případné problémy s výkonem a přesněji analyzovat chování Zabbix serveru či proxy.

Nové možnosti zobrazení prvků a propojení na mapách

Mapy v Zabbixu získaly několik užitečných vylepšení:

1. Automatické skrývání popisků
Popisky prvků (hostů) a linek na mapě lze nyní nastavit do režimu Auto hide. Popisek se automaticky skryje, pokud je prvek či linka v pořádku, a objeví se jen při vzniku problému nebo změně hodnoty. Díky tomu jsou mapy přehlednější.

Výsledekem použití funkce Auto Hide může být například toto zobrazení:

2. Indikátory na základě hodnot položek (Item value indicators)
U linek mezi prvky mapy nyní můžete měnit jejich barvu a styl dynamicky podle aktuální hodnoty položky (itemu). Snadno tak například vizualizujete aktuální rychlost nebo vytížení síťových spojů přímo v mapě.

3. Dynamické zobrazování prvků a linek
Prvky mapy (hosty, propojení) je možné zcela skrýt podle aktuálního stavu nebo hodnoty položky. Tím docílíte maximální přehlednosti a zviditelníte pouze relevantní objekty a propojení.

Okamžitá validace formulářů (Inline validation in forms)

Zabbix nově přináší okamžitou validaci formulářů, která ihned upozorní uživatele na chyby při zadávání hodnot, aniž by bylo potřeba formulář odesílat nebo ukládat. Jakmile vyplníš jednotlivá pole, případné chyby se ihned zobrazí přímo pod konkrétním polem, což výrazně urychluje a zjednodušuje konfiguraci.

Inline validace je aktuálně dostupná pro tyto formuláře:

• Konfigurace šablon (Template configuration)
• Konfigurace hostů (Host configuration)
• Konfigurace položek (Item configuration)
• Konfigurace triggerů (Trigger configuration)

Vylepšený výběr barev s podporou palet

Výběr barev v grafových a koláčových widgetech byl přepracován pro lepší použitelnost. Kromě volby jednolité barvy a zadání hex kódu nyní můžete přepnout na záložku Palette a vybírat z předdefinovaných řad barev – každá série tak dostane odlišný odstín pro jasnější rozlišení. Výběr nyní také plně podporuje ovládání klávesnicí a okamžitě kontroluje správnost zadaných hodnot.

Podpora OAuth2 pro SMTP média

Zabbix nyní podporuje OAuth2 autentizaci pro SMTP média typu Generic, Gmail a Microsoft. Toto vylepšení přináší vyšší zabezpečení a je vyžadováno moderními poskytovateli e-mailových služeb, kteří postupně ukončují podporu klasické autentizace přes uživatelské jméno a heslo.

Příklad konfigurace pro Generic SMTP:
Pro univerzální SMTP služby nastavíte endpointy a OAuth2 parametry ručně dle dokumentace poskytovatele služby:

• Redirection endpoint – URL vašeho Zabbix serveru, kam poskytovatel vrátí autorizační kód.
• Client ID a Client Secret – získáte u svého OAuth2 poskytovatele.
• Authorization endpoint a Token endpoint – dle dokumentace OAuth2 služby.

Příklad konfigurace pro Gmail SMTP:
Pro Gmail stačí vybrat předpřipravenou možnost Gmail, zadat váš

• Client ID,
• Client Secret 
• a URL vašeho Zabbix serveru jako Redirection endpoint. (URL + action=oauth.authorize)
  Redirection endpoint se vyplní automaticky, pouze pokud je Frontend URL v sekci Administration → General → Other → Frontend URL.

Ostatní parametry jsou automaticky nastaveny.

⚠️ Pozor: Gmail již od 30. května 2022 nepodporuje klasické přihlašování heslem, OAuth2 je tedy jedinou možností ověření pro Gmail SMTP v Zabbixu. Doporučujeme přejít co nejdříve.

Správa historické cache

V některých scénářích sběru dat mohou určité položky dočasně zablokovat historii v cache serveru nebo proxy. To může způsobit zpoždění zápisu historických dat do databáze a zpomalit celý systém. Pro lepší správu cache historie byla představena následující vylepšení:

• Ruční vyčištění cache: Nový runtime příkaz history_cache_clear=target pro Zabbix server/proxy umožňuje ručně vymazat cache historie pro konkrétní položku podle jejího ID.
• Automatické vyčištění cache: Pokud položku zakážete, okamžitě se odstraní z cache historie (s výjimkou její poslední hodnoty, která se uchovává kvůli logům). Podobně při zakázání celého hostitele se všechny jeho položky odstraní z cache historie (opět s výjimkou posledních hodnot).
• Diagnostické logování cache: Pokud je cache historie plná, Zabbix server/proxy nyní zapisuje diagnostické informace o stavu cache už od úrovně DebugLevel=3 (dříve od úrovně DebugLevel=4). Log obsahuje položky, které mají v cache nejvíce uložených hodnot.

Šifrování komunikace mezi frontendem a serverem

Nově můžete zabezpečit komunikaci mezi frontendem a Zabbix serverem (trapperem) šifrováním. To oceníte především v konfiguracích se separátními servery pro frontend a backend – typicky v režimu HA. Kromě přepnutí samotného trapperu na TLS (“TLSListen=required”) lze šifrovat i komunikaci mezi proxy a serverem, případně mezi agentem a proxy/serverem, takže vše poběží výhradně přes TLS.

Dále máte možnost definovat, ze kterého frontend node je povoleno se k Zabbix serveru připojit (parametr FrontendAllowedIP), nebo zda povolit pouze připojení chráněné certifikátem (parametr TLSFrontendAccept=cert). Samozřejmě je na vás, zda šifrování použijete, nebo necháte komunikaci otevřenou.

Shrnutí novinek:

• Vynucené TLS pro trapper (TLSListen=required)
• Šifrování proxy↔server, agent↔proxy/server
• Whitelist frontendů pomocí IP/CIDR nebo DNS jmen (FrontendAllowedIP)
• Volba režimu příchozího spojení (TLSFrontendAccept=cert / unencrypted)

Všechny tyto volby ve verzi 7.4 umožňují granularitu od „nikdy šifrovat“ až po „pouze certifikáty“, podle úrovně zabezpečení, kterou ve vaší infrastruktuře potřebujete.

Přehled drobných vylepšení

• Změněna výchozí doba uchovávání uživatelské relace z 365 dnů na 31 dnů.
• Zvýšeny maximální velikosti cache konfigurace pro HistoryCacheSize, HistoryIndexCacheSize a TrendCacheSize(rtrizna):
  • HistoryCacheSize
    Velikost cache pro historická data (historii), v bajtech. Velikost sdílené paměti určené k ukládání historických dat.
    Výchozí: 16M
    Rozsah: 128K–16G
  • HistoryIndexCacheSize
    Velikost indexové cache historie, v bajtech. Velikost sdílené paměti určené k indexaci historických dat uložených v cache. Indexová cache potřebuje přibližně 100 bajtů pro cacheování jedné položky.
    Výchozí: 4M
    Rozsah: 128K–16G
  • TrendCacheSize
    Velikost cache trendů, v bajtech. Velikost sdílené paměti určené k ukládání dat trendů.
    Výchozí: 4M
    Rozsah: 128K–16G
• Proporcionální škálování obrázků na pozadí map
  • Zabbix nyní umožňuje proporcionálně škálovat obrázky na pozadí map. Díky této nové funkcionalitě se obrázek automaticky přizpůsobí aktuální velikosti mapy, aniž by se deformoval nebo ztrácel na kvalitě.

Nové a aktualizované šablony

Nové šablony:

• Juniper MX series: Přidána nová šablona pro monitorování síťových prvků Juniper MX s využitím protokolu NETCONF, umožňující přímé získávání statistik přes nativní rozhraní.
• Azure MSSQL DTU: Nová šablona umožňuje sledovat využití DTU (Database Transaction Unit) databází v Azure prostředí prostřednictvím REST API.
• Pure Storage FlashArray: Přibyla šablona pro monitoring úložišť Pure Storage FlashArray pomocí HTTP API (REST v1 i v2), včetně automatického objevování a sledování kapacit i výkonu.

Aktualizované šablony:

• Dell iDRAC a PowerEdge: Nyní využívají SNMP walk položky pro efektivnější sběr dat.
• Proxmox VE by HTTP: Přidány nové položky a triggery pro sledování využití diskového prostoru.
• MSSQL by ODBC: Opraveny dotazy na performance countery pro přesnější monitorování.
• Linux a Nextcloud: Odstraněny zbytečné preprocessing kroky z LLD pravidel pro zlepšení výkonu.
• Microsoft 365 reports by HTTP: Opraveny popisy pro lepší srozumitelnost.
• PostgreSQL by Zabbix agent 2: Rozšířena podpora PostgreSQL verze 17.
  

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

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

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.

The post Nový Zabbix 7.4 je zde! appeared first on initMAX s.r.o..

Pro tento ročník jsme se opět stali hrdým Gold Parnerem Prague PostgreSQL Developer Day (P2D2). Velké databáze PostgreSQL provozujeme u našich servisních zákazníku jako je Česká spořitelna, Alza, Sazka nebo Kooperativa a samozřejmě i u zákazníků kde provozujeme aplikaci Zabbix. Proto rozhodování jestli jít do podpory takového eventu jako je právě P2D2 nebylo nijak těžké.

Rádi se zde s Vámi také podělíme o zákulisní informace o používání PostgreSQL tak i Zabbixu.

Soutěž o 2 volné vstupenky

Jako partner eventu bychom vám rádi nabídli 2 volné vstupenky. Nebude to ale jen tak, musíte si o ně zasoutěžit.

Soutěž je jednoduchá a stačí vám následující:

• Přidat Like na náš soutěžní příspěvěk na Linkedin
• Přidat k příspěvku komentář, ve kterém napíšete, který náš PostgreSQL Training vás nejvíce zaujal

Soutěž bude ukončena 23. 1. 2025 a následující den budou vylosováni 2 výherci, které budeme obratem kontaktovat.

The post Prague PostgreSQL Developer Day 2025 appeared first on initMAX s.r.o..

Nová verze Zabbix 7.2 přinesla řadu zajímavých novinek.

Widget Host card

Nový Host card widget v Zabbixu umožňuje správu a zobrazení klíčových informací o hostech na dashboardu s následujícími funkcemi:

• Přímé napojení na hosta: Možnost zobrazení podrobností o hostovi, jako jsou monitoring, dostupnost, šablony, inventář a další.
• Externí widgety: Integrace s widgety jako Honeycomb nebo Host navigator pro snadnou navigaci mezi hosty.
• Inventář a tagy: Konfigurovatelná pole inventáře (např. kontaktní informace) a zobrazení tagů pro lepší organizaci a přehlednost.

Uživatel může přizpůsobit obsah widgetu výběrem různých položek, přidávat vlastní inventářová pole a zvolit refresh interval.

Ukázka nastavení pro Host card widget:

Vylepšení widgetu Clock

Widget Clock, který zobrazuje digitální hodiny, prošel výrazným vylepšením. Velikost jednotlivých informací (datum, čas, časové pásmo) se nyní dynamicky přizpůsobuje dostupnému prostoru na základě velikosti widgetu, zobrazovaných jednotek a měřítka zobrazení. Tím je zajištěno, že widget vždy efektivně využije prostor bez nutnosti manuálního nastavování velikosti písma. Konfigurační parametry pro nastavení velikosti byly odstraněny, což zjednodušuje celkové nastavení widgetu.

Top items widget

Top Items widget: Tento widget je skvělý nástroj pro zobrazení seznamu hostů a posledních naměřených hodnot podle vámi nastavených parametrů. Nabízí možnost:

• Řazení dat: Podle jména hosta nebo názvu položky (item).
• Zobrazení aktivních triggerů: Přímo na úrovni položek, což usnadňuje rychlou identifikaci problémů.

Poznámka: Hodnoty binárních dat nejsou v tomto widgetu zobrazovány.

Host Override ve widgetu Graph

Novinkou ve widgetu Graph je host override, který umožňuje dynamicky měnit hodnotu hosta přímo přes externí widgety. Díky této funkci můžete propojit widget Graph s Host Navigator, Honeycomb widgetem nebo Item Navigator, což otevírá nové možnosti práce s grafy na dashboardech.

Co to přináší?

• Dynamické přepínání mezi hosty: S využitím Host Navigator nebo Honeycomb widgetu můžete jednoduše kliknout na konkrétního hosta a widget Graph okamžitě zobrazí příslušné metriky. To znamená rychlou a intuitivní práci bez nutnosti upravovat nastavení grafu.
• Připomenutí – podpora seznamů položek: Již od starších verzí je možné propojit widget Graph s Item Navigator, pokud je zdrojem dat item list. Tato funkce umožňuje rychlé přepínání mezi jednotlivými položkami, což je užitečné například při detailním monitorování metrik na úrovni konkrétních itemů. Nový host override tuto možnost významně rozšiřuje tím, že umožňuje snadné přepínání na úrovni celých hostů.
• Rozšíření grafu na více položek: Při použití host override můžete na grafu zobrazit více položek souvisejících s konkrétním hostem. Například metriky CPU, paměti nebo síťového provozu na jednom hostu. To poskytuje komplexní přehled o výkonu daného hosta.

Proč je to užitečné?

• Jednoduchost: Už žádné kopírování nebo manuální nastavování grafů. Stačí propojit graf s navigátorem a klikat na data, která potřebujete.
• Flexibilita: Kombinujte různé widgety – Host Navigator, Honeycomb widget a Item Navigator – podle vašich potřeb.
• Úspora času: Rychle přepínejte mezi hosty nebo položkami bez zbytečných komplikací.

Ukázka nastavení

Připomenutí: Již jste mohli nastavit kombinaci Host Navigator + Item Navigator s nastaveným item datasetem přímo přes widget.

Vylepšené vlastnosti widgetu Top Hosts

Widget Top Hosts nyní přináší rozšířené možnosti konfigurace sloupců s hodnotami položek, což zlepšuje vizualizaci a přehlednost monitorovaných dat:

• Sparkline grafy:
  • Sloupce nyní mohou zobrazovat sparkline grafy, což jsou malé čárové grafy, které poskytují rychlý vizuální přehled o trendech a změnách v hodnotách v průběhu času. Tato funkce umožňuje snadno identifikovat neobvyklé výkyvy nebo trendy přímo ve widgetu.
• Podpora binárních dat:
  • Nově lze zobrazit hodnoty binárních dat jako náhledy obrázků (thumbnail) nebo hyperlinky na obrázky v plné velikosti. Tato funkce je ideální pro sledování vizuálních dat, jako jsou grafy, snímky obrazovky nebo jiné obrazové soubory.
• Dynamické barevné zvýraznění pro textová data:
  • U textových hodnot můžete nastavit regulární výraz, který při splnění podmínky automaticky změní barvu pozadí sloupce. To umožňuje snadnou identifikaci důležitých hodnot, jako jsou výstrahy, chyby nebo specifické vzory v monitorovaných datech.

Logarithmic Scaling in Graph Widget

Widget Graph nyní podporuje logaritmické měřítko na ose Y. Tato funkce je ideální pro:

• Data s rychlými změnami: Například exponenciální růst nebo pokles.
• Široké rozpětí hodnot: Umožňuje vizualizovat jak malé, tak velké hodnoty na jednom grafu, aniž by malé hodnoty byly přehlédnuty.

NVIDIA GPU Monitoring pro Zabbix Agent 2

Zabbix 7.2 přináší nový oficiální plugin pro Zabbix Agent 2, který umožňuje snadné monitorování GPU NVIDIA. Tento plugin je plně integrován se šablonou „NVIDIA by Zabbix agent 2“, která poskytuje široké možnosti monitorování bez nutnosti použití externích skriptů.

Hlavní vlastnosti:

• Automatické zjišťování GPU: Šablona automaticky detekuje všechna dostupná GPU zařízení a jejich parametry.
• Podpora klíčových metrik: Sledujte využití GPU, paměti, teplotu, spotřebu energie, výkon a další důležité parametry.
• Předpřipravený dashboard: Obsahuje přehledné grafy a statistiky pro snadné sledování výkonu GPU.
• Podpora více platforem: Funguje na Linuxu i Windows.

Typy monitorovaných dat:

• Počet zařízení (detekce GPU v systému).
• Verze ovladače a knihovny NVML.
• Využití enkodéru, dekodéru, GPU i paměti.
• Stav paměti (volná, použitá, celková).
• Teplota a spotřeba energie GPU.
• Chyby ECC paměti.

Tento nový plugin a šablona jsou ideálním řešením pro monitorování GPU NVIDIA v reálném čase. Pomáhají udržovat optimální výkon, identifikovat problémy a snadno sledovat stav hardwaru.

Maximální počet řádků ve widgetech

Počet maximálních řádků, které lze zobrazit ve widgetech na dashboardu, byl zvýšen ze 100 na 1000. Tato změna se týká následujících widgetů:

• Action log
• Item history
• Problems
• Top hosts
• Top triggers

Nový limit 1000 řádků odpovídá hodnotě parametru ZBX_MAX_WIDGET_LINES v definicích frontendů. Díky tomuto navýšení mohou uživatelé získat přehled o větším množství dat přímo na dashboardu, což usnadňuje monitoring a analýzu rozsáhlejších datasetů.

Odstranění limitů závislých položek

Zabbix přináší významné vylepšení v oblasti závislých položek. Předchozí omezení na maximálně 29 999 závislých položek na jednu hlavní položku a pouze 3 úrovně závislostí (Master > Dependent > Dependent > Dependent) byly zcela odstraněny.

Co to znamená:

• Neomezený počet závislých položek: Nyní můžete sledovat libovolné množství metrik odvozených z jedné hlavní položky, bez ohledu na složitost infrastruktury.
• Neomezené úrovně závislostí: Můžete vytvářet složitější struktury závislých položek, což umožňuje hlubší a detailnější monitorování.

Výhody:

• Flexibilnější monitorování: Vytváření pokročilých scénářů monitorování bez technických omezení.
• Lepší škálovatelnost: Ideální pro velká prostředí, kde je třeba sledovat velké množství dat s komplexními vazbami mezi položkami.
• Snadnější konfigurace: Správa položek je jednodušší díky absenci omezení.

Vylepšená podpora proměnných prostředí

Nová podpora proměnných prostředí zjednodušuje konfiguraci a nasazení. Parametry konfigurace Zabbixu lze nyní specifikovat přímo prostřednictvím proměnných, což výrazně usnadňuje práci s kontejnery a automatizovanými CI/CD procesy.

Příklad: Konfigurace Zabbix Agenta pro kontejner

Při vytváření a konfiguraci vlastního obrazu pro Zabbix komponenty (např. Zabbix Agent) je možné definovat parametry konfigurace pomocí proměnných prostředí a poté spustit kontejner s těmito proměnnými.

Příprava obrazu: Nastavte proměnné prostředí v konfiguračním souboru Zabbix Agenta:

Hostname=${ZBX_HOSTNAME}
BufferSize=${BUFSZ}
ListenPort=${LISTENPORT}
UserParameter=${_UsrPar01}
UserParameter=${_UsrPar02}

Spuštění kontejneru: Po vytvoření obrazu spusťte kontejner Zabbix Agenta (např. v Dockeru) s definovanými proměnnými:

docker run --name initMAX-agent \
-e ZBX_HOSTNAME="initMAX-agent" \
-e BUFSZ=1000 \
-e LISTENPORT=20050 \
-e _UsrPar01="key1,ls" \
-e _UsrPar02="key2,pwd" \
--init -d zabbix/zabbix-agent:alpine-trunk

Tento postup umožňuje snadnou konfiguraci a flexibilní nasazení Zabbix komponent v kontejnerových prostředích.

Kompletní odstranění podpory Oracle databáze

Zabbix již nadále nepodporuje Oracle jako backendovou databázi. Tato změna reflektuje přechod k modernějším a otevřeným databázovým řešením, která jsou více využívána v současných IT prostředích. Pro uživatele Oracle to znamená, že je potřeba přejít na jiné databázové systémy, jako jsou PostgreSQL nebo MySQL.

Zlepšený sběr dat ve VMware monitoringu

Zabbix 7.2 zavádí funkci memory pagination, která zlepšuje způsob sběru dat z prostředí VMware. Díky tomu je monitorování efektivnější a vhodnější i pro velké infrastruktury.

Hlavní výhody:

• Lepší výkon: Data se načítají po menších částech, což snižuje zátěž na server i VMware prostředí.
• Rychlejší aktualizace: Metody sběru dat jsou optimalizované, což znamená rychlejší zobrazení aktuálních hodnot.
• Podpora velkých prostředí: Tato funkce usnadňuje sledování prostředí s mnoha virtuálními stroji a hypervizory.

Toto vylepšení zajišťuje stabilnější a rychlejší monitorování prostředků VMware, i ve velmi rozsáhlých systémech.

Nový item pro šablony VMware

Nová verze přidává nový item pro šablonu VMware Guest, který umožňuje monitorovat stav údržby hypervizoru (maintenance mode). Pokud je hypervizor v režimu údržby, problémy jsou automaticky potlačeny. K deaktivaci potlačení problémů je možné nastavit hodnotu makra {$VMWARE.HYPERVISOR.MAINTENANCE} na 0. Toto vylepšení je užitečné zejména pro administrátory, kteří potřebují přehled o stavu údržby virtuálních strojů a jejich dostupnosti.

Možnost konfigurace SSH veřejných klíčů

Zabezpečení komunikace pomocí SSH bylo rozšířeno o nové možnosti konfigurace algoritmů pro veřejné klíče. Uživatelé Zabbixu nyní mohou snadněji a flexibilněji nastavovat bezpečnostní parametry pro vzdálené přístupy pomocí SSH, což zvyšuje bezpečnost celého monitorovacího řešení.

Podpora SSH subsystémů

Nově Zabbix podporuje použití přepínače -s pro SSH položky, což umožňuje připojení k zařízením využívajícím subsystémy, jako je NETCONF nebo SFTP. Tato změna rozšiřuje možnosti monitorování zařízení, která umožňují přístup pouze přes jeden subsystém konfigurovaný na úrovni SSH.

Příklad konfigurace SSH položky s subsystémem v Zabbixu
Chcete-li použít subsystém při konfiguraci SSH položky, použijte následující formát klíče:

ssh.run[unique short description,<ip>,<port>,<encoding>,<ssh options>,<subsystem>]

Příklad použití pro subsystém NETCONF:

ssh.run[netconf-monitoring,192.168.1.100,22,utf-8,,netconf]

Vysvětlení jednotlivých parametrů:
unique short description
Popis položky, například „netconf-monitoring“.
<ip>
IP adresa zařízení, například 192.168.1.100.
<port>
SSH port, standardně 22.
<encoding>
Kódování, například utf-8.
<ssh options>
Další volby SSH, ponechte prázdné (""), pokud nejsou potřeba.
<subsystem>
Název subsystému, například netconf.

Jak to funguje:
Tento klíč zajistí připojení k zařízení přes SSH na zadaný subsystém (např. NETCONF).
Zabbix odešle požadavek přes SSH s přepínačem -s a spustí subsystém definovaný v <subsystem>.

Podpora maker {FUNCTION.VALUE<1-9>} a {FUNCTION.RECOVERY.VALUE<1-9>}

Zabbix nyní podporuje makra {FUNCTION.VALUE<1-9>} a {FUNCTION.RECOVERY.VALUE<1-9>}, která umožňují pracovat s výsledky funkcí v triggerech a jejich obnovovacích výrazech. Tato makra jsou velmi užitečná v různých kontextech, například v notifikacích, názvech událostí nebo skriptech.

Příklad použití v expression macros: Rozdíl hodnot mezi dvěma síťovými rozhraními

Pokud chcete spočítat rozdíl mezi přenesenými daty na dvou síťových rozhraních, můžete použít makra {FUNCTION.VALUE1} a {FUNCTION.VALUE2} v expression macros.

Trigger sleduje přenesená data na dvou rozhraních a chcete zobrazit rozdíl mezi jejich hodnotami.

Konfigurace na úrovni triggeru v názvu události (Event name):

Difference in traffic: {?{FUNCTION.VALUE1} - {FUNCTION.VALUE2}} bytes

Co se stane:

{FUNCTION.VALUE1} odkazuje na první funkci v triggeru, například:

 last(/host/net.if.in[interface1])

{FUNCTION.VALUE2} odkazuje na druhou funkci v triggeru, například

 last(/host/net.if.in[interface2])

Pokud jsou hodnoty pro interface1 a interface2 například:
{FUNCTION.VALUE1} = 5000
{FUNCTION.VALUE2} = 3000
Výsledek bude názvu události (Event name):

Difference in traffic: 2000 bytes

Využití při obnovení problému:
Chcete-li zobrazit hodnoty při obnovení problému, použijte makro {FUNCTION.RECOVERY.VALUE<1-9>}. Například:

Recovered traffic difference: {?{FUNCTION.RECOVERY.VALUE1} - {FUNCTION.RECOVERY.VALUE2}} bytes

Efektivnější monitorování Oracle databází

Nově Zabbix podporuje použití bind proměnných při monitorování Oracle databází. Tato technika odděluje strukturu SQL dotazu od jeho parametrů, což:

• Zlepšuje výkon dotazů díky optimalizaci zpracování.
• Snižuje zátěž na databázový server.

Tato změna zrychluje a zefektivňuje některé operace, jako například získávání statistik o tablespacích.

Nová makra v Zabbixu

Do Zabbixu byla přidána následující nová makra, která rozšiřují možnosti automatizace a práce s událostmi a službami:

• Časová razítka (Unix timestamp):
  • {TIMESTAMP} – aktuální čas.
  • {EVENT.TIMESTAMP} – čas vzniku události.
  • {EVENT.RECOVERY.TIMESTAMP} – čas obnovení události.
  • {EVENT.UPDATE.TIMESTAMP} – čas poslední aktualizace události.
  • {EVENT.CAUSE.TIMESTAMP} – čas související příčiny problému.
  • {ITEM.LOG.TIMESTAMP} – časový údaj z log položky.
• Detaily akcí při aktualizaci události:
  • {EVENT.UPDATE.ACTIONJSON} – vrací JSON pole obsahující podrobnosti o provedených akcích během aktualizace problému.
• ID služby:
  • {SERVICE.ID} – vrací číselné ID služby, která spustila akci.

Nové funkce makra v Zabbixu

Zabbix přidal nové funkce pro makra, které umožňují práci s textem a kódováním dat. Tyto funkce zjednodušují manipulaci s hodnotami přímo v Zabbixu bez nutnosti externích skriptů.

Seznam nových funkcí:

• regrepl: Nahrazuje všechny výskyty hodnoty, počínaje první nalezenou.
• tr: Kompletní transliterace textu (např. změna znaků v řetězci podle definovaných pravidel).
• btoa: Kóduje data do Base64 formátu pomocí PHP metody base64_encode().
• urlencode: Kóduje text pro URL pomocí PHP metody rawurlencode().
• htmlencode: Převádí speciální HTML znaky na entity pomocí PHP metody htmlspecialchars.
• urldecode: Dekóduje text kódovaný pro URL pomocí PHP metody urldecode().
• htmldecode: Převádí HTML entity zpět na původní znaky.
• lowercase: Převádí všechny znaky na malá písmena.
• uppercase: Převádí všechny znaky na velká písmena.

Praktické využití:

• Manipulace s hodnotami: Upravte data před jejich použitím v triggerech nebo vizualizacích.
• Zjednodušení šablon: Přímé zpracování textových dat bez nutnosti dalších skriptů.
• Lepší integrace: Snadné přizpůsobení dat pro různé výstupy, jako jsou URL nebo HTML.

Tato rozšíření usnadňují přizpůsobení monitoringu komplexním scénářům.

Přehled drobných vylepšení

• Rozšíření API pro uživatele s omezenou rolí
  Uživatelé s rolí „User“ nyní mohou používat metodu mediatype.get v API. Zobrazená data jsou však omezena pouze na nezbytná pole (mediatypeid, name, status, description), aby se zabránilo úniku citlivých informací. Toto vylepšení zvyšuje flexibilitu správy médií pro uživatele s omezenými právy.
• Podpora LLD makra v monitorování systemd služeb
  Položka systemd.unit.discovery[] nyní vrací makro {#UNIT.SERVICETYPE}, které určuje chování jednotky služby (například simple, forking, oneshot, idle atd.). Tato možnost umožňuje přesnější monitorování a automatizaci procesů spojených se systemd službami.
• URL odkazy v modálních konfiguračních formulářích
  Modální konfigurační formuláře nyní podporují URL odkazy, což umožňuje otevírání formulářů v nové záložce nebo kopírování URL pro sdílení. Tato funkce usnadňuje spolupráci a zvyšuje efektivitu práce.
• Podpora konfigurace přes environmentální proměnné
  Nově lze specifikovat konfigurační parametry pomocí environmentálních proměnných, což je ideální pro nasazení Zabbixu v kontejnerech a cloudových prostředích. Proměnné umožňují přepsat hodnoty v konfiguračních souborech a usnadňují správu konfigurace.
• Filtr akcí podle mediálních typů
  Přidána možnost filtrovat akce podle použití mediálních typů v jejich operacích:
  • All (Vše): Zobrazení všech akcí bez ohledu na typ média.
  • All available (Všechny dostupné): Zobrazení akcí, které používají všechny dostupné mediální typy.
  • Specific (Specifické): Zobrazení pouze těch akcí, které používají konkrétní mediální typ.
• Automatická aktualizace widgetů na dashboardu
  Widgety na dashboardu nyní podporují automatickou aktualizaci. Například při výběru určitého prvku v jednom widgetu (např. mapa nebo seznam) se ostatní propojené widgety (např. seznam problémů) automaticky aktualizují podle nového kontextu.

Tato vylepšení přinášejí větší flexibilitu, použitelnost a zlepšují možnosti nasazení a monitorování v Zabbixu.

Nové a aktualizované šablony

Nové šablony:

• LAMP stack monitoring: Umožňuje monitorování Linuxu, Apache, MySQL a PHP pomocí aktivního Zabbix agenta.
• Juniper MX series: Šablona pro monitorování síťových prvků Juniper MX.
• Huawei OceanStor V6 Dorado: Pro sledování úložišť Huawei OceanStor.
• Nutanix Prism Element: Umožňuje monitorování hyperkonvergované infrastruktury Nutanix.
• NVIDIA GPU: Umožňuje sledovat využití GPU, paměti, teplotu a spotřebu energie s automatickým zjišťováním a předpřipraveným dashboardem.

Aktualizované šablony:

• Dell iDRAC a PowerEdge: Nyní využívají SNMP walk položky pro efektivnější sběr dat.
• Proxmox VE by HTTP: Přidány nové položky a triggery pro sledování využití diskového prostoru.
• MSSQL by ODBC: Opraveny dotazy na performance countery pro přesnější monitorování.
• Linux a Nextcloud: Odstraněny zbytečné preprocessing kroky z LLD pravidel pro zlepšení výkonu.
• Microsoft 365 reports by HTTP: Opraveny popisy pro lepší srozumitelnost.

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

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

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.

The post Nový Zabbix 7.2 je zde! appeared first on initMAX s.r.o..

V rámci těchto kurzů získáte nejen teoretické znalosti, ale také si vše vyzkoušíte v praktických cvičeních, což vám umožní okamžitě aplikovat nabyté dovednosti v reálném prostředí. Každé školení je navíc zakončeno certifikací, kterou získáte přímo od initMAX. Tento certifikát vám potvrdí vaši odbornou kvalifikaci a zlepší vaši pozici na trhu práce.

Přehled školení Wazuh

Naše nabídka školení pokrývá různé úrovně zkušeností a potřeby:

• Introduction to Wazuh
  Tento úvodní kurz poskytuje základy pro práci s Wazuh, včetně instalace, konfigurace a základních operací. Kurz je ideální pro IT profesionály, bezpečnostní analytiky a systémové administrátory, kteří jsou ve Wazuh noví a chtějí získat pevný základ. Absolvování kurzu je zakončeno teoretickou zkouškou a získáním certifikátu „Introduction to Wazuh“. Více o školení​
• Advanced Wazuh Configuration and Management
  Tento pokročilý kurz je určen pro zkušené uživatele Wazuh, kteří chtějí prohloubit své znalosti a naučit se pokročilé techniky konfigurace a ladění Wazuh. Kurz zahrnuje praktická cvičení a zakončuje se zkouškou, po jejímž úspěšném složení získáte certifikát „Advanced Wazuh Configuration and Management“. Více o školení​
• Integrating Wazuh with Enterprise Systems
  Tento závěrečný kurz je určen pro IT profesionály, bezpečnostní architekty a systémové integrátory, kteří potřebují integrovat Wazuh s dalšími podnikovými systémy, jako jsou SIEM řešení nebo cloudové služby. Kurz zahrnuje praktická cvičení a po jeho dokončení získáte certifikát „Integrating Wazuh with Enterprise Systems“. Více o školení​
• Wazuh for Compliance and Regulatory Requirements
  Tento kurz je zaměřen na profesionály z oblasti compliance, IT auditu a bezpečnosti, kteří potřebují zajistit dodržování regulací pomocí Wazuh. Kurz vás naučí, jak implementovat Wazuh tak, aby splňoval normy jako PCI DSS, GDPR nebo HIPAA. Součástí školení jsou praktická cvičení a kurz je zakončen certifikací „Wazuh for Compliance and Regulatory Requirements“. Více o školení​

Proč se školit u initMAX?

Naše školení jsou vedená zkušenými lektory, kteří mají hluboké praktické zkušenosti s implementací a správou bezpečnostních řešení. Díky tomu vám můžeme nabídnout nejen teoretické znalosti, ale i praktické tipy a triky z reálného světa. Kromě toho se naše kurzy konají v malých skupinách, což zajišťuje individuální přístup a maximální zapojení účastníků.

Pokud se chcete dozvědět více o našich školeních, navštivte naši stránku se školeními a certifikacemi​, kde najdete všechny potřebné informace včetně aktuálních termínů a možností registrace.

Pokud hledáte kvalitní školení v oblasti IT bezpečnosti a chcete získat certifikaci, která zvýší vaši hodnotu na trhu práce, neváhejte a přihlaste se na některý z našich kurzů zaměřených na Wazuh. Díky našim školením se stanete odborníkem, který dokáže efektivně implementovat a spravovat Wazuh ve vaší organizaci. Těšíme se na vás na našich kurzech!

The post Nové školení Wazuh s certifikací přímo od initMAX appeared first on initMAX s.r.o..

Nová verze Zabbix 7.0 LTS přináší řadu zajímavých novinek.

Nové widgety

Gauge widget – Tento widget umožňuje zobrazit měřenou hodnotu na škále s přesnou vizualizací, podobně jako na budíku. To umožňuje rychlé a snadné vyhodnocení stavu sledovaných metrik nebo ukazatelů. Gauge widget je ideální pro zobrazení měření, jako je teplota, vlhkost, rychlost přenosu dat nebo jakýkoli jiný číselný ukazatel. Je k dispozici velká škála možností nastavení.

Pie widget – Tento widget v Zabbixu nabízí různé možnosti vizualizace dat pomocí dvou základních zobrazení pro koláčové grafy: Pie (koláč) a Donut (kobliha).

• Pie (koláč) zobrazení je klasickým koláčovým grafem, který reprezentuje poměr jednotlivých prvků v rámci určitého datasetu. Každý prvek je zobrazen jako část koláče, přičemž velikost části je relativní k hodnotě nebo procentuálnímu podílu, který zastává ve srovnání s ostatními prvky.
• Donut (kobliha) zobrazení je variací koláčového grafu, která přidává prázdný prostor ve středu grafu, vytvářející efekt „koblihy“. Toto zobrazení umožňuje zobrazovat dodatečné informace nebo popisky ve středu grafu, které mohou sloužit k poskytnutí dalších detailů nebo kontextu.

Díky těmto dvěma zobrazením mohou uživatelé v Zabbixu snadno vizualizovat data pomocí koláčových grafů a získat přehled o poměru jednotlivých prvků v rámci jejich datasetu. Tímto způsobem mohou rychle identifikovat trendy, rozložení nebo vztahy mezi daty.

Honeycomb widget – Tento další, zcela nový widget umožňuje vytvářet šestiúhelníkové infografické bloky ve stylu včelí plástve zobrazující statistiky a informace na obou stranách v jednom celku. Widget umí filtrovat podle hostů, skupin hostů, host tagů, item tagů a regulérního výrazu itemů. Každá buňka obsahuje název položky nebo hosta její barvu se mění v závsilosti na konkrétní hodnotě položky.

Zde můžete vidět konfigurační možnosti, které tento nový widget umožnuje:

Top triggers widget – V tomto widgetu můžete vidět triggery, které nejčastěji změnily svůj stav během vyhodnocovaného období, seřazené podle počtu změn stavu. Můžete zde také filtrovat podle hostů, skupin hostů, tagů, názvu problému a severit. Kromě toho je zde také možnost nastavit počet zobrazených řádků.

Host navigator widget – Host Navigator Widget umožňuje uživatelům plynule přecházet mezi různými hosty prostřednictvím interaktivního rozhraní. S funkcí Override Host má schopnost ovlivňovat nastavení sousedních widgetů, jako jsou Item Widget, Honeycomb Widget a Gauge Widget, na základě zvoleného hosta. Tím poskytuje uživatelům možnost rychle a efektivně přizpůsobovat zobrazení dle kontextu vybraného hosta.

Item navigator widget – Item Navigator umožňuje uživatelům plynule přecházet mezi různými položkami prostřednictvím interaktivního rozhraní. Díky možnosti výběru položky na kompatibilních widgetech, jako je Item Widget a Plain text, má schopnost zobrazovat hodnoty na základě výběru provedeného ve Widgetu Item Navigator. To uživatelům umožňuje rychle a efektivně upravit zobrazení podle kontextu vybraného hosta.

Item history widget – Tento nový typ widgetu umožňuje pokročilé zobrazování historických dat jednotlivých položek. Data zobrazuje v tabulkovém režimu, buďto v horizontálním nebo vertikálním rozložení. Jednotlivé, vybrané položky s jejich historickými daty tvoří sloupce, přičemž maximální množství zobrazovaných řádků je 100. Nastavením lze ovlivnit to, jak budou nové hodnoty do widgetu přibývat, jestli odshora dolů, anebo obráceně. Zobrazení časové značky (timestamp) a časového rozsahu historických dat je rovněž volitelné. Největší devizou tohoto widgetu je pak jeho schopnost zobrazovat i data binární, tedy např. screenshoty z nového typu položky „Browser“ (viz náš screenshot níže). Widget je kompatibilní s Item Navigator a Host Navigator widgety.

Rozšířená dostupnost widgetů v šablonách

Dříve v šablonách bylo možné vytvářet pouze následující widgety: Hodiny, Graf (klasický), Prototyp grafu, Hodnota položky, Prostý text, URL.

Nyní šablony podporují vytváření všech widgetů.

Zabbix Proxy v režimu vysoké dostupnosti (HA)

Novou a veskrze převratnou novinkou, kterou nová verze Zabbixu přináší je možnost použít Zabbix Proxy v řežimu vysoké dostupnosti.

Přímo na toto zajímavé téma jsme pro Vás připravili workshop zdarma!

Cluster běží v režimu active-active a nefunguje pouze pro potřeby failover/failback, ale řeší také loadbalancing jednotlivých hostů.

Pro tyto účely vznikla v menu nová položka, a to sekce Administration -> Proxy groups.

Zde se vytvářejí skupiny Zabbix Proxy serverů, které následně budou v fungovat jako cluster – v režimu HA.

V nastavení skupiny je pak možné nastavit patřičné quorum clusteru (Minimum number of proxies) a časou prodlevu pro failover (Failover period).

Zde můžete vidět vytvořený cluster (Proxy group) s dvěma přiřazenými nodes.

Zároveň s touto funkcionalitou se mění i možnosti nastavení jednotlivých hostů.

Toto nastavení nyní reflektuje možnost monitorování pomocí clusteru Zabbix Proxy serverů, a konfigurační položka Monitored by nyní obsahuje možnosti Server, Proxy a Proxy group.

Na tomto obrázku je vidět nově nastavenou Proxy group, ale prozatím se v sekci Assigned proxy nezobrazí žádný přiřazený proxy server.

Ve chvíli, kdy se data o novém nastavení dostanou do konfigurační cache obou Zabbix Proxy serverů, které jsou nyní součástí clusteru, tak Zabbix rozhodne, který konkrétní člen clusteru bude tento host monitorovat a danou proxy mu přiřadí.

Na obrázku níže můžete vidět konkrétní přiřazený proxy server z clusteru.

V sekci Administration -> Proxies jsou pak nově viditelné Proxy groups, do kterých dané Zabbix Proxy servery patří.

V případě výpadku jednoho z proxy nodes se tento server bude tvářit stále ve stavu Online až do té doby, než uplyne přednastavený časový interval (Failover period).

Zde vidíte, že po uplynutí intervalu 1 minuty je node ve stavu Offline a monitorovaný host má nyní přiřazený nový proxy server – druhý node v clusteru.

V případě obnovení provozu původního proxy node bude tento stále svítit červeně jako nedostupný, dokud neuplyne předdefinovaný interval (v našem případě 1 minuta).

Po uplynutí přednastaveného intervalu pak opět vidíme původní proxy server v řežimu online, ale monitorovaný host je stále přiřazen na stejný node v clusteru.

Cluster totiž funguje v režimu active-active a v tuto chvíli tedy není důvod pro přepínání hosta zpět.

Nový item Browser

Nový „Browser“ item využívá Selenium jako prostředníka pro kompletní načítání webových stránek s JavaScriptem.

I na toto téma jsme pro Vás připravili workshop zdarma!

Tento item umožňuje tvorbu komplexních monitorovacích scénářů, včetně automatického zachycení snímků obrazovky na konci procesu. Uživatelé mohou uložit snímky jako binární data pomocí závislých položek. Je potřeba nainstalovat Selenium jako samostatnou komponentu.

Ukázka JavaScriptu uvnitř nastavení browser itemu.

Výsledek testu a ukázka dat.

{
    "duration": 1.004,
    "performance_data": {
        "details": [
            {
                "navigation": {
                    "entry_type": "navigation",
                    "dom_content_loaded_event_start": 462.1,
                    ...
                    "connect_start": 18,
                    "duration": 910,
                    "type": "navigate"
                },
                "resource": {
                    "response_time": 5174.8,
                    ...
                    "request_time": 287.7
                }
            }
        ],
        "summary": {
            "navigation": {
                "dom_content_loading_time": 2.2,
                ...
                "min_protocol": "http/1.1"
            },
            "resource": {
                "response_time": 5174.8,
                ...
                "request_time": 287.7
            }
        }
    }
}

A to, jak to může vypadat na dashboardu i se screenshoty můžete vidět zde:

Rozšířená možnost úprav uživatelských médií u JIT

Ve verzi Zabbixu 6.4 přibyla možnost nastavit ověřování pomocí externího autentizačního providera i s využitím JIT, ovšem chyběla možnost nastavení parametrů automatického přiřazování uživatelských médií, jejich aktualizace anebo možnost ručních úprav.

Toto se u verze 7.0 mění a nejenže jsou média nyní automaticky přiřazena a aktualizována, ale na úrovni mapování médií můžeme nyní nastavit, s jakými parametry se vytvoří.

Další novou funkcionalitou, kterou v této oblasti verze 7.0 přináší je možnost automaticky vytvořená média měnit, anebo ručně přidávat nová.

Možnost nativní dvoufaktorové autentifikace (MFA) byla přidána do Zabbixu

Nyní máte možnost volitelně využít dvoufaktorovou autentifikaci (MFA). Můžete zde použít TOTP nebo DUO Universal Prompt. Tyto metody můžete používat různě pro různé uživatelské skupiny.

• TOTP znamená „Time-based One-Time Password“ a představuje jednorázové heslo založené na čase. Jedná se o mechanismus dvoufaktorové autentifikace, kde uživatel kromě běžného hesla generuje jednorázový kód založený na aktuálním čase. Tato metoda zvyšuje bezpečnost, protože heslo platí jen po omezenou dobu a nemůže být použito opakovaně.
• Typicky se TOTP generuje pomocí mobilních aplikací, jako je například Google Authenticator nebo Authy. Uživatel zobrazí aktuální kód z aplikace a zadá ho společně s běžným heslem při přihlašování. Každý kód je platný jen po omezenou dobu, obvykle po dobu 30 sekund až několika minut, což zvyšuje bezpečnost autentizace.

• DUO Universal Prompt je funkce od společnosti Duo Security, která slouží k vylepšení a zjednodušení procesu vícefaktorové autentizace (MFA). MFA je bezpečnostní metoda, která vyžaduje, aby uživatelé prokázali svoji identitu pomocí více než jednoho ověřovacího mechanismu při přístupu k chráněným systémům a službám. Typicky zahrnuje něco, co uživatel zná (například heslo), něco, co má (například mobilní telefon), nebo něco, co je (například otisk prstu).
• Universal Prompt je navržen tak, aby byl kompatibilní s širokým spektrem zařízení a platforem, a poskytuje rozšířené možnosti pro správu a nastavení politik autentizace podle potřeb organizace. Jeho použití může výrazně zvýšit celkovou bezpečnost přístupu k citlivým datům a službám, zatímco zároveň snižuje komplikace a frustraci spojenou s tradičními metodami MFA.

Základní nastavení MFA naleznete v sekci Users > Authentication > MFA settings.

Definovaná MFA z předchozího kroku se následně aplikuje na úrovni uživatelské skupiny.

Při prvním přihlášení v této uživatelské skupině po aplikování nastavení MFA vás Zabbix vyzve k ověření pomocí vašeho vybraného autentizátoru, například Authenticator od Google. Nastavení je tímto pro daného uživatele dokončeno.

V systémových informacích naleznete informace o verzích a dostupných aktualizacích

Zabbix 7.0 přidává nový endpoint, který umožňuje sledovat aktuálně používané verze jak na straně serveru, tak na frontendu. Uživatelé zde budou informováni o dostupnosti nové verze, konkrétně o poslední dostupné verzi a odkazu na příslušné poznámky k vydání. Tato funkce usnadní správu verzí a udržování aktuálního systému. Kontrola verzí se dá v případě potřeby zakázat na straně serveru. Standardně aktualizace stavu probíhá každých 8 hodin.

Pokročilá nastavení jsou nyní vysouvací

Zaškrtávací políčka, která doposud sloužila k zobrazování pokročilých konfigurací (Advanced configuration) byla nyní nově nahrazena vysouvacími bloky. To ve výsledku značně zlepšuje uživatelský komfort, protože sbalení těchto bloků a uložení konfigurace již neresetuje nakonfigurované pokročilé možnosti na výchozí hodnoty, jak tomu bylo v případě použití zaškrtávacích políček.

Spouštění globálních skriptů lze zakázat

Spouštění globálních skriptů na serveru Zabbix může být zakázáno nastavením EnableGlobalScripts=0 v konfiguraci serveru. Pro nové instalace je spouštění globálních skriptů na serveru Zabbix výchozím nastavením zakázáno. Toto zakázání spouštění skriptů je možné přímo vidět v uživatelském rozhraní jako informace.

Nové asynchronní procesy

Procesy „agent poller„, „http agent pollers“ a „snmp poller„, byly nahrazeny novými, asynchronními variantami a jsou tedy nyní schopné provádět více kontrol současně.

Staré, původní verze těchto procesů byly pouze synchronní, mohly provést v danou chvíli pouze jeden jediný úkon a následně čekaly na odpověď. Nově se nyní v průběhu fáze čekání na odpověď spustí další, paralelní procesy. Rychlost a efektivita monitoringu tedy doznala razatního zlepšení.

Konfiguraci těchto procesů provedete úpravou direktiv „StartHTTPAgentPollers“ a nově tedy i „StartAgentPollers“ a „StartSNMPPollers„.

Počet souběžných dotazů pak lze regulovat pomocí nové direktivy „MaxConcurrencyCheckPerPoller„, a to až na maximální hodnotu 1000.

Zároveň s těmito změnami byla pro HTTP kontroly nově implementována i cURL funkce persistentních spojení.

V souvislosti s implementací asynchronního SNMP byla současně přidána i funkce pro asynchronní DNS resolving.

Vícevláknové zpracování

V rámci přechodu na vícevláknovou architekturu bylo provedeno několik změn:

• Byl přidán nový konfigurační parametr: --with-stacksize, který umožňuje přepsat výchozí nastavení „thread stack size“ používané systémem.
• Počítání uživatelských maker bylo přesunuto z preprocessing managera na preprocessing workery.

Možnost spustit vzdálené příkazy na aktivních agentech

Počínaje Zabbix Agentem verze 7.0 je nyní možné provádět vzdálené příkazy na agentovi, který pracuje v aktivním režimu. Jakmile je spuštění vzdáleného příkazu spuštěno akční operací nebo ručním spuštěním skriptu, příkaz bude zahrnut do konfigurace aktivních kontrol a proveden, jakmile jej aktivní agent přijme. Všimněte si, že starší aktivní agenti budou ignorovat všechny vzdálené příkazy zahrnuté v konfiguraci aktivních kontrol.

Zakázání nebo mazání neobjevených sond pomocí objevovacích pravidel (LLD)

V nové verzi Zabbixu přichází s novou možností neodstraňovat a zakazovat sondy, které již nejsou nalezeny pomocí pravidel pro dynamické objevování (LLD). Tato funkce umožňuje uživatelům vybrat mezi třemi možnostmi pro zacházení se sondami: nikdy je nesmazat, smazat je okamžitě nebo po určité době. Kromě toho je také možné zvolit, zda zakázat nalezené sondy: opět můžete vybrat mezi možnostmi nikdy, okamžitě nebo po určité době. Zajímavou funkcí je možnost kombinovat nejprve zakázání sondy a později její smazání po určité době. Tato flexibilita umožňuje uživatelům přesně nastavit, jak chcete, aby se systém choval vůči nalezeným sondám, což pomáhá optimalizovat správu prostředků a udržet systém v efektivním stavu.

Paralelní zpracování při síťovém objevování

Dříve bylo každé pravidlo pro objevování sítě zpracováváno jedním procesem. Tím pádem mohly být všechny kontrolní služby v rámci pravidla prováděny pouze sekvenčně.

V nové verzi byl proces síťového objevování přepracován tak, aby umožňoval paralelní zpracování kontrolních služeb. Byl přidán nový proces „discovery manager“ spolu s konfigurovatelným počtem „discovery workers“ (pracovníků objevování).

Výchozí počet StartDiscoverers byl zvýšen z 1 na 5 a rozsah z 0-250 na 0-1000.

Zabbix proxy nyní využívá vyrovnávací paměť

Nově byla pro Zabbix proxy vyvinuta vyrovnávací paměť, kde jsou ukládána nová data. Ta jsou přeposílána Zabbix serveru bez toho, aniž by bylo nutné přistupovat k databázi, což opět přispívá k celkovému zvýšení výkonnosti.

Pro optimální výkonnost této funkcionality se doporučuje použití vyrovnávací paměti na úrovni proxy nastavit. To je možné úpravou konfigurační direktivy „ProxyBufferMode“ z hodnoty „disk“ (natvrdo nastavená implicitní hodnota pro již existující instalace) na doporučovanou hodnotu „hybrid“ nebo hodnotu „memory„.

Dále je nutné nastavit velikost této vyrovnávací paměti, k čemuž slouží parametr „ProxyMemoryBufferSize„.

Pokud je proxy zastavena, vyrovnávací paměť je plná nebo data příliš stará, pak je vyrovnávací paměť v režimu „hybrid“ chráněna před ztrátou dat tím, že odloží neodeslaná data do databáze, a po zapsání všech hodnot se pak proxy navrátí k používání vyrovnávací paměti. V režimu „memory“ bude využita pouze vyrovnávací paměť a výkon je tak potenciálně vyšší, ale neexistuje zde žádná ochrana proti ztrátě dat.

Oddělené databázové tabulky pro Zabbix Proxy

Data o Zabbix Proxy byla v databázi přesunuta z tabulky „hosts“ a jsou nyní uložena v nové tabulce „proxy„.

Také provozní data o Zabbix Proxy (jako je verze, kompatibilita nebo poslední odezva) byla přesunuta z tabulky „host_rtdata“ a jsou nyní uložena v nové tabulce „proxy_rtdata„.

Skripty s parametry

Interní definice skriptů do této chvíle neměly možnost zaslání parametru na vstup, a tak se každé volání skriptu s konkrétním parametrem muselo definovat zvlášť.

Toto se v Zabbix verzi 7.0 mění a skripty nyní umí přijmout vstupní parametr tak, že v Zabbix frontendu stačí vydefinovat konkrétní skript a dostupné parametry mu pak lze vydefinovat pomocí jednoduchého průvodce s přednastavenými, dostupnými možnostmi (dropdown menu).

Zde můžete vidět možnosti nastavení, pokud zvolíte tento přístup:

A na následujících screenshotech můžete vidět, jak celý proces spuštění skriptu s parametry definovanými pomocí „drop-down menu“ probíhá přímo na úrovni hosta.

Další volbou je v tomto případě také možnost nastavit vložení parametrů konkrétnímu skriptu manuálně, a to i s případnou (a poměrně nezbytnou) validací těchto přeposlaných hodnot už na vstupu, na úrovni Zabbix frontendu.

Příklad konfigurace můžete vidět zde:

Spuštění takového typu parametrizováného skriptu pak vypadá následovně:

A zde vidíme výsledek spuštění:

Zjednodušené klonování

V nové verzi Zabbix 7.0 LTS je změněn proces klonování hostů, šablon nebo map. Dříve existovaly dvě možnosti klonování, přičemž nyní zcela zmizela možnost „jednoduchého“ klonování (Clone) a tato je pak zcela nahrazena klonováním plným (Full clone), se všemi jeho funkcionalitami.

Odkaz na dokumentaci pro každou standardní položku

Každá standardní položka má nyní přímý odkaz z frontendu na stránku dokumentace.

Více stránkový PDF reporting

Plánovaný reporting (Scheduled reports) nyní pro více stránkové dashboardy zasílá report, který obsahuje všechny tyto stránky.

Každá stránka vygenerovaného PDF odpovídá jedné stránce dashboardu.

Dříve byla tato funkce omezena pouze na první stránku, a to i pro více stránkový dashboard.

Na téma reportingu v Zabbixu 7.0 jsme pro vás připravili samostatný webinář, který můžete zhlédnout zde:

Nastavení timeout specificky pro item / proxy / server

Další, revoluční vychytávkou v Zabbix 7.0 LTS je nyní možnost nastavení timeout pro jednotlivé items.

V případě potřeby je možnost nastavit v Administration > Proxies v záložce Timeouts na samotné proxy nastavit vlastní nastavení pro timeouty.

Časový limit lze nastavit v rozmezí 1 – 600s, a to přímo ve frontendu pro konkrétní item anebo limity určit globálně.

Tato možnost výrazně napomůže výkonnosti a optimalizaci celého monitoringu vůčihledně vaší IT infrastruktury a jejím možnostem, a odpadne nutnost překompilovat Zabbix agenta s ručně nastavenými časovými limity například v případě, že pro monitoring databáze používáte složitější SQL dotazy.

Nové funkce

Byly přidány nové funkce pro použití ve výrazech triggerů (trigger expressions) a vypočítaných položkách (calculated items):

• jsonpath() – vrátí výslednou JSONPath
• xmlxpath() – vrátí výslednou XML XPath

Aktualizované funkce

Bylo aktualizováno několik funkcí:

• Agregační funkce nyní podporují pro výpočet také nečíselné typy. To může být užitečné například u funkcí count a count_foreach.
• Agregační funkce count a count_foreach podporují volitelné parametry operátor a vzor (pattern), které lze použít k doladění filtrování položek a spočítat pouze hodnoty, které odpovídají daným kritériím.
• Všechny funkce foreach nyní již nezahrnují do výpočtu nepodporované položky (unsupported items).
• Funkce last_foreach, dříve nastavená tak, aby ignorovala argument časového období, jej nyní přijímá jako volitelný parametr.

Odesílání dat Zabbix serveru pomocí API

Dříve bylo odesílání dat Zabbix serveru možné pomocí nástroje zabbix-sender, anebo implementací vlastního komunikačního protokolu založeného na JSON.

Nově je nyní také možné posílat data na Zabbix server přes HTTP protokol pomocí API metody history.push.

Příjem odeslaných dat vyžaduje nakonfigurovanou položku Zabbix trapper nebo položku HTTP agent (se zapnutým trappingem).

Úspěšné operace API metody history.push jsou také zaznamenány v sekci Reports -> Audit log, a tato metoda je také dostupná v seznamu metod API při konfiguraci uživatelských oprávnění.

Příklad použití této API metody můžete vidět zde:

{​
    "jsonrpc": "2.0",​
    "method": "history.push",​
    "params": [​
        {​
            "itemid": 10600,​
            "value": 0.5,​
            "clock": 1690891294,​
            "ns": 45440940​
        },​
],​
    "id": 1​
}​

Auditlog převeden na hypertabulku v TimescaleDB

Tabulka auditlog byla v nových instalacích převedena na hypertabulku v TimescaleDB tak, aby využila lepšího výkonu a také automatického partitioning závislém na čas (ve výchozím nastavení 7 dní).

Chcete-li úspěšně aktualizovat stávající instalace, musíte před spuštěním serveru Zabbix znovu spustit skript timescaledb.sql umístěný v cestě database/postgresql.
Pokud je první spuštění Zabbix serveru bez toho, aniž by předtím byl spuštěn tento skript, pak vyskočí varovná hláška.

Zvýšený limit počtu znaků

Limit počtu znaků pro všechna pole adresy URL je nyní 2048 znaků a limit znaků pro veškerá autentizační pole User/Username i Password je taktéž navýšen, a to na 255 znaků.

Podpora pro starý numerický typ byla zrušena

Starý styl desetinných čísel, který byl dříve označen jako zastaralý, již není podporován, protože jsou používány číselné hodnoty s rozšířeným rozsahem (Float64).

Oracle RDBMS označena jako zastaralá

Od Zabbix verze 7.0 LTS byla databáze Oracle označena jako zastaralá a v následujících verzích bude podpora Oracle DB pro backendovou databázi i zcela odstraněna.

Odstraněna podpora pro TimescaleDB v1

Podpora pro databázi TimescaleDB verze 1 byla označena jako zastaralá a Zabbix verze 7.0 LTS ji tudíž již nepodporuje.

Nové šablony

• Acronis Cyber Protect Cloud
• AWS Cost Explorer
• AWS ECS
• AWS ELB Application Load Balancer
• AWS ELB Network Load Balancer
• Azure Cost Management
• Check Point Next Generation Firewall
• Cisco Meraki
• Cisco SD-WAN
• FortiGate
• HashiCorp Nomad
• HPE iLO
• MSSQL by Zabbix Agent 2
• MantisBT
• NextCloud
• OpenStack Nova
• Oracle Cloud Infrastructure
• PostgreSQL by ODBC
• Website by Browser
• YugabyteDB

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

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

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.

The post Nový Zabbix 7.0 LTS appeared first on initMAX s.r.o..

Veselé Vánoce přeje tým initMAXu. Děkujeme Vám za důvěru a spolupráci v roce 2023, přejeme pohodové Vánoce a mnoho úspěchů v roce novém.

The post Veselé Vánoce 2023 přeje initMAX appeared first on initMAX s.r.o..

Hans nám věnoval volné vouchery pro konferenci a rádi bychom se podělili o tuto výhodu s našimi fanoušky. Máme pro vás dva volné vouchery, které můžete získat účastí v naší giveaway. Vyplňte prosím krátký formulář zde a 11. prosince dopoledne provedeme losování. Výsledky obdrží všichni účastníci emailem.

Informace o konferenci naleznete zde: https://2023.pgconf.eu/

Hodně štěstí a těšíme se na setkání s vámi na konferenci!

Podívejte se na naše nová certifikovaná školení nejen pro PostgreSQL.

• Základy SQL
• Úvod do PostgreSQL
• PostgreSQL Professional
• PostgreSQL – správa a ladění výkonu
• PostgreSQL – vysoká dostupnost a Patroni
• PostgreSQL v Kubernetes
• Úvod do PostGIS
• Migrace na PostgreSQL

S čím Vám například pomůžeme v rámci služeb a konzultací?

• CYBERTEC PostgreSQL Support
• CYBERTEC PGEE
• CYBERTEC Migrator
• CYBERTEC Consulting Pool Remote
• CYBERTEC Assessment Packages
• CYPEX

The post Rozdáváme vstupenky na konferenci PostgreSQL Conference Europe appeared first on initMAX s.r.o..

Zabbix Certified partnerství

Získání titulu Zabbix Certified Partnera je pro nás nejen velkou ctí, ale i zárukou kvality našich služeb. Jsme pyšní na to, že můžeme podporovat a implementovat produkty Zabbix na Slovensku a přinášet našim klientům vynikající monitorovací řešení.

Zabbix Certified Trainer

Dále jsme hrdi na to, že jsme získali certifikaci Zabbix Certified Trainera. Tato akreditace nám umožňuje poskytovat profesionální školení týkající se produktů Zabbix. Věříme, že znalosti, které předáme, budou pro naše klienty klíčové pro efektivní využívání monitorovacích nástrojů a optimalizaci jejich IT infrastruktury.

Rozšířené portfolio služeb

S naším příchodem na slovenský trh přinášíme široké portfolio služeb nad rámec produktů Zabbix. Naši zákazníci na Slovensku teď mohou využívat našich profesionálních služeb a konzultačních dovedností, abychom jim pomohli dosáhnout optimálního výkonu a spolehlivosti své IT infrastruktury.

Více o ZABBIX

Více o Wazuh

Více o PostgreSQL

A další naše služby naleznete zde

Budoucnost Spolupráce

Těšíme se na budoucnost, která přináší nové možnosti a výzvy. S pevným základem certifikovaných odborníků a širokým portfoliem služeb jsme připraveni podporovat slovenské klienty na jejich cestě k efektivnímu řízení a monitorování IT prostředí.

Pokud máte nějaké otázky nebo zájem o naše služby, neváhejte nás kontaktovat. Jsme tu, abychom vám pomohli dosáhnout optimálního výkonu vaší IT infrastruktury.

Děkujeme za důvěru a těšíme se na vzájemně prospěšnou spolupráci!

Pokud by vás zajímala živá ukázka instalací Zabbixu u našich zákazníků, rádi vás pozveme na kávu a ukážeme vám Zabbix v praxi 😊. 

Můžete se například těšit na:

• začlenění monitoringu do DevOps
• automatický deployment monitoringu pro klienty
• high picture pohled na kritickou business infrastrukturu
• dynamické grafické znázornění napříč celou infrastrukturní i businessovou částí
• notifikace
• eskalace
• automatizace změn na infrastruktuře, která pomůže snížit náročnost správy celé vaší infrastruktury.
• vlastní widgety a skripty naleznete v našem GIT repozitáři https://git.initmax.cz/initMAX-Public

The post Expandovali jsme na Slovensko a stali se Zabbix Certified Partnerem appeared first on initMAX s.r.o..

Díky tomuto kroku Vám můžeme nabídnout certifikovaná PostgreSQL školení a také veškeré služby společnosti CYBERTEC s podporou v lokálním jazyce s přímým napojením na výrobce. Naši stávající zákazníci tímto získali benefit rychlé reakce a možnosti ovlivnit přímo zdrojový kód produktu PostgreSQL. A samozřejmě se těšíme na další z Vás, kteří nám svěří svou databázi.

Podívejte se na naše nová certifikovaná školení nejen pro PostgreSQL.

• Základy SQL
• Úvod do PostgreSQL
• PostgreSQL Professional
• PostgreSQL – správa a ladění výkonu
• PostgreSQL – vysoká dostupnost a Patroni
• PostgreSQL v Kubernetes
• Úvod do PostGIS
• Migrace na PostgreSQL

S čím Vám například pomůžeme v rámci služeb a konzultací?

• CYBERTEC PostgreSQL Support
• CYBERTEC PGEE
• CYBERTEC Migrator
• CYBERTEC Consulting Pool Remote
• CYBERTEC Assessment Packages
• CYPEX

The post Jsme prvním certifikovaným partnerem společnosti CYBERTEC appeared first on initMAX s.r.o..

Wazuh je vynikající open-source bezpečnostní platforma, která umožňuje organizacím včas identifikovat a reagovat na různé bezpečnostní hrozby.

Mirkův úspěch přináší významný přínos našim stávajícím i novým zákazníků, kteří mohou využívat Wazuh jako službu pro ochranu svých citlivých dat. Díky znalostem a schopnostem, které náš kolega získal, můžeme poskytovat našim zákazníkům ještě kvalitnější služby v oblasti kybernetické bezpečnosti.

Mirku, ještě jednou gratulujeme k tvému úspěchu a jsme velmi hrdí na tvůj přínos pro initMAX.

Jako Wazuh partner pro Vás chystáme také oficiální školení v češtině. Budeme Vás informovat o dalších krocích.

The post Získali jsme další certifikaci Wazuh for Security Engineers appeared first on initMAX s.r.o..

Nová verze Zabbix 6.4 přináší řadu zajímavých novinek.

Nové rozložení menu

Nová verze přináší aktualizované rozvržení menu, ve kterém došlo k těmto změnám:

• Dashboardy dostaly vlastní samostatnou položku
• Vznikla nová nabídka Alerts, která sdružuje vše ohledně alertingu včetně všech typů akcí (TriggerActions, ServiceActions atd.)
• Přidána byla také nová nabídka Users obsahující vše ohledně správy uživatelů, jako jsou User groups (Skupiny uživatelů), User roles (Role uživatelů), Users (Uživatelé), API tokens (Tokeny API) a Authentication (Ověřování)
• Zatím poslední novinkou je nová nabídka Data collection (Sběr dat), ta nahrazuje předchozí nabídku Configuration (Konfigurace) a obsahuje podsekce, které se týkají konfigurace sběru dat.

Podpora Zabbix serveru pro starší verze proxy

V prostředí server-proxy je upgrade výrazně flexibilnější. Nyní Zabbix server oficiálně podporuje shromažďování dat, provádění vzdálených příkazů a okamžité kontroly hodnoty položek prostřednictvím zastaralých proxy serverů, které nejsou starší než předchozí verze LTS serveru Zabbix.

Vylepšené kontextové nabídky

Kontextové nabídky pro items, hosts a events prošly značným vylepšením.

Kontextová nabídka hosta nyní nabízí možnosti přechodu na seznam itemů, triggerů, discovery rules nebo webových scénářů.

V kontextové nabídce pro Item lze nyní:

• zobrazit a prokliknout na triggery navázané na item
• vytvořit trigger, dependent item nebo discovery rule navázané na vybranou položku
• prokliknout na Latest data vybrané položky

A konečně kontextová nabídka eventu nyní nabízí možnost:

• potvrdit nebo aktualizovat problém
• zobrazit všechny položky používané spouštěčem problému a přejít ke konfiguraci kterékoli z nich

Automatizace vytváření účtů z LDAP a SAML

Možnost automatického vytváření uživatelů je dlouho očekávanou a žádanou novinkou. Od verze Zabbixu 6.4 je tedy možné spravovat uživatele a jejich oprávnění, včetně mapování na skupiny, prostřednictvím AD, LDAP nebo SAML.

Snadnější konfigurace typu média (Media Type) pro Gmail a Office365

Uživatelé Gmailu nebo Office365 mohou nyní využívat snadnější konfiguraci typu média. Nové pole Email provider v konfiguraci typu poštovního média umožňuje vybrat předkonfigurované možnosti pro Gmail a Office 365 (vedle možnosti „Generic SMTP“, která funguje stejně jako dříve).

Vyberete-li O365 nebo Gmail je nyní vyžadována pouze e-mailová adresa a heslo. Zabbix automaticky vyplní všechna požadovaná nastavení pro tyto typy médií aktuálními/doporučenými hodnotami, tj. server SMTP, port serveru SMTP, helo SMTP a zabezpečení připojení.

Dynamická barva pozadí pro widget Item Value

Widget Hodnota položky nyní umožňuje konfigurovat dynamickou barvu pozadí na základě nastavených prahových hodnot a poslední přijaté hodnoty.

Povinné zadání starého hesla při změně hesla

Nově bude při změně hesla vyžadováno zadání původního hesla.

Optimalizace SNMP

Byla přepracována část SNMP volání využívajcí BULK volání. Nově Zabbix přistupuje k více metrikám stejně jako standartní bulk volání. Tato úprava například řeší, problemy při využítí proxy a SNMP Discovery, kdy zabbix nebyl schopen nareportovat veškerá data a nebo se v Zabbixu objevila hláška: „SNMP error: noCreation (That table does not support row creation or that object can not ever be created)“.

Nový item snmp.walk

Od Zabbixu verze 6.4 je k dispozici nový item snmp.walk[], vracející víceřádkový seznam hodnot.

Například snmp.walk[1.3.6.1.2.1.2.2.1.2,1.3.6.1.2.1.2.2.1.3] vrátí:

.1.3.6.1.2.1.2.2.1.2.1 = STRING: "lo"
.1.3.6.1.2.1.2.2.1.2.2 = STRING: "ens33"
.1.3.6.1.2.1.2.2.1.2.3 = STRING: "ens37"
.1.3.6.1.2.1.2.2.1.3.1 = INTEGER: 24
.1.3.6.1.2.1.2.2.1.3.2 = INTEGER: 6
.1.3.6.1.2.1.2.2.1.3.3 = INTEGER: 6

Nové možnosti preprocessingu

V souvislosti se změnami v SNMP přibyly i dvě nové, velice užitečné, možnosti preprocessingu:

• SNMP walk value – Vybere hodnotu podle zadaného názvu OID/MIB a použije na ni zvolené formátování.
• SNMP walk to JSON – Převede SNMP do formátu JSON.

Příčina a příznaky problémů

V novém Zabbixu 6.4, přibyla i možnost označit vzniklé eventy jako vedlejší symptom většího problému. Například když selže switch, že je problém se switchem a vše ostatní je symptom nikoli hlavní problém. Stačí vybrat všechny problémy a kliknout na název eventu, který chcete označit za ten hlavní.

Ack odkaz přejmenován na update

Ack (Potvrzení) odkaz v seznamu problémů byl přejmenován na Update, aby název lépe odrážel možnosti, které jsou v posledních verzích k dispozici pro aktualizaci problémů.

Verzování šablon

U šablon se nyní zobrazuje její verze a vendor. Jedná se o další krok k verzování šablon přímo v Zabbixu. Zatím se jedná pouze o vizualizaci nikoliv o samotné verzování, už ale máme myšlenku jak tuto funkcionalitu využít pro Zabbix modul s napojenim na git.

Podpora streamování metrik a událostí do externích systémů přes HTTP

Nově bude možné v reálném čase přeposílat metriky do dalších systémů. Konkrétně se dají zasílat naměřené metriky a vzniklé události. Je zde možné filtrovat pomocí TAGů a je zde i možnost navolit si přihlášení na cílový konektor a to jménem a heslem a nebo certifikátem. Další možnosti jsou například zvolení počtu paralelních spojení a zda se posílají zprávy dávkově nebo jednotlivě. Volání probíhá metodou POST.

Příklad odeslaného požadavku:

POST / HTTP/1.1
Host: log-management.initmax.cz
Accept: */*
Accept-Encoding: deflate, gzip, br
Content-Type: application/x-ndjson
Content-Length: 4869{"host":{"host":"demo.initmax.cz","name":"demo.initmax.cz"},"groups":["Zabbix","Connector","DEMO"],"item_tags":[{"tag":"Target","value":"OpenSearch"},{"tag":"Target","value":"WAZUH"}],"itemid":147414,"name":"Demo item value, % free","clock":1675972194,"ns":97908485,"value":99.745535424749832,"type":0}

Import konfigurace

Do konfiguračního formuláře pro import šablon/hostů přibyla nová možnost importovat vše. Pokud zaškrtnete Vše, budou pro import označeny nebo odznačeny všechny importovatelné položky.

Chcete-li zobrazit seznam možností v pravidlech importu, je nyní nutné zaškrtnout políčko Rozšířené možnosti.

Další změnou je, že možnost Odstranit chybějící je nyní ve výchozím nastavení zaškrtnuta.

Nový framework pro widgety a dokumentace pro vývojáře

V Zabbix dokumentaci nově naleznete sekci s návody na použítí nového frameworku s funkčním příkladem na novém budíkovém widgetu.

Widget je k vidění na našem DEMO zabbixu.

Demo Zabbix naleznete zde: https://www.initmax.cz/zabbix/

Dokumentece k frameworku: zde

Nové šablony

• AWS RDS instance by HTTP
• AWS S3 bucket by HTTP
• Azure by HTTP
• OPNsense by SNMP
• Cisco Meraki dashboard by HTTP
• Veeam Backup and Replication by HTTP
• Veeam Backup Enterprise Manager by HTTP

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

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

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.

The post Nový Zabbix 6.4 je zde appeared first on initMAX s.r.o..

Zejména v případě serverů a firemních aplikací je nutné pohlížet na jejich zabezpečení z více stran a ve více vrstvách. A právě tady přichází na řadu platforma Wazuh, která pomáhá získat celkový přehled a kontrolu nad stavem zabezpečení IT infrastruktury.

Celé řešení, označované také jako SIEM, se skládá z jediného univerzálního agenta, nainstalovaného na sledovaném zařízení a tří centrálních komponent: serveru Wazuh, indexeru Wazuh a ovládacího panelu Wazuh.

Proč jsme zvolili Wazuh jako SIEM?

Platforem pro bezpečnostní monitoring, především těch komerčních, je mnoho. Wazuh nás zaujal především svými schopnostmi, záběrem a svojí otevřeností.

Wazuh využívá ke zlepšení svých detekčních schopností více různých zdrojů informací o hrozbách. Obohacuje získaná data pomocí MITRE ATT&CK frameworku a compliance a regulatorních požadavků jako jsou PCI DSS, GDPR, HIPAA, CIS a NIST 800-53, a poskytuje tak užitečný kontext pro získání celkového přehledu a kontroly nad děním a stavem IT infrastruktury.

Jak vám může Wazuh pomoci se zabezpečením

Analýza logů a jejich archivace

V mnoha případech lze důkazy o podezřelých činnostech nalézt v logu sledovaného systému nebo aplikace. Wazuh pomůže s automatizací správy a analýzy logů a tím může urychlit odhalování hrozeb a to jak vnějších, tak vnitřních.

Díky silnému indexeru pomáhá také s uchováním logů pro další forenzní analýzu a také pro naplnění regulatorních a interních retenčních požadavků.

Inventarizace systému

Modul inventarizace shromažďuje informace o hardwaru a softwaru ze sledovaného systému. Tento nástroj pomáhá identifikovat aktiva a vyhodnocovat účinnost správy záplat.

Shromážděná inventární data pro každý ze sledovaných zařízení lze vyhledávat prostřednictvím rozhraní Wazuh RESTful API a z webového uživatelského rozhraní. Jedná se zejména o využití paměti, místa na disku, specifikace procesoru, síťová rozhraní, otevřené porty, spuštěné procesy a seznam nainstalovaných aplikací.

Sběr inventárních dat se provádí automaticky a pravidelně dle nastavení. Po dokončení sběru se porovnají nová inventární data se starými daty z předchozího skenování. Tímto způsobem identifikují například otevření nového portu, změny v procesech nebo instalace nové aplikace.

Sledování souladu s regulatorními požadavky – CIS, PCI DSS a podobně

Jsou vaše GPO v souladu s bezpečnostními doporučeními? Je vaše AD zabezpečeno souladu s specifikací CIS? Modul automatizovaného hodnocení konfigurace pomáhá udržovat standardní konfiguraci prostřednictvím sledování konfigurace sledovaných zařízení.

Modul pravidelně provádí skenování a hlásí chybné konfigurace ve sledovaném systému. Tato skenování posuzují konfiguraci systému prostřednictvím souborů zásad obsahujících sadu kontrol. Může například zkontrolovat konfiguraci souborového systému, vyhledat přítomnost aktualizace nebo bezpečnostní záplaty, zjistit, zda je povolen firewall, identifikovat nepotřebné spuštěné služby nebo ověřit zásady hesel uživatelů.

Zásady pro skenování jsou zapsány ve formátu YAML, což uživatelům umožňuje rychle jim porozumět a také rozšířit stávající zásady podle svých potřeb nebo napsat nové.

Detekce zranitelností

Wazuh může provádět pravidelnou, automatickou detekci zranitelností a pomáhá tak včas odhalit zranitelnosti v operačních systémech a v aplikacích nainstalovaných na sledovaných zařízeních.

Modul detekce zranitelností je integrovaný s externími zdroji informací o zranitelnostech společností Canonical, Debian, Red Hat, Arch Linux, Amazon Linux Advisories Security (ALAS), Microsoft a National Vulnerability Database (NVD).

Wazuh udržuje seznam aplikací nainstalovaných na sledovaných koncových zařízení a pravidelně jej porovnává s databází zranitelností (CVE). Výstupem je pak přehled zranitelností včetně dalších doplňujících informací a doporučení.

Členové security teamu tak získávají aktuální přehled o stavu zranitelností na sledovaných systémech a mohou efektivně a včas reagovat.

Aktivní ochrana

Velmi užitečnou součástí platformy Wazuh je modul aktivní ochrany. Tento modul umožnuje automatizovat reakce na události ve sledovaných systémech. Automatizace zajištuje včasné a konzistentní řešení vybraných incidentů, což může být obzvláště cenné pro menší týmy s omezenými zdroji.

Modul obsahuje řadu skriptů pro reakce, které pomáhají reagovat na hrozby a zmírňovat je. Skripty například blokují škodlivý přístup k síti nebo odstraňují škodlivé soubory na sledovaných zařízeních. Automatické akce tak snižují pracovní zátěž bezpečnostních týmů a umožňují jim efektivně zvládat incidenty.

Sledování integrity

Modul sledování integrity pravidelně sleduje systém na kterém je nainstalován a ukládá si kontrolní součty, atributy a další vlastnosti souborů a/nebo klíčů registru. Porovnáním takto získaných informací zjišťuje změny provedené na sledovaném systému a odesílá je Wazuh manageru. Kdykoli jsou ve sledovaných souborech a/nebo klíčích registru zjištěny změny, je vygenerováno upozornění.

Bezpečnost cloudu

Wazuh umožňuje sledovat také vaši infrastrukturu služby u oblíbených poskytovatelů cloudových služeb jako jsou Microsof Azure, Amazon AWS nebo Google Cloud a také v Office 365.

Prostřednictvím již dříve zmíněných komponent můžete sledovat servery provozované v cloudu a díky integracím s API poskytovatelů cloudových služeb může sledovat také činnosti spojené se správou cloudových prostředí a činnosti prováděné uživateli.

Například komponenta Azure Logs Vám umožní sledovat veškerou činnost a služby vaší infrastruktury v Microsoft Azure jako jsou activity logy, resource logy nebo logy Azure Active Directory.

Bezpečnost kontejnerů

Nedílnou součástí mnoha firemních prostředí je také platforma Docker. I tady Vám může Wazuh poskytnout potřebný přehled. Sleduje chování kontejnerů a může tak odhalit možné hrozby, zranitelnosti a anomálie.

Díky nativní integraci s Docker prostředím, umožňuje Wazuh uživatelům sledovat obrazy, svazky, síťová nastavení nebo spuštěné kontejnery.

Wazuh průběžně shromažďuje a analyzuje podrobné informace o běhu konteinerů. Upozorňuje například na kontejnery spuštěné v privilegovaném režimu, zranitelné aplikace, shell spuštěný v kontejneru, změny trvalých svazků nebo obrazů a další možné hrozby.

Vlastní dashboardy, reporting a alerting

Díky širokým možnostem nastavení přehledových panelů, reportingu a alertingu může nejen správa IT, ale i risk management a security team snadno a rychle získat přehled například o podezřelých činnostech, změnách na AD, pravidlech firewallu nebo v nastavení uživatelských práv na sledovaných systémech.

Zaujaly vás možnosti SIEM platformy Wazuh?

Více o schopnostech open-source security platformy Wazuh se dozvíte v našich webinářích:

Objevte potenciál OpenSource security platformy Wazuh

Wazuh: Instalace a konfigurace – 26. 2. 2023 od 10:00

Wazuh: Detekce hrozeb a aktivní ochrana – 24. 5. 2023 10:00

Zůstaňte naladěni😍, ať vám nic neunikne:

• LinkedIn
• X
• Instagram
• Facebook
• YouTube

The post Wazuh: užitečný pomocník (SIEM) pro bezpečnostní monitoring appeared first on initMAX s.r.o..

Veselé Vánoce přeje tým initMAXu. Děkujeme Vám za důvěru a spolupráci v roce 2022, přejeme pohodové Vánoce a mnoho úspěchů v roce novém.

The post Veselé Vánoce 2022 přeje initMAX appeared first on initMAX s.r.o..

Pro tento ročník jsme se stali hrdým gold parnerem Prague PostgreSQL Developer Day (P2D2). Velké databáze PostgreSQL provozujeme u našich servisních zákazníku jako je Česká spořitelna, Alza, Sazka nebo Kooperativa a samozřejmě i u zákazníků kde provozujeme aplikaci Zabbix. Proto rozhodování jestli jít do podpory takového eventu jako je právě P2D2 nebylo nijak těžké.

Rádi se zde s Vámi také podělíme o zákulisní informace o používání PostgreSQL tak i Zabbixu.

Podívejte se na krátké video jaké to bylo

Naše přednáška – Provozování Zabbixu s PostgreSQL jako backend DB a migrace z MySQL

V naší přednášce se věnujeme následujcím oblastem:

• Jak zmigrovat Zabbix DB z MySQL do PostgreSQL
• Instalace, výhody použítí TimescaleDB a PgBouncer pro efektivni běh Zabbixu
• Výhody a nevýhody a jak používáme PostgreSQL u našich zákazníků.
• Monitoring PostgreSQL

Soutěž o 4 volné vstupenky (ukončeno)

Jako partner eventu bychom vám rádi nabídli 4 volné vstupenky. Nebude to ale jen tak, musíte si o ně zasoutěžit.

Soutěž je jednoduchá a stačí vám následující:

• Začít nás sledovat na LinkedIn (Follow page)
• Až se v lednu objeví na našem LinkedInu informace o p2d2 tak ji přesdílet

Soutěž bude ukončena. 24.1.2023 a budou vylosováni 4 výherci, které budeme obratem kontaktovat.