Zabbix, konfiguracja krok po kroku

W jakiej kolejności to konfigurować

Kolejność wygląda tak: grupy hostów, szablony, hosty, automatyczne wykrywanie zasobów, makra, wyzwalacze, akcje, pulpity. Każdy krok korzysta z poprzedniego i pominięcie któregokolwiek mści się przy kolejnych trzydziestu maszynach.

Grupy tworzy się według roli, nie według miejsca: serwery baz danych, kontrolery domeny, przełączniki dostępowe, hosty wirtualizacji. Od grup zależą później uprawnienia, przypisanie akcji i zawartość pulpitów, więc podział na oddziały wydaje się naturalny dokładnie do momentu, w którym trzeba wysłać alert wszystkim administratorom baz danych.

Szablony, czyli miejsce, gdzie oszczędza się najwięcej czasu

Zasada jest jedna: nic nie definiujemy bezpośrednio na hoście. Wszystko idzie do szablonu, host tylko go dziedziczy. Dzięki temu zmiana progu w jednym miejscu obejmuje wszystkie maszyny tej klasy, a nowy serwer podłącza się w minutę.

Szablony producenta są dobrym punktem wyjścia i złym punktem docelowym. Standardowy szablon dla systemu operacyjnego zbiera kilkadziesiąt pozycji, z których połowa nigdy nikomu do niczego nie posłuży, za to obciąża bazę. Praktyka, która się sprawdza: wziąć szablon producenta, wyłączyć zbędne pozycje, dołożyć własne sprawdzenia usług i zapisać jako szablon firmowy dla tej klasy maszyn.

Wykrywanie zasobów i makra

Dyski, systemy plików, interfejsy sieciowe i procesory wykrywa się automatycznie, przez reguły niskiego poziomu. Ręczne dopisywanie pozycji przy każdej zmianie konfiguracji maszyny jest pracą, która sama znika po ustawieniu jednej reguły. Trzeba tylko dołożyć filtry odrzucające zasoby tymczasowe, inaczej monitoring zacznie pilnować systemów plików kontenerów i punktów montowania, które żyją po dziesięć minut.

Progi trzymamy w makrach, nie w treści wyzwalacza. Makro definiuje się raz na poziomie szablonu, a na pojedynczym hoście nadpisuje wtedy, gdy ta maszyna faktycznie rządzi się swoimi prawami. Serwer, którego dysk zawsze jest zajęty w dziewięćdziesięciu procentach, bo tak działa aplikacja, dostaje własną wartość zamiast stałego wyciszenia.

Jak pisać wyzwalacze, żeby nie budziły bez powodu

Zamiast tego	Zrób to	Dlaczego
Reakcja na ostatni odczyt	średnia z kilku minut	pojedynczy skok obciążenia nie jest awarią
Jeden próg dla wszystkich	próg z makra, nadpisywany na hoście	maszyny mają różne profile pracy
Alert przy zajętości dysku	alert przy prognozie wyczerpania miejsca	procent nie mówi nic o tempie przyrostu
Osobne alerty z każdej maszyny	zależności od przełącznika i hosta wirtualizacji	jedna awaria ma dawać jedno zdarzenie
Krytyczny dla wszystkiego	podział wag na budzące i czekające do rana	wszystko krytyczne znaczy nic krytycznego
Brak reakcji na ciszę	osobne sprawdzenie braku danych	martwy agent wygląda jak brak problemów

Ostatni wiersz jest tym, o którym zapomina się najczęściej. Host, z którego przestały spływać dane, nie generuje żadnego przekroczenia progu, więc na pulpicie wygląda spokojnie. Bez osobnego sprawdzenia braku danych maszyna może tak stać tygodniami.

Akcje, eskalacja i okna serwisowe

Akcja odpowiada na pytanie, co się dzieje po powstaniu zdarzenia. Minimalny sensowny zestaw to trzy kroki: powiadomienie właściciela grupy, po piętnastu minutach powtórka i powiadomienie drugiej osoby, po godzinie powiadomienie przełożonego. Do tego automatyczne zamknięcie zdarzenia po ustąpieniu przyczyny, żeby nikt nie zamykał ręcznie stu wpisów po nocnej awarii łącza.

Prace planowane zamykamy w oknach serwisowych zakładanych na grupę hostów. Wyłączanie hostów na czas prac działa równie dobrze, dopóki ktoś nie zapomni ich włączyć, co zdarza się mniej więcej zawsze.

Uprawnienia i porządek przy większej liczbie osób

Przy dwóch administratorach wystarczy jedno konto z pełnymi prawami. Przy kilkunastu osobach, z których część ma tylko patrzeć, zaczyna się potrzeba podziału. Grupy użytkowników wiąże się z grupami hostów, więc dobrze przygotowany podział z pierwszego kroku zwraca się właśnie tutaj: dział handlowy widzi dostępność systemu handlowego i nic poza tym, a dostęp do konfiguracji ma wyłącznie zespół, który za nią odpowiada.

Osobna sprawa to konta serwisowe używane przez integracje i przez skrypty sięgające po dane przez interfejs programistyczny. Trzymamy je oddzielnie od kont ludzi, z ograniczonymi prawami i opisem, do czego służą, bo konto o nazwie admin2 z pełnymi uprawnieniami znajduje się w każdej instalacji, którą przejmujemy, i nikt nigdy nie wie, co się stanie po jego usunięciu.

Siedem rzeczy, które psują wdrożenie

Progi z instalatora zostawione na produkcji. Brak zależności między hostami, przez co jedna awaria wysyła czterdzieści wiadomości. Alerty wysyłane na skrzynkę zespołową bez wskazanego właściciela. Historia trzymana w pełnej rozdzielczości przez rok, przez co baza rośnie do rozmiarów, których dysk nie udźwignie. Sprawdzenia uruchamiające ciężkie zapytania co minutę. Brak sprawdzenia braku danych. I ostatnia: konfiguracja robiona bezpośrednio na hostach, bez szablonów, która przy pięćdziesiątej maszynie staje się nie do utrzymania.

Jeżeli któraś z tych rzeczy brzmi znajomo, przegląd instalacji zwykle zwraca się w pierwszym miesiącu spokojniejszych dyżurów. Pełne wdrożenie od zera opisuje wdrożenie Zabbix, wizualizację danych dashboard w Grafanie, a nadzór z dyżurem całodobowym monitoring IT.

Treść sprawdzona i zaktualizowana: 30 lipca 2026