Własne szablony w Zabbiksie

To druga część serii o Zabbiksie — pierwsza, wprowadzająca, kończyła się obietnicą, że zajmiemy się m.in. własnymi szablonami. Dziś ją spełniam.

Gotowe szablony ze strony Zabbiksa albo te wbudowane (jak Linux by Zabbix agent, którego użyliśmy poprzednio) załatwiają 90% przypadków. Problem zaczyna się, gdy chcesz monitorować coś, czego autorzy oficjalnego szablonu nie przewidzieli — konkretną usługę, własny skrypt, katalog, który nie powinien przekroczyć pewnego rozmiaru. Wtedy piszesz własny template.

Z czego składa się szablon

Template w Zabbiksie to kontener, który możesz podpiąć pod dowolną liczbę hostów. Może zawierać:

  • Items — definicje metryk (co i jak często sprawdzać),
  • Triggers — warunki, które zamieniają wartość itemu w problem,
  • Discovery rules — reguły, które same znajdują, co monitorować (do tego wrócimy w ostatniej części serii),
  • Graphs i Dashboards — wizualizacje zebranych danych.

Zaletą trzymania tego w szablonie zamiast dodawania itemów ręcznie na każdym hoście jest to, że zmianę robisz raz, w jednym miejscu, a propaguje się ona na wszystkie podpięte hosty.

Przykład: pilnowanie konkretnej usługi

Zamiast monitorować ogólny stan systemu, zbudujemy coś węższego — trigger, który zaalarmuje, gdy wybrana usługa systemd przestanie działać. Klasyczny Zabbix agent nie ma gotowego klucza do sprawdzania dowolnej usługi, więc posłużymy się UserParameter — mechanizmem, który pozwala agentowi uruchamiać dowolne polecenie na hoście i zwracać jego wynik jako wartość itemu.

Krok 1: UserParameter na hoście

Na maszynie, którą chcesz monitorować, edytuj konfigurację agenta:

nano /etc/zabbix/zabbix_agentd.conf

I dodaj:

UserParameter=service.status[*],systemctl is-active $1 2>/dev/null || echo inactive

$1 to pierwszy argument przekazany w kluczu itemu — dzięki temu jeden UserParameter obsłuży dowolną usługę, zamiast pisać osobny wpis dla każdej. Zrestartuj agenta, żeby zmiana zaczęła obowiązywać:

systemctl restart zabbix-agent
ℹ️
Możesz to od razu przetestować lokalnie, bez czekania na serwer Zabbix: zabbix_agentd -t service.status[nginx] wypisze wartość, jaką zwróci agent.

Krok 2: nowy szablon

W interfejsie: Data collection → Templates → Create template. Nadaj nazwę (np. Service watchdog) i grupę szablonów (np. Custom). Zapisz.

Krok 3: Item w szablonie

Wejdź w świeżo utworzony szablon, zakładka Items → Create item:

  • Name: Status usługi {$SERVICE_NAME}
  • Type: Zabbix agent
  • Key: service.status[{$SERVICE_NAME}]
  • Type of information: Text
  • Update interval: 1m

Zamiast wpisywać nazwę konkretnej usługi na sztywno, użyłem tu makra — dzięki temu ten sam item (i cały szablon) będzie można podpiąć pod wiele różnych usług na różnych hostach.

Krok 4: makro z wartością domyślną

W zakładce Macros szablonu dodaj:

MacroValueDescription
{$SERVICE_NAME}nginxNazwa usługi systemd do pilnowania

Wartość nginx to tylko domyślna — każdy host, do którego podepniesz szablon, może ją nadpisać własną (o tym niżej).

Krok 5: Trigger

Zakładka Triggers → Create trigger:

  • Name: Usługa {$SERVICE_NAME} nie działa na {HOST.NAME}
  • Severity: High
  • Expression:
last(/Service watchdog/service.status[{$SERVICE_NAME}])<>"active"

{HOST.NAME} w nazwie triggera to kolejne makro — tym razem wbudowane, nie zdefiniowane przez nas — które Zabbix podmieni na nazwę konkretnego hosta w momencie wygenerowania problemu.

⚠️
Pamiętaj o cudzysłowach wokół "active"last() zwraca tu tekst, nie liczbę, więc porównanie musi być tekstowe.

Linkowanie szablonu do hosta

Szablon sam w sobie niczego nie monitoruje, dopóki nie podepniesz go pod hosta: Data collection → Hosts, wybierz hosta, zakładka Templates → Link new templates, wskaż Service watchdog, zapisz.

Jeśli monitorowana usługa na tym hoście różni się od wartości domyślnej, nadpisz makro na poziomie hosta: zakładka Macros hosta, opcja “Inherited and host macros”, znajdź {$SERVICE_NAME} i zmień wartość — np. na docker albo postgresql. Zero zmian w samym szablonie, a każdy host może pilnować czegoś innego.

Podsumowanie

Jeden szablon, jeden UserParameter, jedno makro — a efekt to uniwersalny “watchdog” usługi, który podłączysz pod dowolną liczbę hostów, każdy z inną usługą do pilnowania. To wzorzec, który warto zapamiętać: zamiast kopiować konfigurację, parametryzuj ją makrami.

W następnej części serii zajmiemy się monitoringiem od zupełnie innej strony — nie hostów, a stron internetowych: Web scenarios, sprawdzanie kodu odpowiedzi HTTP i czasu ładowania.

Comments powered by Talkyard.