Monitoring Docker w Zabbix – kompleksowy przewodnik (2026)

Monitoring Dockera w Zabbix pozwala śledzić stan kontenerów, zużycie zasobów (CPU, RAM, dysk, sieć), dostępność usług oraz kondycję samego demona Docker – wszystko w jednym, centralnym systemie monitoringu. W tym przewodniku pokażemy krok po kroku, jak skonfigurować monitoring kontenerów Docker w Zabbix przy użyciu Zabbix Agent 2, wbudowanego pluginu Docker oraz szablonu Docker by Zabbix agent 2, a także jak zbudować sensowne alerty i dashboardy.

Promocja na kursy n8n i AI dla Administratora

Naucz się automatyzować powtarzalne zadania, integrować systemy, tworzyć workflow z AI oraz budować agentów i rozwiązania RAG.

Sprawdź szczegóły:

https://asdevops.pl/1

TL;DR (szybka odpowiedź): Aby monitorować Docker w Zabbix, zainstaluj Zabbix Agent 2 na hoście z Dockerem, dodaj użytkownika zabbix do grupy docker (dostęp do /var/run/docker.sock), a następnie podepnij do hosta szablon „Docker by Zabbix agent 2”. Low-Level Discovery automatycznie wykryje wszystkie kontenery i obrazy, a Zabbix zacznie zbierać metryki bez dodatkowej konfiguracji.

Spis treści

Dlaczego warto monitorować Docker w Zabbix?
Metody monitoringu Dockera w Zabbix – porównanie
Wymagania wstępne
Krok 1: Instalacja Docker Engine
Krok 2: Instalacja Zabbix Agent 2
Krok 3: Nadanie uprawnień do docker.sock
Krok 4: Konfiguracja pluginu Docker
Krok 5: Środowisko testowe – nginx w Docker Compose
Krok 6: Dodanie hosta i szablonu w Zabbix
Najważniejsze metryki kontenerów Docker
Low-Level Discovery – automatyczne wykrywanie kontenerów
Triggery i alerty – dobre praktyki
Monitoring Zabbix Agent 2 jako kontener
Docker Swarm i Kubernetes
Rozwiązywanie problemów (troubleshooting)
Dobre praktyki produkcyjne
FAQ – najczęściej zadawane pytania

1. Dlaczego warto monitorować Docker w Zabbix?

Konteneryzacja stała się standardem wdrażania aplikacji, ale wraz z nią pojawiły się nowe wyzwania operacyjne. Kontenery są ulotne (ephemeral) – powstają i znikają dynamicznie, a klasyczny monitoring „per serwer” przestaje wystarczać. Zabbix rozwiązuje ten problem dzięki automatycznemu wykrywaniu kontenerów i zbieraniu metryk bezpośrednio z Docker API.

Najważniejsze korzyści z monitoringu Dockera w Zabbix:

Jedna platforma dla całej infrastruktury – serwery fizyczne, maszyny wirtualne, bazy danych i kontenery w jednym systemie, z jednym mechanizmem alertowania i eskalacji.
Automatyczne wykrywanie kontenerów (LLD) – nowe kontenery są dodawane do monitoringu bez ręcznej konfiguracji, a usunięte znikają zgodnie z polityką retencji.
Wczesne wykrywanie problemów – restarty w pętli (crash loop), wycieki pamięci, kontenery w stanie unhealthy, throttling CPU czy zapełniający się dysk.
Dane historyczne i planowanie pojemności – Zabbix przechowuje historię i trendy, co pozwala analizować wzorce zużycia zasobów w czasie.
Brak dodatkowych komponentów – w przeciwieństwie do stosu Prometheus + cAdvisor + Alertmanager + Grafana, Zabbix Agent 2 ma wbudowany plugin Docker i nie wymaga instalowania niczego dodatkowego na hoście.
Rozwiązanie open source klasy enterprise – bez limitów hostów, metryk czy opłat licencyjnych.

2. Metody monitoringu Dockera w Zabbix – porównanie

Zanim przejdziemy do konfiguracji, warto poznać dostępne podejścia:

Metoda	Jak działa	Zalety	Wady	Kiedy wybrać
Zabbix Agent 2 + plugin Docker (zalecana)	Natywny plugin agenta komunikuje się z Docker API przez `docker.sock`	Zero dodatkowych komponentów, gotowy szablon, LLD, niski narzut	Wymaga agenta w wersji 2	Standardowe hosty Docker, produkcja
Zabbix Agent 2 w kontenerze	Oficjalny obraz `zabbix/zabbix-agent2` z podmontowanym socketem	Spójne wdrożenie „wszystko w kontenerach”, łatwa aktualizacja	Trzeba przemyśleć uprawnienia i sieć	Środowiska w pełni skonteneryzowane, docker-compose
HTTP agent + Docker API (TCP)	Zabbix odpytuje zdalnie Docker API po TCP	Monitoring bezagentowy	Wystawienie API Dockera na sieć = ryzyko bezpieczeństwa (wymagane TLS)	Przypadki szczególne, urządzenia embedded
Prometheus scraping (cAdvisor)	Zabbix pobiera metryki z endpointu `/metrics` cAdvisora	Bardzo szczegółowe metryki per kontener (cgroups)	Dodatkowy komponent, większa złożoność	Gdy potrzebujesz metryk niedostępnych w Docker API
UserParameter + docker CLI (legacy)	Własne skrypty wywołujące `docker stats`, `docker inspect`	Pełna elastyczność	Trudne w utrzymaniu, wolne, podatne na błędy	Tylko nietypowe scenariusze

W dalszej części skupimy się na metodzie zalecanej – Zabbix Agent 2 z natywnym pluginem Docker – ponieważ oferuje najlepszy stosunek możliwości do złożoności.

3. Wymagania wstępne

Przed rozpoczęciem upewnij się, że masz:

Działający Zabbix Server w wersji 6.0 LTS lub nowszej (zalecana 7.x – szablony są bogatsze, a agent wydajniejszy),
Host z zainstalowanym Docker Engine (lub Docker Desktop w środowisku testowym),
Dostęp root/sudo do hosta z Dockerem,
Otwarty port 10050/TCP (pasywny agent) z serwera Zabbix do hosta lub 10051/TCP w drugą stronę (aktywny agent),
Podstawową znajomość interfejsu Zabbix (hosty, szablony, itemy, triggery).

Ważne: plugin Docker działa wyłącznie w Zabbix Agent 2 (napisanym w Go). Klasyczny Zabbix Agent (C) nie obsługuje kluczy docker.*.

4. Krok 1: Instalacja Docker Engine

Jeśli na hoście nie ma jeszcze Dockera, zainstaluj go zgodnie z oficjalną dokumentacją dla Debiana: https://docs.docker.com/engine/install/debian/

W skrócie (Debian 12 Bookworm):

# Dodaj oficjalne repozytorium Dockera
sudo apt update
sudo apt install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
  https://download.docker.com/linux/debian $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Zainstaluj Docker Engine wraz z pluginem Compose
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Weryfikacja
sudo docker run hello-world

5. Krok 2: Instalacja Zabbix Agent 2

Debian 12 (Bookworm) – Zabbix 7.4

# Dodaj repozytorium Zabbix 7.4
wget https://repo.zabbix.com/zabbix/7.4/release/debian/pool/main/z/zabbix-release/zabbix-release_latest_7.4+debian12_all.deb
sudo dpkg -i zabbix-release_latest_7.4+debian12_all.deb
sudo apt update

# Zainstaluj Zabbix Agent 2
sudo apt install -y zabbix-agent2

Wersję repozytorium dobierz do wersji swojego serwera Zabbix – agent nie powinien być nowszy niż serwer. Dla Zabbix 7.0 LTS użyj analogicznie paczki zabbix-release_latest_7.0+debian12_all.deb.

RHEL / Rocky / AlmaLinux

sudo rpm -Uvh https://repo.zabbix.com/zabbix/7.4/release/rocky/9/x86_64/zabbix-release-latest-7.4.el9.noarch.rpm
sudo dnf clean all
sudo dnf install -y zabbix-agent2

Podstawowa konfiguracja agenta

Otwórz plik konfiguracyjny:

sudo nano /etc/zabbix/zabbix_agent2.conf

I ustaw trzy kluczowe dyrektywy:

# Adres serwera Zabbix (checki pasywne) – agent AKCEPTUJE połączenia tylko z tego adresu
Server=192.168.1.10

# Adres serwera dla checków aktywnych
ServerActive=192.168.1.10

# Nazwa hosta – musi być IDENTYCZNA jak w konfiguracji hosta w Zabbix
Hostname=docker-host-01

Uruchom i włącz usługę:

sudo systemctl enable --now zabbix-agent2
sudo systemctl status zabbix-agent2

Uwaga: jeśli kiedykolwiek zmienisz adres serwera Zabbix (np. przeniesiesz monitoring na inną maszynę), pamiętaj o aktualizacji Server= i ServerActive= – w przeciwnym razie agent będzie odrzucał połączenia z nowego adresu, a host w GUI zaświeci się na czerwono z błędem „connection rejected”.

6. Krok 3: Nadanie uprawnień do docker.sock

Plugin Docker komunikuje się z demonem przez gniazdo UNIX /var/run/docker.sock. Domyślnie dostęp do niego mają tylko root i członkowie grupy docker. Agent działa jako użytkownik zabbix, więc:

# Dodaj użytkownika zabbix do grupy docker
sudo usermod -aG docker zabbix

# Zrestartuj agenta, aby zmiana grupy zaczęła obowiązywać
sudo systemctl restart zabbix-agent2

Weryfikacja z poziomu hosta:

# Sprawdź, czy użytkownik zabbix jest w grupie docker
groups zabbix
# zabbix : zabbix docker

# Sprawdź, czy zabbix widzi kontenery
sudo -u zabbix docker ps

# Test klucza docker.info lokalnie
zabbix_agent2 -t docker.info

Poprawny wynik docker.info zwróci JSON z informacjami o demonie Docker – wersją, storage driverem, liczbą kontenerów i obrazów (przykład):

docker.info  [s|{"ID":"14b5abb7-...","Containers":1,"ContainersRunning":1,
"ContainersStopped":0,"Images":1,"Driver":"overlayfs",
"OperatingSystem":"Debian GNU/Linux 12 (bookworm)","ServerVersion":"29.3.1",...}]

Jeśli widzisz błąd permission denied while trying to connect to the Docker daemon socket, upewnij się, że restart agenta nastąpił po dodaniu do grupy.

Uwaga bezpieczeństwa: dostęp do docker.sock jest równoważny uprawnieniom roota na hoście. Ograniczaj go wyłącznie do zaufanych procesów i nigdy nie wystawiaj Docker API po TCP bez TLS i uwierzytelniania klienta.

7. Krok 4: Konfiguracja pluginu Docker

W większości instalacji plugin działa od razu z ustawieniami domyślnymi. Jeżeli używasz niestandardowej ścieżki socketu (np. Docker rootless), utwórz dedykowany plik konfiguracyjny pluginu:

sudo nano /etc/zabbix/zabbix_agent2.d/plugins.d/docker.conf

Z zawartością (parametry można też umieścić bezpośrednio w zabbix_agent2.conf):

# Domyślna wartość – zmieniaj tylko przy nietypowej konfiguracji
Plugins.Docker.Endpoint=unix:///var/run/docker.sock

# Timeout zapytań do Docker API (sekundy)
Plugins.Docker.Timeout=10

Dla Dockera rootless ścieżka socketu wygląda zwykle tak:

Plugins.Docker.Endpoint=unix:///run/user/1000/docker.sock

Po każdej zmianie konfiguracji zrestartuj agenta:

sudo systemctl restart zabbix-agent2

8. Krok 5: Środowisko testowe – nginx w Docker Compose

Aby mieć co monitorować, uruchomimy przykładowy kontener nginx. Do zarządzania kontenerami – także w środowisku produkcyjnym – polecam Docker Compose: konfiguracja usług trafia do wersjonowalnego pliku YAML zamiast długich poleceń docker run.

Utwórz katalog projektu:

mkdir -p /opt/nginx
cd /opt/nginx

Utwórz plik definicji usługi:

nano docker-compose.yml

I wklej:

services:
  nginx:
    image: nginx:latest
    container_name: nginx
    ports:
      - "80:80"
    restart: unless-stopped

Uruchom i zweryfikuj:

docker compose up -d
docker ps

W wyniku docker ps powinieneś zobaczyć kontener nginx w stanie Up. Teraz sprawdź, czy agent wykrywa go przez discovery:

zabbix_agent2 -t docker.containers.discovery

Oczekiwany wynik – JSON z makrami LLD dla kontenera:

docker.containers.discovery  [s|[{"{#ID}":"f4cd6d526c14...","{#NAME}":"/nginx"}]]

Zwróć uwagę na dwie rzeczy: nazwa kontenera w discovery ma prefiks ukośnika (/nginx – tak zwraca ją Docker API) oraz to, że jawne container_name: nginx w Compose daje stałą, przewidywalną nazwę – bez niej Compose wygenerowałby nazwę typu nginx-nginx-1, a każda zmiana nazwy oznacza dla Zabbixa nowy obiekt LLD i utratę ciągłości historii.

9. Krok 6: Dodanie hosta i szablonu w Zabbix

Zaloguj się do frontendu Zabbix i przejdź do Data collection → Hosts → Create host.
Host name: wpisz dokładnie tę samą nazwę, którą ustawiłeś w Hostname= w konfiguracji agenta (np. docker-host-01).
Host groups: wybierz lub utwórz grupę, np. Linux servers lub Docker hosts.
Interfaces: dodaj interfejs typu Agent z adresem IP hosta i portem 10050.
Templates: podepnij szablon Docker by Zabbix agent 2.
Zapisz host.

Po kilku minutach (domyślny interwał discovery) w sekcji Latest data zobaczysz pierwsze metryki, a Low-Level Discovery utworzy itemy dla każdego kontenera i obrazu.

10 .Najważniejsze metryki kontenerów Docker

Szablon Docker by Zabbix agent 2 zbiera dziesiątki metryk. Poniżej te, które mają największą wartość operacyjną:

Metryki demona Docker (poziom hosta)

Klucz itemu	Co mierzy	Dlaczego to ważne
`docker.info`	Wersja, storage driver, liczba kontenerów/obrazów	Baza do wielu itemów zależnych (dependent items)
`docker.containers.running`	Liczba działających kontenerów	Nagły spadek = awaria usług
`docker.containers.stopped`	Liczba zatrzymanych kontenerów	Rosnąca liczba może oznaczać crash loop
`docker.containers.paused`	Kontenery wstrzymane	Zwykle powinna wynosić 0
`docker.images`	Liczba obrazów na hoście	Kontrola „śmieciowych” obrazów zjadających dysk
`docker.data_usage`	Zużycie dysku przez obrazy, kontenery, wolumeny	Zapobiega zapełnieniu `/var/lib/docker`
`docker.ping`	Dostępność Docker API	Podstawowy health check demona

Metryki per kontener (tworzone przez LLD)

Metryka	Klucz (przykład)	Próg ostrzegawczy (typowo)
Zużycie CPU	`docker.container_stats["/nginx"]` → CPU %	> 80% przez 5 min
Zużycie pamięci	pamięć used / limit	> 90% limitu
Stan kontenera	`docker.container_info["/nginx"]` → `State.Status`	inny niż `running`
Health check	`State.Health.Status`	`unhealthy`
Liczba restartów	`RestartCount`	wzrost > 3 w 10 min
Exit code	`State.ExitCode`	≠ 0 przy zatrzymaniu
Sieć RX/TX	statystyki interfejsów kontenera	anomalie względem baseline
Operacje blokowe I/O	`blkio_stats`	saturacja dysku
OOM killed	`State.OOMKilled`	`true` = przekroczony limit pamięci

Wskazówka: metryka RestartCount w połączeniu z funkcją triggera change() to najprostszy sposób wykrycia kontenera restartującego się w pętli – klasycznego objawu błędnej konfiguracji lub wycieku pamięci.

11. Low-Level Discovery – automatyczne wykrywanie kontenerów

Serce monitoringu Dockera w Zabbix to Low-Level Discovery (LLD). Reguła docker.containers.discovery zwraca listę kontenerów w formacie JSON z makrami:

{#NAME} – nazwa kontenera (np. /nginx),
{#ID} – pełny identyfikator kontenera.

Na tej podstawie Zabbix tworzy z prototypów konkretne itemy, triggery i wykresy dla każdego wykrytego kontenera.

Filtrowanie kontenerów w discovery

W środowiskach z dziesiątkami kontenerów tymczasowych (CI/CD, joby cron) warto ograniczyć discovery tylko do istotnych usług. W szablonie skonfiguruj filtr LLD:

Otwórz Data collection → Templates → Docker by Zabbix agent 2 → Discovery rules → Containers discovery.
W zakładce Filters dodaj warunek, np. {#NAME} matches ^/(nginx|postgres|redis|app-).*.
Alternatywnie użyj makra {$DOCKER.LLD.FILTER.CONTAINER.MATCHES} (w nowszych wersjach szablonu), które możesz nadpisać per host.

Parametr discovery: kontenery zatrzymane

Domyślnie discovery może wykrywać tylko działające kontenery. Klucz docker.containers.discovery[true] obejmie także zatrzymane – przydatne, gdy chcesz alertować o usługach, które powinny działać, a zostały zatrzymane.

Retencja utraconych zasobów

Ustaw sensowny czas „Delete lost resources” (np. 3–7 dni). Zbyt krótki spowoduje utratę historii przy chwilowym re-createʼcie kontenera; zbyt długi – zaśmiecenie hosta martwymi itemami.

12. Triggery i alerty – dobre praktyki

Gotowy szablon zawiera podstawowe triggery, ale produkcyjny monitoring warto dostroić:

Przykładowe wyrażenia triggerów (Zabbix 7.x)

Kontener przestał działać:

last(/Docker by Zabbix agent 2/docker.container_info["{#NAME}",State.Status])<>"running"

Kontener unhealthy (wymaga zdefiniowanego HEALTHCHECK w obrazie):

last(/Docker by Zabbix agent 2/docker.container_info["{#NAME}",State.Health.Status])="unhealthy"

Crash loop – kontener zrestartował się co najmniej 3 razy w 10 minut:

change(/Docker by Zabbix agent 2/docker.container_info["{#NAME}",RestartCount])>=3

Demon Docker nie odpowiada:

last(/Docker by Zabbix agent 2/docker.ping)=0

Wysokie zużycie pamięci przez kontener (przykład z item preprocessing / calculated item):

min(/Docker by Zabbix agent 2/docker.container_stats.memory.pct["{#NAME}"],5m)>90

Zasady, które ograniczą alert fatigue

Alertuj na symptomy, nie przyczyny – „usługa nie odpowiada” jest ważniejsze niż „CPU 85%”. Metryki zasobów ustaw jako Warning, niedostępność usług jako High/Disaster.
Używaj histerezy (recovery expression) – np. alarm przy > 90% pamięci, odwołanie dopiero przy < 80%, aby uniknąć „migotania” alertów.
Dodaj zależności triggerów – jeśli pada cały demon Docker, nie chcesz 40 osobnych alertów o kontenerach. Ustaw trigger docker.ping jako nadrzędny.
Różnicuj progi makrami – {$MEM.PCT.MAX:"postgres"} pozwala ustawić inny próg dla bazy danych niż dla aplikacji stateless.
Testuj eskalacje – alert, którego nikt nie zobaczy o 3:00 w nocy, nie istnieje. Skonfiguruj media types (e-mail, Slack, Telegram, PagerDuty) i eskalacje czasowe.

13. Monitoring z agentem uruchomionym jako kontener

W środowiskach w pełni skonteneryzowanych sam Zabbix Agent 2 możesz uruchomić z oficjalnego obrazu:

# docker-compose.yml
services:
  zabbix-agent2:
    image: zabbix/zabbix-agent2:ubuntu-7.0-latest
    container_name: zabbix-agent2
    restart: unless-stopped
    privileged: false
    environment:
      ZBX_SERVER_HOST: "192.168.1.10"
      ZBX_HOSTNAME: "docker-host-01"
    volumes:
      # Dostęp do Docker API – klucz całej integracji
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - "10050:10050"

Uruchomienie:

docker compose up -d
docker logs -f zabbix-agent2

Na co uważać:

Socket montuj w trybie read-only (:ro) – plugin potrzebuje tylko odczytu API.
Jeśli chcesz monitorować także metryki samego hosta (CPU, dysk, pamięć OS), agent w kontenerze będzie widział zasoby przez pryzmat własnych namespace’ów. Rozwiązania: tryb network_mode: host + pid: host + montowanie /proc, /sys i / (ro), albo drugi agent zainstalowany klasycznie na hoście.
Wersję obrazu przypnij do konkretnego taga zamiast latest, aby aktualizacje były świadome.

14. Docker Swarm i Kubernetes

Docker Swarm: plugin Docker działa na każdym węźle niezależnie – zainstaluj agenta na wszystkich nodach i użyj tego samego szablonu. Metryki poziomu klastra (usługi, repliki) możesz dociągnąć przez docker service ls w UserParameter lub przez Docker API (/services) z HTTP agentem.
Kubernetes: do klastrów K8s Zabbix oferuje dedykowane rozwiązanie – Zabbix Helm Chart z komponentami zabbix-proxy i zabbix-agent (DaemonSet) oraz szablony Kubernetes cluster state, Kubernetes nodes i inne, oparte o Kubernetes API i endpointy Prometheus. Nie używaj pluginu Docker do monitorowania K8s – od wersji 1.24 Kubernetes nie używa już Dockera jako runtime (containerd/CRI-O).

15. Rozwiązywanie problemów (troubleshooting)

Objaw	Najczęstsza przyczyna	Rozwiązanie
`ZBX_NOTSUPPORTED: Cannot fetch data`	Brak dostępu do `docker.sock`	`usermod -aG docker zabbix` + restart agenta
`permission denied ... docker.sock`	Restart agenta przed dodaniem do grupy	`systemctl restart zabbix-agent2`
Klucz `docker.*` „Unsupported item key”	Zainstalowany klasyczny agent zamiast Agent 2	`apt install zabbix-agent2`, usuń `zabbix-agent`
Discovery nie znajduje kontenerów	Filtr LLD odrzuca nazwy / discovery tylko running	Sprawdź filtry, użyj `docker.containers.discovery[true]`
Host „czerwony” (agent unreachable)	Firewall blokuje 10050/TCP	`ufw allow from <IP_serwera> to any port 10050`
Host „czerwony” z błędem `connection rejected`	`Server=` w konfiguracji agenta wskazuje inny adres niż faktyczny serwer (np. po zmianie serwera)	Popraw `Server=`/`ServerActive=` i zrestartuj agenta; dokładny odrzucany adres zobaczysz w `journalctl -u zabbix-agent2 -f`
Availability na szaro, Latest data puste	Serwer nigdy nie wykonał checku: proces `zabbix_server` nie działa (sam frontend nie wystarczy!), złe IP w interfejsie hosta lub host przypisany do proxy	Sprawdź Reports → System information („Zabbix server is running: Yes/No”), zweryfikuj IP interfejsu i pole „Monitored by”; test z serwera: `zabbix_get -s <IP_hosta> -k agent.ping`
Rozjazd nazwy hosta	`Hostname` w conf ≠ nazwa hosta w GUI	Ujednolić (wielkość liter ma znaczenie)
Metryki per kontener puste po re-create	Zmienił się `{#ID}` kontenera	To normalne – LLD utworzy nowe itemy; używaj stałych nazw kontenerów
Timeouty przy wielu kontenerach	Zbyt niski `Plugins.Docker.Timeout` / `Timeout`	Zwiększ do 10–30 s
Agent w kontenerze nie widzi hosta	Izolacja namespace	`pid: host`, montowanie `/proc`, `/sys` albo agent na hoście

Przydatne polecenia diagnostyczne:

# Test kluczy lokalnie na hoście
zabbix_agent2 -t docker.info
zabbix_agent2 -t 'docker.container_info["/nginx"]'

# Logi agenta
journalctl -u zabbix-agent2 -f

# Ręczny test Docker API przez socket
curl --unix-socket /var/run/docker.sock http://localhost/version

16. Dobre praktyki produkcyjne

Standaryzuj nazwy kontenerów – LLD identyfikuje kontenery po nazwie; losowe nazwy z docker-compose (projekt_app_1 vs projekt-app-1) utrudniają utrzymanie historii i triggerów.
Definiuj HEALTHCHECK w obrazach – bez niego Zabbix widzi tylko running/exited, a kontener „żywy, ale niedziałający” pozostanie niewykryty.
Ustawiaj limity pamięci (--memory) – metryka procentowego zużycia pamięci ma sens tylko względem limitu; bez limitu kontener „widzi” całą pamięć hosta.
Monitoruj /var/lib/docker osobnym itemem vfs.fs.size – zapełniony dysk z warstwami obrazów to jedna z najczęstszych awarii hostów Docker.
Łącz monitoring kontenera z monitoringiem usługi – sprawdzaj też HTTP (web.page.get, szablon Website by HTTP), porty (net.tcp.service) i logi. Kontener running ≠ aplikacja działa.
Używaj makr per host/grupa – progi CPU/RAM różnią się między środowiskami dev/staging/prod; makra pozwalają zarządzać nimi bez klonowania szablonów.
Ogranicz retencję historii dla metryk wysokiej częstotliwości – setki kontenerów × metryki co 30 s potrafią zauważalnie obciążyć bazę Zabbix. Rozważ history 7–14 dni + trendy 365 dni.
Wersjonuj konfigurację – eksportuj szablony do YAML i trzymaj w Git; zmiany progów i triggerów przechodzą wtedy code review jak każdy inny kod.

17. FAQ – najczęściej zadawane pytania

Czy Zabbix może monitorować Docker bez instalowania agenta?

Tak, przez HTTP agent odpytujący Docker API po TCP (port 2375/2376), ale wymaga to wystawienia API na sieć – koniecznie z TLS i uwierzytelnianiem certyfikatem klienta. W praktyce Zabbix Agent 2 z lokalnym socketem jest bezpieczniejszy i prostszy, dlatego metoda bezagentowa jest rzadko zalecana.

Czym różni się Zabbix Agent od Zabbix Agent 2 w kontekście Dockera?

Tylko Agent 2 (napisany w Go) ma wbudowany plugin Docker i obsługuje klucze docker.*. Klasyczny agent (C) wymagałby własnych skryptów UserParameter wywołujących docker CLI – rozwiązania wolniejszego i trudniejszego w utrzymaniu.

Czy monitoring Dockera w Zabbix obciąża hosta?

Narzut jest minimalny. Plugin odpytuje lokalne Docker API (te same dane co docker stats), a agent napisany w Go zużywa zwykle kilkanaście–kilkadziesiąt MB RAM. Przy setkach kontenerów zwiększ interwały zbierania mniej istotnych metryk.

Jak monitorować logi kontenerów w Zabbix?

Zabbix nie jest systemem agregacji logów. Możesz użyć itemu log[] dla logów zapisywanych do plików (np. przez logging driver json-file w /var/lib/docker/containers/.../*.log), ale do pełnej analizy logów lepiej sprawdzą się Loki lub Elasticsearch – a Zabbix niech alertuje na metryki i zdarzenia.

Zabbix czy Prometheus do monitoringu kontenerów?

Zabbix wygrywa, gdy potrzebujesz jednej platformy dla infrastruktury mieszanej (serwery, sieć, VM, kontenery), gotowych szablonów, alertowania z eskalacjami i długiej retencji „out of the box”. Prometheus jest naturalnym wyborem w ekosystemie Kubernetes i przy metrykach wysokokardinalnych. Oba podejścia można łączyć – Zabbix potrafi scrapować endpointy Prometheus (prometheus.get), zyskując metryki cAdvisora czy exporterów bez zmiany platformy alertowania.

Czy szablon Docker by Zabbix agent 2 działa z Podmanem?

Podman wystawia API zgodne z Dockerem. Po uruchomieniu socketu (systemctl enable --now podman.socket) i wskazaniu go w Plugins.Docker.Endpoint większość metryk działa, choć oficjalnie plugin jest testowany z Docker Engine – w produkcji przetestuj kluczowe itemy.

Co monitorować w pierwszej kolejności?

Minimalny sensowny zestaw: docker.ping (dostępność demona), stan i health check kluczowych kontenerów, RestartCount, zużycie pamięci względem limitów oraz zajętość dysku /var/lib/docker. Ten zestaw wykrywa ~90% typowych awarii środowisk kontenerowych.

Podsumowanie

Monitoring Dockera w Zabbix sprowadza się do trzech kroków: Zabbix Agent 2 → dostęp do docker.sock → szablon Docker by Zabbix agent 2. Low-Level Discovery zdejmuje z administratora ciężar ręcznej konfiguracji, a bogaty zestaw metryk – od stanu kontenerów, przez zużycie zasobów, po health checki – pozwala wykrywać awarie, zanim zauważą je użytkownicy. Dopracuj triggery (histereza, zależności, makra progów), uzupełnij monitoring o warstwę aplikacyjną i dyski, a otrzymasz kompletny, produkcyjny system nadzoru środowiska kontenerowego – bez dodatkowych komponentów i kosztów licencji.

Następne kroki: zbuduj dashboard z widgetami Top hosts i Graph dla kluczowych kontenerów, skonfiguruj powiadomienia do Slacka/Teams i przetestuj scenariusz awarii (docker stop), aby zweryfikować cały łańcuch alertowania end-to-end.