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
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:
| Macro | Value | Description |
|---|---|---|
{$SERVICE_NAME} | nginx | Nazwa 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.
"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.