Wdrożenie i konfiguracja Zabbix

Co dostajecie na koniec wdrożenia

Wdrożenie kończy się przekazaniem konkretnych rzeczy, a nie zdaniem, że monitoring działa. Na liście odbioru jest działający serwer z bazą i kopią konfiguracji, komplet podłączonych hostów z przypisanymi szablonami, progi ustawione po okresie obserwacji, ścieżka powiadamiania z nazwiskami i telefonami, dashboard dla zespołu technicznego, skrócony widok dla osoby nietechnicznej, dokumentacja wdrożenia oraz dwie godziny szkolenia dla tych, którzy będą z tego korzystać.

Ostatnia pozycja bywa pomijana w wycenach konkurencji i jest tą, przez którą wdrożenia najczęściej się marnują. Narzędzie, którego nikt u Was nie rozumie, zamienia się w kolejny system do wyłączenia przy pierwszych porządkach.

Jak przebiega wdrożenie

Etap	Co się dzieje	Ile trwa
Rozpoznanie	spis hostów, usług i miejsc, gdzie mają iść alerty	dwa dni
Instalacja	serwer, baza, kompresja historii, kopia konfiguracji	jeden dzień
Podłączenie hostów	agenty, SNMP, sprawdzenia zewnętrzne, wykrywanie zasobów	dwa do trzech dni
Obserwacja	monitoring zbiera dane bez wysyłania alertów	dwa tygodnie
Strojenie	progi, wyzwalacze, zależności między hostami	jeden dzień
Powiadomienia	ścieżki, eskalacja, cisza nocna dla zdarzeń drobnych	pół dnia
Przekazanie	dokumentacja, dostępy, szkolenie	jeden dzień

Etap obserwacji jest jedynym, którego nie da się skrócić. Progi ustawione pierwszego dnia zawsze są zgadywaniem, a dwa tygodnie danych pokazują dobowy i tygodniowy rytm środowiska, łącznie z zadaniami, o których nikt już nie pamiętał.

Jak dobieramy architekturę

Wielkość środowiska	Układ	Na co uważać
Do 50 hostów, jedna lokalizacja	serwer i baza na jednej maszynie	wydajność dysku pod bazę
Do 200 hostów, kilka lokalizacji	serwer i proxy w oddziałach	przepustowość między proxy a serwerem
Powyżej 200 hostów	baza na osobnej maszynie, kompresja historii	rozmiar bazy i czas przechowywania danych
Środowisko z krótkimi łączami zapasowymi	proxy z lokalnym buforem	dziury w historii przy przełączeniu łącza

Najczęstszy błąd na tym etapie to niedoszacowanie dysku. Monitoring pisze do bazy bez przerwy, a decyzja o tym, ile historii trzymamy w pełnej rozdzielczości, a ile w postaci uśrednionej, wpływa na rozmiar bazy silniej niż liczba hostów. Domyślnie proponujemy miesiąc odczytów w pełnej rozdzielczości i rok danych uśrednionych: tyle wystarcza do analizy incydentu i do pokazania trendu przy planowaniu zakupów, a dłuższe trzymanie surowych wartości zwiększa bazę wielokrotnie i rzadko do czegoś służy.

W jakiej kolejności konfigurujemy Zabbiksa

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 tworzymy 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.

Skąd biorą się hosty i czy każdy potrzebuje agenta

Agent instalowany jest na serwerach i stacjach, ale spora część środowiska obchodzi się bez niego. Przełączniki, routery, zasilacze awaryjne i drukarki oddają dane przez SNMP, serwery mają interfejsy zarządzające działające nawet przy wyłączonym systemie, a usługi dostępne z internetu sprawdzamy z zewnątrz, bez niczego instalowanego po stronie klienta.

Tam, gdzie agent jest potrzebny, wybór trybu zależy od sieci, a nie od gustu. Najczęstsza usterka po podłączeniu wygląda tak samo w każdej instalacji: host widnieje jako podłączony, a danych nie ma. Odpowiada za to zwykle zapora na porcie agenta, wpis serwera niezgodny z konfiguracją agenta albo rozjechany zegar na maszynie. Czwarta możliwość to szablon przeniesiony z innego hosta, w którym sprawdzenia pasywne trafiły na agenta pracującego w trybie aktywnym.

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, także cyklicznych, na przykład na czas nocnego zadania kopii. 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. Jest jeszcze różnica w raportach: wyłączony host wypada z zestawienia dostępności, a okno serwisowe zostaje w nim odnotowane jako zaplanowana przerwa.

Uprawnienia i konta serwisowe

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.

Co zostaje u Was po zakończeniu prac

Wdrożenie nie może kończyć się tak, że jedyną osobą rozumiejącą konfigurację jest wykonawca. Dlatego przekazujemy komplet: opis architektury z adresami i wersjami, listę hostów z przypisanymi szablonami, wykaz progów wraz z uzasadnieniem, schemat powiadamiania z nazwiskami oraz procedurę na dwie najczęstsze sytuacje, czyli dodanie nowego serwera i wyciszenie monitoringu na czas prac.

Do tego dochodzi kopia konfiguracji, odtwarzalna na czystej maszynie, oraz dostęp do repozytorium ze zmianami, jeśli Wasz zespół chce śledzić, kto co zmienił. Dzięki temu zmiana dostawcy albo odejście administratora nie oznacza odtwarzania wszystkiego od zera, co jest realnym kosztem przy większości zastanych wdrożeń, które przejmujemy.

Skąd biorą się alerty, których nikt nie czyta

Z siedmiu rzeczy, powtarzalnych na tyle, że można je wypisać z pamięci. Progi z instalatora zostawione na produkcji, identyczne dla serwera bazy i dla drukarki. Brak zależności między hostami, przez co jedna awaria przełącznika wysyła czterdzieści wiadomości zamiast jednej. Alerty bez adresata, wysyłane na skrzynkę zespołową, przy której każdy zakłada, że zajmie się tym ktoś inny. 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.

Wszystkie siedem naprawia się na etapie konfiguracji, a nie po roku pracy z wyciszonym systemem. Dlatego zależności ustawiamy od razu, a każdy typ zdarzenia dostaje właściciela i regułę eskalacji na wypadek braku reakcji.

Co monitorujemy od pierwszego dnia, a co dokładamy później

Pierwsza tura obejmuje rzeczy, które wywracają pracę firmy: dostępność serwerów i maszyn wirtualnych, miejsce na dyskach, stan macierzy i zasilania awaryjnego, dostępność łącza oraz usług, z których korzystają wszyscy, czyli poczty, systemu handlowego i plików. To wystarcza, żeby monitoring zaczął się zwracać, i mieści się w pierwszym tygodniu prac.

Drugą turę dokładamy po miesiącu, gdy widać, co się faktycznie dzieje. Wtedy dochodzą liczniki baz danych, sprawdzenia biznesowe pisane pod Wasze procesy, kontrola zadań kopii zapasowych, terminy ważności certyfikatów i domen oraz pomiary z oddziałów. Rozbicie tego na dwie tury ma prosty powód: środowisko oplecione stoma sprawdzeniami w pierwszym tygodniu produkuje tyle zdarzeń, że nikt nie zdąży ich przejrzeć, a pierwsze wrażenie z narzędzia decyduje o tym, czy ktokolwiek będzie z niego korzystał.

Wdrożenie od zera czy strojenie tego, co już stoi

Da się zrobić to samodzielnie i część firm tak robi, zwłaszcza gdy mają własnego administratora z czasem na naukę. Sama instalacja jest prosta, trudność zaczyna się przy szablonach, automatycznym wykrywaniu zasobów i akcjach, czyli dokładnie tam, gdzie kończy się dokumentacja producenta, a zaczyna wiedza o konkretnym środowisku.

Dlatego rozdzielamy dwie sytuacje. Środowisko bez monitoringu dostaje pełne wdrożenie z kwotą podaną wyżej. Środowisko, w którym Zabbix już pracuje, ale generuje szum, dostaje przegląd i strojenie za około dzień pracy inżyniera: porządkujemy grupy, szablony, makra, progi i akcje, a na koniec zostaje lista poprawek z podziałem na te wykonane przez nas i te dla Waszego zespołu. Jeżeli któraś pozycja z siedmiu wypisanych wyżej brzmi znajomo, ten wariant zwykle zwraca się w pierwszym miesiącu spokojniejszych dyżurów.

Wizualizację danych z wdrożenia opisuje dashboard w Grafanie, a stały nadzór z dyżurem i raportem to monitoring infrastruktury IT.

Treść sprawdzona i zaktualizowana: 31 lipca 2026