Low-Level Discovery (LLD) w Zabbix – kompletny przewodnik od A do Z (2026)

    Daniel Nowak·
    Administracja systemamimonitoringPoradnikiZabbix

    Spis treści

    1. Czym jest Low-Level Discovery w Zabbix
    2. Po co używać LLD – problem, który rozwiązuje
    3. Jak działa mechanizm LLD – architektura krok po kroku
    4. Reguły discovery (Discovery Rules) – konfiguracja
    5. Makra LLD ({#MACRO}) – klucz do zrozumienia szablonów
    6. Prototypy elementów (Item Prototypes)
    7. Prototypy wyzwalaczy (Trigger Prototypes)
    8. Prototypy wykresów i hostów (Graph & Host Prototypes)
    9. Wbudowane metody discovery w Zabbix
    10. Discovery oparte na skryptach (Custom UserParameter / Zabbix Agent)
    11. LLD przez Zabbix API (JSON, integracje zewnętrzne)
    12. Filtry, warunki i wyrażenia regularne w LLD
    13. Overrides – reguła nadpisywania w LLD
    14. Zarządzanie cyklem życia obiektów (lifecycle management)
    15. Praktyczne przykłady zastosowania LLD
    16. LLD a Docker, Kubernetes i chmura
    17. Wydajność i dobre praktyki (best practices)
    18. Najczęstsze błędy i troubleshooting
    19. LLD vs ręczna konfiguracja – porównanie
    20. FAQ – najczęściej zadawane pytania o LLD w Zabbix
    21. Podsumowanie

    1. Czym jest Low-Level Discovery w Zabbix

    Low-Level Discovery (LLD) to mechanizm w systemie monitoringu Zabbix, który automatycznie wykrywa obiekty do monitorowania – takie jak interfejsy sieciowe, systemy plików, procesy, kontenery Docker, bazy danych czy usługi – i na tej podstawie samodzielnie tworzy elementy monitoringu (items), wyzwalacze (triggers), wykresy (graphs) oraz hosty, bez konieczności ręcznego dodawania każdego z nich osobno.


    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:
     
     
     

    Innymi słowy: zamiast administrator ręcznie definiował monitoring dla każdego dysku, karty sieciowej czy kontenera na serwerze, Zabbix sam „odkrywa”, co jest dostępne na danym urządzeniu, i tworzy dla tych obiektów odpowiednią konfigurację według wcześniej przygotowanego wzorca (prototypu).

    LLD jest jednym z filarów skalowalności Zabbix – pozwala monitorować środowiska liczące tysiące hostów i dziesiątki tysięcy elementów bez ręcznej pracy operacyjnej.

    2. Po co używać LLD – problem, który rozwiązuje

    Wyobraź sobie środowisko ze 200 serwerami, z których każdy ma inną liczbę dysków, kart sieciowych i uruchomionych kontenerów. Bez LLD administrator musiałby:

    • ręcznie dodać element monitoringu dla każdego dysku na każdym serwerze,
    • ręcznie stworzyć wyzwalacz alarmujący o zapełnieniu przestrzeni,
    • aktualizować konfigurację za każdym razem, gdy dysk zostanie dodany, odłączony lub zmieni się punkt montowania,
    • powtórzyć to dla setek hostów.

    LLD eliminuje tę pracę. Reguła discovery uruchamiana jest cyklicznie (domyślnie co godzinę), skanuje host i automatycznie:

    • dodaje monitoring dla nowo wykrytych obiektów (np. nowy dysk),
    • usuwa lub oznacza jako nieaktywne elementy dla obiektów, które zniknęły (np. odłączony dysk),
    • utrzymuje spójność konfiguracji bez interwencji człowieka.

    To sprawia, że LLD jest niezbędny w dynamicznych środowiskach: chmurze, kontenerach, autoskalujących się klastrach czy infrastrukturze, która często się zmienia.

    3. Jak działa mechanizm LLD – architektura krok po kroku

    Proces Low-Level Discovery w Zabbix przebiega w pięciu etapach:

    1. Uruchomienie reguły discovery (Discovery Rule) – Zabbix wysyła zapytanie discovery (np. vfs.fs.discovery, net.if.discovery, zapytanie SNMP lub skrypt) do agenta, proxy lub urządzenia.
    2. Zwrot danych w formacie JSON – host zwraca listę wykrytych obiektów wraz z makrami LLD, np. nazwami dysków, interfejsów czy identyfikatorami kontenerów.
    3. Przetworzenie danych przez Zabbix Server – serwer analizuje otrzymany JSON i porównuje go z filtrami/warunkami zdefiniowanymi w regule.
    4. Generowanie obiektów na podstawie prototypów – dla każdego wykrytego obiektu spełniającego filtry Zabbix tworzy konkretny element, wyzwalacz, wykres lub host na bazie zdefiniowanego prototypu, podstawiając wartości makr LLD.
    5. Zarządzanie cyklem życia – przy kolejnych uruchomieniach reguły Zabbix aktualizuje, dezaktywuje lub usuwa obiekty w zależności od tego, czy dany obiekt nadal istnieje.

    Ten cykl powtarza się automatycznie zgodnie z interwałem zdefiniowanym w regule discovery (parametr „Update interval”).

    4. Reguły discovery (Discovery Rules) – konfiguracja

    Reguła discovery to serce mechanizmu LLD. Definiuje się ją na poziomie hosta lub szablonu (template), w sekcji Data collection → Hosts/Templates → Discovery.

    Kluczowe parametry reguły discovery:

    • Name – nazwa reguły, np. „Filesystem discovery”.
    • Key – klucz elementu discovery, np. vfs.fs.discovery, net.if.discovery, docker.containers.discovery (custom).
    • Type – typ zbierania danych: Zabbix agent, Zabbix agent (active), SNMP agent, Script, HTTP agent, IPMI, JMX.
    • Update interval – jak często reguła jest ponownie uruchamiana (domyślnie 1h).
    • Keep lost resources period – jak długo przechowywać dane po zniknięciu wykrytego obiektu, zanim zostanie on trwale usunięty.
    • Filters – warunki decydujące, które wykryte obiekty faktycznie mają zostać przetworzone.

    Reguła sama w sobie nic nie monitoruje – jest jedynie punktem wejścia. Prawdziwa logika monitoringu znajduje się w prototypach powiązanych z regułą.

    5. Makra LLD ({#MACRO}) – klucz do zrozumienia szablonów

    Makra LLD (zapisywane w formacie {#NAZWA}) to zmienne, które Zabbix podstawia dynamicznie na podstawie danych zwróconych przez discovery. To one pozwalają jednym prototypem obsłużyć nieograniczoną liczbę różnych obiektów.

    Przykład typowej odpowiedzi JSON dla discovery systemów plików:

    {
    "data": [
        { "{#FSNAME}": "/", "{#FSTYPE}": "ext4" },
        { "{#FSNAME}": "/var", "{#FSTYPE}": "xfs" },
        { "{#FSNAME}": "/home", "{#FSTYPE}": "ext4" }
    ]
}

    Na tej podstawie prototyp elementu z kluczem vfs.fs.size[{#FSNAME},pfree] zostanie zamieniony na trzy realne elementy:

    • vfs.fs.size[/,pfree]
    • vfs.fs.size[/var,pfree]
    • vfs.fs.size[/home,pfree]

    Makra LLD mogą też być łączone i przetwarzane za pomocą wyrażeń regularnych, funkcji JavaScript w preprocessingu oraz wykorzystywane w nazwach elementów, opisach, tagach czy poziomach ważności wyzwalaczy.

    6. Prototypy elementów (Item Prototypes)

    Item Prototype to szablon elementu monitoringu zawierający makra LLD zamiast konkretnych wartości. To on decyduje, co dokładnie będzie mierzone dla każdego wykrytego obiektu.

    Przykład: prototyp elementu monitorującego wolne miejsce na dysku:

    • Name: Free space on {#FSNAME}
    • Key: vfs.fs.size[{#FSNAME},pfree]
    • Type: Zabbix agent
    • Update interval: 1m
    • Units: %

    Dla każdego wykrytego systemu plików Zabbix utworzy osobny, realny element na podstawie tego prototypu.

    7. Prototypy wyzwalaczy (Trigger Prototypes)

    Trigger Prototype definiuje logikę alarmowania dla każdego wykrytego obiektu. Przykład wyzwalacza ostrzegającego o niskiej ilości wolnego miejsca:

    • Name: Low disk space on {#FSNAME}
    • Expression: last(/Host/vfs.fs.size[{#FSNAME},pfree])<10
    • Severity: Warning

    Dzięki temu każdy nowo wykryty dysk automatycznie otrzymuje własny, niezależny alarm – bez potrzeby ręcznego kopiowania wyzwalacza.

    8. Prototypy wykresów i hostów (Graph & Host Prototypes)

    • Graph Prototype – automatycznie generuje wykres dla każdego wykrytego obiektu (np. osobny wykres obciążenia dla każdego interfejsu sieciowego).
    • Host Prototype – najbardziej zaawansowana funkcja LLD, używana głównie przy discovery VMware, sieci czy urządzeń w topologii. Pozwala automatycznie tworzyć całe nowe hosty (np. każda wykryta maszyna wirtualna w klastrze VMware staje się osobnym hostem w Zabbix z własnym zestawem elementów, dziedziczonym z szablonu).

    9. Wbudowane metody discovery w Zabbix

    Zabbix posiada gotowe, wbudowane klucze discovery, które nie wymagają dodatkowej konfiguracji po stronie agenta:

    Klucz discoveryCo wykrywa
    net.if.discoveryinterfejsy sieciowe
    vfs.fs.discoverysystemy plików / dyski
    system.cpu.discoveryrdzenie/procesory CPU
    net.udp.socket.count / dyskonery siecioweporty, gniazda
    SNMP discovery (walk)urządzenia sieciowe, interfejsy switchy, drukarki
    Zabbix agent 2 – plugin discovery (Docker, MySQL, Redis, Memcached)kontenery, bazy danych, procesy
    VMware discoveryhosty ESXi, maszyny wirtualne, datastore

    Większość oficjalnych szablonów Zabbix (dostępnych w Zabbix Git/Marketplace) ma te reguły już skonfigurowane – wystarczy podpiąć szablon do hosta.

    10. Discovery oparte na skryptach (Custom UserParameter / Zabbix Agent)

    Gdy wbudowane metody nie wystarczają, można stworzyć własną regułę discovery za pomocą skryptu, który zwraca poprawny JSON w formacie oczekiwanym przez Zabbix.

    Przykład prostego skryptu bash zwracającego listę kontenerów Docker:

    #!/bin/bash
echo '{"data":['
docker ps --format '{"{#CONTAINER_NAME}":"%n","{#CONTAINER_ID}":"%i"}' | paste -sd,
echo ']}'

    Taki skrypt podpinany jest jako UserParameter w pliku konfiguracyjnym agenta:

    UserParameter=docker.containers.discovery,/etc/zabbix/scripts/docker_discovery.sh

    Następnie w Zabbix tworzy się regułę discovery typu Zabbix agent z kluczem docker.containers.discovery, a do niej podpina prototypy elementów monitorujące np. zużycie CPU/RAM każdego kontenera.

    11. LLD przez Zabbix API (JSON, integracje zewnętrzne)

    Reguły discovery, prototypy elementów, wyzwalaczy i hostów można w pełni zarządzać programistycznie przez Zabbix API (metody discoveryrule.create, itemprototype.create, triggerprototype.create, hostprototype.create). Jest to szczególnie przydatne przy:

    • integracji z systemami CMDB,
    • automatycznym wdrażaniu monitoringu z pipeline’ów CI/CD,
    • masowej migracji konfiguracji między instancjami Zabbix,
    • generowaniu discovery na podstawie zewnętrznych źródeł danych (np. inwentarza chmurowego AWS/Azure).

    Dzięki temu LLD można traktować jako Infrastructure as Code – konfiguracja monitoringu powstaje automatycznie wraz z provisioningiem infrastruktury.

    12. Filtry, warunki i wyrażenia regularne w LLD

    Nie każdy wykryty obiekt musi być monitorowany. Filtry w regule discovery pozwalają zawęzić zakres, np.:

    • monitoruj tylko systemy plików, których {#FSTYPE} pasuje do wyrażenia regularnego ext4|xfs (pomijając tmpfs, proc, overlay),
    • monitoruj tylko interfejsy sieciowe, których nazwa nie zaczyna się od lo czy veth,
    • monitoruj tylko kontenery z etykietą (label) env=production.

    Filtry można łączyć logiką AND/OR, co daje dużą elastyczność przy wykluczaniu „szumu” (np. dysków wirtualnych, interfejsów pętli zwrotnej, tymczasowych kontenerów).

    13. Overrides – reguła nadpisywania w LLD

    Overrides to mechanizm pozwalający zmieniać zachowanie prototypów w zależności od warunku, bez tworzenia osobnej reguły discovery. Przykład zastosowania:

    • domyślnie wszystkie wykryte dyski mają próg alarmowy 10% wolnego miejsca,
    • ale dla dysków, których nazwa zawiera backup, próg ma być obniżony do 5%, a interwał sprawdzania wydłużony do 1h zamiast 1m.

    Overrides pozwalają też np. wyłączyć tworzenie wyzwalacza dla konkretnej grupy wykrytych obiektów, zmienić priorytet (severity), dodać tagi albo skierować dany obiekt do innej grupy hostów – wszystko warunkowo, na podstawie wartości makr LLD.

    14. Zarządzanie cyklem życia obiektów (lifecycle management)

    Jedną z najważniejszych, a często pomijanych funkcji LLD jest automatyczne zarządzanie cyklem życia wykrytych obiektów:

    • Item/trigger/graph discovered – nowy obiekt jest tworzony automatycznie.
    • Obiekt zniknął z wyników discovery (np. dysk odłączony) – Zabbix, w zależności od konfiguracji „Keep lost resources period”, może:
      • oznaczyć element jako nieaktywny (disabled),
      • usunąć element po określonym czasie,
      • pozostawić historyczne dane bez zmian.
    • Host prototype disabled/enabled – analogicznie dla całych hostów tworzonych automatycznie (np. maszyn wirtualnych).

    Dobrze skonfigurowany „Keep lost resources period” (np. 7–30 dni) zapobiega utracie danych historycznych przy chwilowym zniknięciu zasobu (np. restart kontenera), a jednocześnie utrzymuje konfigurację w porządku.

    15. Praktyczne przykłady zastosowania LLD

    1. Monitoring dysków (Filesystem Discovery) Automatyczne wykrywanie punktów montowania i tworzenie alarmów o zapełnieniu przestrzeni na każdym z nich, niezależnie od tego, ile dysków ma dany serwer.

    2. Monitoring interfejsów sieciowych Wykrywanie wszystkich aktywnych interfejsów na przełącznikach (SNMP) i automatyczne tworzenie wykresów ruchu in/out dla każdego portu.

    3. Monitoring baz danych (np. MySQL/PostgreSQL) Discovery automatycznie wykrywa wszystkie bazy danych na instancji i tworzy dla każdej osobne elementy monitorujące rozmiar, liczbę połączeń czy replikację.

    4. Monitoring procesów aplikacyjnych Wykrywanie uruchomionych procesów pasujących do wzorca (np. worker-*) i tworzenie alarmów, gdy liczba instancji spadnie poniżej oczekiwanej.

    5. Monitoring maszyn wirtualnych VMware Host prototypes automatycznie tworzą nowy host w Zabbix dla każdej maszyny wirtualnej wykrytej w klastrze vCenter.

    16. LLD a Docker, Kubernetes i chmura

    W środowiskach kontenerowych i chmurowych zasoby powstają i znikają w sposób ciągły – to właśnie tam LLD daje największą wartość:

    • Docker – Zabbix agent 2 posiada natywny plugin discovery dla kontenerów, wykrywający uruchomione kontenery i automatycznie monitorujący ich zużycie CPU, pamięci i sieci.
    • Kubernetes – integracja zazwyczaj odbywa się przez Zabbix API + zewnętrzny skrypt/operator, który synchronizuje listę podów/node’ów z regułami discovery, lub przez dedykowane szablony community.
    • Chmura (AWS/Azure/GCP) – discovery można łączyć z API dostawcy chmury (np. przez Zabbix API + skrypt pobierający listę instancji EC2), automatycznie dodając nowe maszyny do monitoringu zaraz po ich uruchomieniu (autoskalowanie).

    To sprawia, że LLD jest praktycznie niezbędny w podejściu cloud-native i infrastrukturze efemerycznej, gdzie ręczna konfiguracja monitoringu byłaby niemożliwa do utrzymania.

    17. Wydajność i dobre praktyki (best practices)

    • Nie ustawiaj zbyt krótkiego interwału discovery (np. co minutę) dla dużej liczby hostów – generuje to niepotrzebne obciążenie Zabbix Server/Proxy. Standardowo 1h jest wystarczające.
    • Zawsze używaj filtrów, aby nie monitorować zbędnych obiektów (np. tmpfs, interfejsów pętli zwrotnej) – każdy zbędny element to dodatkowe obciążenie bazy danych.
    • Ustaw rozsądny „Keep lost resources period”, aby nie tracić historii przy chwilowych zanikach zasobu, ale też nie zaśmiecać konfiguracji martwymi elementami.
    • Grupuj powiązane reguły w szablonach, żeby łatwo podpinać cały zestaw discovery (dyski + sieć + procesy) jednym kliknięciem do nowego hosta.
    • Testuj dane wyjściowe discovery poleceniem zabbix_get lub w sekcji „Test” w konfiguracji reguły przed wdrożeniem na produkcję.
    • Unikaj zagnieżdżonego LLD o wysokiej częstotliwości na Zabbix Proxy przy słabszym sprzęcie – proxy powinien mieć odpowiednie zasoby CPU/RAM przy dużej liczbie wykrywanych obiektów.

    18. Najczęstsze błędy i troubleshooting

    ProblemPrawdopodobna przyczynaRozwiązanie
    Discovery nie tworzy żadnych elementówBłędny format JSON zwracany przez skrypt/agentaZweryfikuj JSON np. przez zabbix_get -s <host> -k <klucz>
    Elementy nie znikają mimo braku zasobuZbyt długi „Keep lost resources period”Skróć okres lub ręcznie usuń nieaktywne elementy
    Zbyt dużo niepotrzebnych elementówBrak filtrów w regule discoveryDodaj warunki filtrujące na makrach LLD
    Wysokie obciążenie Zabbix ServerZbyt częste interwały discovery na wielu hostachWydłuż interwał, rozważ Zabbix Proxy
    Prototyp nie generuje wyzwalaczaBłąd w wyrażeniu wyzwalacza odwołującym się do makra LLDSprawdź poprawność składni {#MACRO} w Expression
    Host prototype nie tworzy nowego hostaBrak uprawnień lub błędna grupa hostów w konfiguracji prototypuZweryfikuj uprawnienia API/użytkownika i przypisaną grupę

    19. LLD vs ręczna konfiguracja – porównanie

    KryteriumRęczna konfiguracjaLow-Level Discovery
    Czas wdrożenia dla wielu obiektówWysoki (liniowo rośnie z liczbą obiektów)Niski (jeden szablon obsługuje dowolną liczbę)
    Reakcja na zmiany infrastrukturyWymaga ręcznej aktualizacjiAutomatyczna
    Ryzyko błędu ludzkiegoWyższeNiższe
    SkalowalnośćOgraniczonaBardzo wysoka
    Elastyczność w edge-case’achPełna kontrolaWymaga filtrów/overrides dla wyjątków
    Zalecane środowiskoStatyczne, niewielkieDynamiczne, chmurowe, kontenerowe, duże

    20. FAQ – najczęściej zadawane pytania o LLD w Zabbix

    Czym różni się Low-Level Discovery od zwykłego monitoringu w Zabbix?

    Zwykły monitoring wymaga ręcznego zdefiniowania każdego elementu (item) na stałe. LLD automatycznie tworzy elementy na podstawie prototypów i danych wykrytych na hoście, dostosowując się do zmian w infrastrukturze bez interwencji administratora.

    Jak często Zabbix uruchamia reguły discovery?

    Domyślnie co godzinę, ale interwał można dowolnie skonfigurować w parametrze „Update interval” reguły discovery – od kilku minut po wiele godzin, w zależności od dynamiki środowiska.

    Czy LLD można stworzyć samodzielnie dla własnej aplikacji?

    Tak. Wystarczy napisać skrypt lub UserParameter, który zwróci poprawnie sformatowany JSON zgodny ze specyfikacją Zabbix LLD (klucz data z listą obiektów zawierających makra {#MACRO}), a następnie podpiąć go jako regułę discovery typu Script lub Zabbix agent.

    Co się dzieje, gdy wykryty wcześniej obiekt zniknie (np. dysk zostanie odłączony)?

    Zabbix, zgodnie z ustawieniem „Keep lost resources period”, może oznaczyć powiązany element jako nieaktywny lub usunąć go po zdefiniowanym czasie, zachowując dane historyczne przez ten okres.

    Czy Host Prototypes tworzą realne, w pełni funkcjonalne hosty?

    Tak – Host Prototype tworzy pełnoprawny host w Zabbix, dziedziczący szablony, grupy i makra zgodnie z konfiguracją prototypu, tak jakby został dodany ręcznie.

    Czy LLD nadaje się do monitorowania Kubernetes?

    Tak, choć zwykle wymaga to dodatkowej integracji – np. przez Zabbix API i skrypt synchronizujący stan klastra, ponieważ natywne wsparcie discovery dla K8s jest mniej rozbudowane niż dla Dockera.

    Czy zbyt wiele reguł LLD może spowolnić Zabbix Server?

    Tak, przy nieodpowiedniej konfiguracji (zbyt krótkie interwały, brak filtrów, tysiące hostów) discovery może znacząco obciążyć bazę danych i serwer. Kluczowe jest stosowanie filtrów i rozsądnych interwałów.

    Czym są overrides i kiedy warto ich używać?

    Overrides pozwalają warunkowo modyfikować zachowanie prototypów (np. inny próg alarmowy, wyłączony wyzwalacz, inna grupa hostów) dla podzbioru wykrytych obiektów, bez tworzenia osobnej reguły discovery – przydatne przy wyjątkach od reguły ogólnej.

    21. Podsumowanie

    Low-Level Discovery to jeden z najważniejszych mechanizmów Zabbix, który zamienia monitoring z żmudnej, ręcznej pracy w automatyczny, samoutrzymujący się proces. Dzięki regułom discovery, prototypom elementów, wyzwalaczy, wykresów i hostów, a także mechanizmom filtrowania, overrides i zarządzania cyklem życia, Zabbix potrafi dostosować się do dynamicznie zmieniającej się infrastruktury – od pojedynczego serwera z dyskami, przez sieci SNMP, po środowiska kontenerowe i chmurowe.

    Dobrze skonfigurowany LLD to nie tylko oszczędność czasu administratora, ale przede wszystkim gwarancja spójności i kompletności monitoringu w środowiskach, w których ręczne nadążanie za zmianami byłoby praktycznie niemożliwe.

     

    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:
     
     
     

    Promocja na kursy n8n i AI dla Administratora

    Dołącz!
    X