Monitoring SSH, Docker kontajnerov a SSL certifikátov v prostredí Linux a Docker

V tomto návode si ukážeme, ako rozšíriť existujúci monitoring v Zabbixe o vlastné monitorovacie položky (Items), spúšťacie podmienky (Triggers), používateľské makrá (Macros) a automatické objavovanie služieb (Low-Level Discovery).

Zameriame sa na praktické príklady z infraštruktúry IBASTERISK, kde prevádzkujeme viacero Linux serverov, Docker aplikácií, interných webových služieb a certifikátov vydávaných internou certifikačnou autoritou FreeIPA.

1. Základné pojmy v Zabbixe

Pojem	Význam
Host	Server, sieťové zariadenie alebo monitorovaná služba
Item	Položka, ktorá získava konkrétnu monitorovanú hodnotu
Trigger	Podmienka, ktorá vyhodnocuje získané údaje a vytvára problém
Template	Šablóna obsahujúca opakovane použiteľné Items, Triggers a ďalšie nastavenia
Macro	Premenná používaná pri konfigurácii monitoringu
Discovery	Automatické objavovanie monitorovaných objektov
Trigger prototype	Vzor na automatické vytváranie triggerov pre objavené objekty
Action	Pravidlo určujúce, čo sa má vykonať pri udalosti, napríklad odoslanie e-mailu

2. Monitoring dostupnosti SSH

Ako prvý príklad vytvoríme jednoduchý monitoring dostupnosti služby SSH.

Cieľom je, aby Zabbix pravidelne kontroloval SSH na Linux serveroch a v prípade nedostupnosti vytvoril upozornenie.

2.1 Vytvorenie vlastnej šablóny

 V Zabbixe otvoríme:

Data collection → Templates → Create template

Vyplníme

Parameter	Hodnota
Template name	Template SSH Monitoring
Visible name	SSH Monitoring
Template groups	Templates

Kliknutím na Add vytvoríme šablónu.

2.2 Pridanie SSH Item

Otvoríme vytvorenú šablónu a prejdeme do sekcie Items → Create item.

Parameter	Hodnota
Name	SSH service availability
Type	Simple check
Key	net.tcp.service[ssh]
Type of information	Numeric (unsigned)
Update interval	1m
History	7d

Kľúč `net.tcp.service[ssh]` kontroluje dostupnosť SSH služby na štandardnom porte 22.

• `1` – SSH služba odpovedá.
• `0` – SSH služba neodpovedá.

Kontrolu vykonáva Zabbix server alebo proxy. Na cieľovom serveri preto tento konkrétny Item nevyžaduje Zabbix agenta.

Pri neštandardnom SSH porte môžeme použiť napríklad:

net.tcp.service[ssh,,2222]

2.3 Vytvorenie SSH Trigger

V šablóne otvoríme Triggers → Create trigger.

Následne Create trigger

Parameter	Hodnota
Name	SSH service is unavailable on {HOST.NAME}
Severity	High
OK event generation	Expression
Enabled	Yes

Do poľa Expression vložíme:

max(/Template SSH Monitoring/net.tcp.service[ssh],3m)=0

Trigger sa aktivuje vtedy, keď sú všetky dostupné hodnoty SSH kontroly za posledné tri minúty nulové. Keď Zabbix opäť zaznamená hodnotu `1`, problém sa automaticky uzavrie.

Poznámka: Výraz využíva trojminútové časové okno, ale nie je to presný časovač. Pri neúplnej histórii meraní môže byť vhodné pridať podmienku na minimálny počet vzoriek.

2.4 Priradenie šablóny serverom

Prejdeme do Data collection → Hosts → vybraný server → Templates.

V časti Link new templates vyberieme `SSH Monitoring` a uložíme zmeny.

V našej infraštruktúre sme šablónu priradili serverom:

• dns.ibasterisk.local
• freeipa.ibasterisk.local
• mail.ibasterisk.local
• mon.ibasterisk.local

Ako pridať template na ďalší server

Klikneme na server napríklad

freeipa.ibasterisk.local

Do poľa vpíšeme SSH, vyberieme ho

A následne klikneme na update

Funkčnosť overíme v **Monitoring → Latest data**. Vyhľadáme `SSH service availability`. Pri dostupnom SSH by sme mali vidieť hodnotu `1`.

Ak už na serveri existuje rovnaký Item, pred priradením šablóny treba vyriešiť duplicitu.

3. Monitoring Docker kontajnerov

Ďalším krokom je monitoring Docker prostredia pomocou Zabbix Agent 2.

Na monitorovacom serveri prevádzkujeme viacero aplikácií vrátane Grafany, Graylogu, NetBoxu, Passboltu a samotného Zabbixu.

3.1 Kontrola Zabbix Agent 2

Na Linux serveri spustíme:

zabbix_agent2 -V

V našom prípade bola použitá verzia:

zabbix_agent2 (Zabbix) 7.4.15

Docker monitoring vyžaduje dostupný Docker plugin a prístup k Docker API.

3.2 Kontrola Docker socketu

Aby mohol Zabbix Agent 2 monitorovať Docker kontajnery, musí mať oprávnenie komunikovať s Docker Engine prostredníctvom Docker socketu.

Najskôr overíme, či Docker socket existuje a aké má nastavené oprávnenia:

ls -l /var/run/docker.sock

Príklad výstupu:

srw-rw---- 1 root docker 0 Oct 11 18:14 /var/run/docker.sock

Z výstupu vidíme, že vlastníkom socketu je používateľ root a skupina docker. Prístup k socketu majú štandardne iba títo používatelia a členovia príslušnej skupiny.

Následne skontrolujeme, do ktorých skupín patrí používateľ zabbix:

id zabbix

V našom prípade bol výsledok:

uid=109(zabbix) gid=113(zabbix) groups=113(zabbix)

Z výstupu vyplýva, že používateľ zabbix nie je členom skupiny docker.

Overenie komunikácie s Dockerom

Teraz otestujeme, či Zabbix Agent 2 dokáže komunikovať s Docker Engine:

sudo -u zabbix zabbix_agent2 -t docker.ping

V našom prípade sme dostali:

docker.ping    [s|0]

Hodnota 0 znamená, že Docker nie je z pohľadu vykonaného testu dostupný. Jednou z možných príčin sú nedostatočné oprávnenia k Docker socketu.

Dočasný test s oprávneniami skupiny docker

Aby sme si overili, či problém skutočne súvisí s oprávneniami, vykonáme test so skupinou docker bez trvalej zmeny členstva používateľa:

sudo -g docker -u zabbix zabbix_agent2 -t docker.ping

Výsledok testu:

docker.ping    [s|1]

Hodnota 1 potvrdzuje, že Zabbix Agent 2 dokáže komunikovať s Docker Engine, keď má prístup k Docker socketu.

Záver kontroly

Porovnaním oboch výsledkov sme potvrdili, že príčinou nedostupnosti Docker API boli nedostatočné oprávnenia používateľa zabbix.

V nasledujúcom kroku nastavíme trvalý prístup k Docker socketu a reštartujeme Zabbix Agent 2, aby sa nové oprávnenia prejavili.

Bezpečnostné upozornenie: Členstvo v skupine docker poskytuje prakticky administrátorské oprávnenia nad hostiteľským systémom. Preto je potrebné túto zmenu vykonávať iba v dôveryhodnom prostredí a po zvážení bezpečnostných rizík.

3.3 Nastavenie oprávnení

Jednoduchou možnosťou je priradenie používateľa `zabbix` do skupiny `docker`:

sudo usermod -aG docker zabbix
sudo systemctl restart zabbix-agent2
sudo systemctl is-active zabbix-agent2
sudo -u zabbix zabbix_agent2 -t docker.ping

Očakávaná hodnota poslednej kontroly je `1`.

Bezpečnostné upozornenie. Členstvo v skupine `docker` poskytuje prakticky administrátorské oprávnenia nad hostiteľským systémom. Toto riešenie používame len tam, kde akceptujeme uvedené riziko. V prísnejšie zabezpečenom prostredí je vhodné použiť obmedzený prístup k monitorovaciemu API.

3.4 Priradenie Docker šablóny

V Zabbixe otvoríme Data collection → Hosts → mon.ibasterisk.local → Templates a pridáme oficiálnu šablónu:

`Docker by Zabbix agent 2`

Následne klikneme na update

Po jej priradení overíme položky v Monitoring → Latest data.

Zabbix dokáže získavať informácie o Docker Engine aj jednotlivých kontajneroch, napríklad stav, CPU, pamäť, sieťové štatistiky a počty reštartov.

Do Hosts zadáme meno servera

4. Automatické objavovanie Docker kontajnerov

Otvoríme Data collection → Templates a vyhľadáme šablónu Docker by Zabbix agent 2

Na jej riadku klikneme na Discovery.

Nájdeme pravidlo Containers discovery.

Oficiálna Docker šablóna obsahuje pravidlo `Containers discovery`.

V našej konfigurácii používalo kľúč:

docker.containers.discovery[false]

Interval automatického objavovania bol nastavený na `15m`.

Pomocou Low-Level Discovery Zabbix automaticky vytvára monitorovacie položky pre jednotlivé kontajnery.

4.1 Kontrola stavu kontajnera

Pre stav kontajnera využijeme Item prototype `Container {#NAME}: Running`:

docker.container_info.state.running["{#NAME}"]

Makro `{#NAME}` sa pri objavovaní automaticky nahradí názvom kontajnera. Napríklad pre Grafanu vznikne:

docker.container_info.state.running["/grafana"]

• `1` – kontajner beží.
• `0` – kontajner nebeží.

4.2 Vlastný Trigger prototype

Oficiálna šablóna už obsahuje triggery pre chybový exit kód, chybový stav a neúspešný healthcheck. V praxi sme však chceli monitorovať aj kontajner, ktorý sa zastaví korektne s exit kódom `0`.

Preto sme doplnili vlastný Trigger prototype v Data collection → Templates → Docker by Zabbix agent 2 → Discovery → Containers discovery → Trigger prototypes.

Parameter	Hodnota
Name	Docker: Container {#NAME} is not running
Severity	High
Create enabled	Yes
Discover	Yes

Expression:

max(/Docker by Zabbix agent 2/docker.container_info.state.running["{#NAME}"],3m)=0
and
count(/Docker by Zabbix agent 2/docker.container_info.state.running["{#NAME}"],3m)>=4

Výsledok

Trigger sa aktivuje pri najmenej štyroch nulových meraniach v posledných troch minútach, pričom v tomto okne nesmie byť zaznamenaná hodnota `1`.

Pri našom intervale merania približne 50 sekúnd tým obmedzujeme upozornenia na krátke reštarty.

Po vytvorení prototypu Zabbix automaticky vygeneroval **17 triggerov** pre objavené kontajnery. Medzi nimi boli:

• `/grafana`
• `/graylog`
• `/graylog-datanode`
• `/graylog-mongodb`
• `/netbox-netbox-1`
• `/passbolt`
• `/freepbx-app`
• `/zabbix-server`
• `/zabbix-web`

Dôležité: Pred zásahom do oficiálnej šablóny odporúčame exportovať jej YAML zálohu. Po aktualizácii alebo opätovnom importe šablóny treba vlastné úpravy skontrolovať.

Trigger funguje iba vtedy, keď Zabbix stále získava stav kontajnera. Pri úplnom odstránení kontajnera počas aktualizácie treba zvlášť riešiť pravidlá pre stratené objekty (*lost resources*) a kontroly neprítomnosti dát. Pre kontajnery, ktoré sa majú pravidelne zastavovať, je vhodné použiť výnimky.

5. Monitoring SSL/TLS certifikátov

Okrem dostupnosti aplikácií je dôležité sledovať aj platnosť ich SSL/TLS certifikátov.

V našej infraštruktúre používame verejné certifikáty pre internetové domény a interné certifikáty vydávané cez FreeIPA Certificate Authority.

Na monitoring používame oficiálnu šablónu `Website certificate by Zabbix agent 2`.

5.1 Manuálna kontrola certifikátu

Pred vytvorením monitoringu môžeme certifikát overiť pomocou OpenSSL:

echo | openssl s_client \
  -connect grafana.ibasterisk.local:443 \
  -servername grafana.ibasterisk.local \
  2>/dev/null | openssl x509 \
  -noout -subject -issuer -dates

Výsledok kontroly

subject=O = IBASTERISK.LOCAL, CN = grafana.ibasterisk.local
issuer=O = IBASTERISK.LOCAL, CN = Certificate Authority
notBefore=Aug  1 21:10:07 2026 GMT
notAfter=Aug  1 21:10:07 2028 GMT

Tento príkaz kontroluje obsah certifikátu, ale sám osebe ešte nepotvrdzuje dôveryhodnosť celého certifikačného reťazca.

5.2 Vytvorenie SSL monitorovacieho hosta

Prejdeme do Data collection → Hosts → Create host.

Parameter	Hodnota
Host name	ssl.grafana.ibasterisk.local
Visible name	SSL – Grafana
Host groups	web
Template	Website certificate by Zabbix agent 2
Agent interface	10.10.8.5:10050

5.3 Konfigurácia makier

Na záložke **Macros** nastavíme:

Macro	Value
{$CERT.WEBSITE.HOSTNAME}	grafana.ibasterisk.local
{$CERT.EXPIRY.WARN}	30
{$CERT.WEBSITE.PORT}	443

Dedenie makier zo šablóny

Pri konfigurácii SSL monitoringu nemusíme všetky makrá definovať priamo na monitorovanom hoste. Zabbix umožňuje dediť predvolené hodnoty z priradenej šablóny.

V našom prípade sme na hoste ssl.grafana.ibasterisk.local nastavili dve vlastné makrá:

• {$CERT.WEBSITE.HOSTNAME} – grafana.ibasterisk.local
• {$CERT.EXPIRY.WARN} – 30

Makro {$CERT.WEBSITE.PORT} s hodnotou 443 je automaticky zdedené zo šablóny Website certificate by Zabbix agent 2.

Zdedené hodnoty môžeme overiť v konfigurácii hosta na záložke Macros → Inherited and host macros, kde Zabbix zobrazuje výslednú hodnotu makra (Effective value) aj hodnotu definovanú v šablóne (Template value).

Vďaka dedeniu makier nemusíme opakovane nastavovať rovnaké hodnoty na každom monitorovanom hoste. Ak služba používa iný HTTPS port, napríklad Synology NAS na porte 5001, môžeme zdedenú hodnotu prepísať makrom priamo na danom hoste.

V zozname hostov klikneme na SSL – Grafana a otvoríme záložku Macros.

Makro `{$CERT.EXPIRY.WARN}` určuje počet dní pred expiráciou, pri ktorých Zabbix aktivuje upozornenie.

Výraz triggera pracuje so zostávajúcou platnosťou (ukážka z verejnej domény):

(last(/web.cv.ibasterisk.eu/cert.not_after[cv.ibasterisk.eu])-now())/86400 < {$CERT.EXPIRY.WARN}

Pri iných hostoch sa názov hosta a kľúč prispôsobia automaticky prostredníctvom šablóny.

5.4 Overenie certifikátu v Zabbixe

V Monitoring → Latest data sme pri Grafane získali:

Parameter	Výsledok
Expires on	1. 8. 2028
Issuer	Certificate Authority, IBASTERISK.LOCAL
Validation result	valid
Last validation status	certificate verified successfully

5.5 Klonovanie SSL hostov

Po úspešnom nastavení prvého hosta je najjednoduchšie použiť funkciu Clone. Pri klonovaní zmeníme Host name, Visible name, makro `{$CERT.WEBSITE.HOSTNAME}` a makro `{$CERT.WEBSITE.PORT}`, ak služba nepoužíva port 443.

Ostatné nastavenia šablóny a agenta môžeme ponechať.

Takto možno monitorovať Grafanu, Graylog, FreeIPA, Zabbix, NetBox a ďalšie interné HTTPS služby. Pred použitím rovnakého postupu treba overiť, že cieľový port poskytuje TLS certifikát a Agent 2 ho dokáže načítať.

6. Monitoring certifikátu Synology NAS

Rovnaký postup sme pripravili aj pre Synology NAS na IP `10.10.8.3` a doméne `nas.ibasterisk.local`.

Keďže administrácia Synology DSM využíva štandardne HTTPS port `5001`, certifikát sme overili:

echo | openssl s_client \
  -connect 10.10.8.3:5001 \
  -servername nas.ibasterisk.local \
  2>/dev/null | openssl x509 \
  -noout -subject -issuer -dates

Výsledkom bol certifikát vydaný cez internú FreeIPA CA s dátumom expirácie 1. augusta 2028.

Pre Synology vytvoríme samostatný host klonovaním Grafany:

Parameter	Hodnota
Host name	ssl.nas.ibasterisk.local
Visible name	SSL – Synology NAS
Template	Website certificate by Zabbix agent 2
Agent interface	10.10.8.5:10050

Makrá:

{$CERT.WEBSITE.HOSTNAME} = nas.ibasterisk.local

{$CERT.WEBSITE.PORT} = 5001

{$CERT.EXPIRY.WARN} = 30

Po vytvorení hosta treba overiť `Expires on` a `Validation result` v Latest data. Výsledok manuálnej kontroly OpenSSL ešte neznamená, že sa už úspešne vykonala aj kontrola zo Zabbixu.

V zozname hostov vyberieme SSL – Synology NAS.

Klikneme na Macros a Host macros

Potom vedľa na Inherited and host macros

7. E-mailové upozornenia

Samotné vytvorenie triggerov nestačí. Aby Zabbix automaticky informoval administrátora o problémoch, potrebujeme nakonfigurovať e-mailový Media type a Trigger actions.

V našej infraštruktúre používame **Alerts → Actions → Trigger actions**.

Klikneme na Report problems to Zabbix administrators

Action

Obsahuje podmienky:

Podmienky sú spojené operátorom OR, takže akcia sa vykoná pri probléme na hoste, ktorý patrí aspoň do jednej z uvedených skupín.

Následne otvoríme záložku Operations, kde skontrolujeme nastavenia odosielania e-mailových upozornení.

V záložke **Operations** je nastavené odosielanie správ cez Email skupine `Zabbix administrators`. Samostatne sú pripravené aj Recovery operations na informovanie o vyriešení problému.

7.1 Overenie odosielania

V sekcii Reports → Action log môžeme skontrolovať, či boli správy úspešne odoslané alebo došlo k chybe.

Potom zvolíme napríklad Last 7 days

Príklad odoslania mailu

Na obrázku vidíme úspešne odoslané e-mailové upozornenia so stavom Sent. Tento stav potvrdzuje, že Zabbix úspešne odovzdal správu nakonfigurovanému SMTP serveru. Neznamená však automaticky, že správa bola doručená do schránky príjemcu. Skutočné doručenie je potrebné overiť aj na poštovom serveri alebo v cieľovej e-mailovej schránke.

Je potrebné pamätať, že pri úplnom výpadku samotného Zabbix servera nemusí byť schopný odoslať upozornenie. Na takéto situácie je vhodný externý monitoring.

8. Odporúčania pre prevádzku

1. Používať šablóny. Rovnaké kontroly nastavujeme na viacerých serveroch bez zbytočného opakovania.
2. Nevytvárať duplicitné Items a Triggers. Pred vytvorením novej kontroly najskôr preveríme existujúce šablóny.
3. Využívať Low-Level Discovery. Pri Dockeri umožňuje automaticky objavovať nové kontajnery.
4. Prispôsobiť intervaly merania. Príliš krátke intervaly môžu zbytočne zaťažovať infraštruktúru; príliš dlhé môžu oneskoriť upozornenia.
5. Zálohovať vlastné úpravy šablón. Najmä pred aktualizáciami alebo opätovným importom.
6. Kontrolovať dôveryhodnosť certifikátov. Samotný dátum expirácie nie je dostatočným potvrdením platnosti SSL/TLS.
7. Testovať upozornenia. Stav Enabled a OK potvrdzuje konfiguráciu, ale úplné overenie vyžaduje aj kontrolu skutočného správania pri probléme a doručenia notifikácie.

9. Záver

Pomocou Zabbixu sme rozšírili existujúci monitoring o kontrolu SSH, automatické objavovanie Docker kontajnerov, vlastné „Docker trigger“ prototypy a sledovanie SSL/TLS certifikátov.

Výsledkom je centralizované monitorovacie prostredie, ktoré dokáže sledovať dostupnosť služieb, ich prevádzkový stav a včas upozorňovať na potenciálne problémy.

Najväčší prínos prináša kombinácia Templates, Items, Trigger prototypes, Macros a Actions, pretože umožňuje správu väčšieho množstva služieb bez nutnosti opakovať konfiguráciu na každom serveri.

Celý postup je možné rozšíriť o monitoring diskov, databáz, sieťových rozhraní, HTTP služieb a ďalších komponentov infraštruktúry.

**Testovacie prostredie:** Zabbix 8.0 vývojová vetva, Zabbix Agent 2 7.4.15, Ubuntu 24.04 ARM64, Docker, FreeIPA CA a Synology NAS.