Wdrożenie Zabbix Lublin

Dlaczego ścieżka powiadamiania nie może zawierać nazwisk?

W firmie, przez którą w ciągu roku przechodzi kilkadziesiąt osób, lista adresatów zdarzeń starzeje się szybciej niż cokolwiek innego w konfiguracji. Wdrożenie odebrane w marcu z trzema nazwiskami w akcji potrafi we wrześniu wysyłać wiadomości na dwie skrzynki, których nikt już nie otwiera, i nikt tego nie zauważy, dopóki nie wydarzy się awaria.

Dlatego adresata opisujemy funkcją, a nie osobą. Zdarzenie z bazy idzie do dyspozytora na zmianie, sprawa z warsztatu do kierownika warsztatu, a rzeczy wymagające decyzji zakupowej do osoby prowadzącej firmę. Za tymi rolami stoi jedna lista kontaktów, aktualizowana w jednym miejscu, więc odejście pracownika oznacza zmianę wpisu, a nie przeglądanie kilkudziesięciu akcji.

Przy okazji ustalamy rzecz, o którą przy wdrożeniach nikt nie pyta: kto ma prawo zdarzenie zamknąć. Bez tej zasady kolejka po kilku miesiącach zamienia się w listę spraw otwartych od tygodni, przy których każdy zakłada, że zajmuje się nimi ktoś inny.

Co podłączamy w bazie poza serwerami?

Rozpoznanie zwykle kończy się listą dłuższą, niż zakładał sam klient, bo większość pilnowanych pozycji nie jest komputerem. W typowej bazie pod Lublinem mieszczą się na niej zasilacz awaryjny w szafie, przełączniki w biurze i warsztacie, punkty dostępowe na placu, sprzęt spinający budynki, rejestrator z kamer oraz komputer przy wadze, którego nikt nie liczy jako serwera, choć bez niego nie da się wypuścić pojazdu.

Do tego dochodzą rzeczy widoczne wyłącznie z zewnątrz: dostępność systemu transportowego u dostawcy, ważność certyfikatu i czas odpowiedzi usługi, do której łączą się urządzenia pokładowe. Żadna z nich nie stoi w Waszej szafie, a wszystkie potrafią zatrzymać pracę tak samo jak zgaszony serwer.

Podział na grupy robimy według roli, nie według budynku. Wydaje się to nienaturalne dopiero do chwili, w której trzeba wysłać jedną wiadomość o wszystkich urządzeniach sieciowych naraz albo nadać komuś podgląd wyłącznie na sprzęt placu.

Jak układamy obserwację, gdy zespół zmienia się w jej trakcie?

Dwa tygodnie zbierania danych bez wysyłania alertów są w każdym wdrożeniu, tylko w firmie z dużą rotacją mają dodatkowe zadanie. Poza rytmem maszyn pokazują rytm ludzi: o której realnie zaczyna się zmiana, kiedy na plac wjeżdża najwięcej pojazdów i w jakich godzinach systemem nie posługuje się nikt.

Ta wiedza decyduje potem o rzeczach, których nie da się dobrać z instrukcji. O porze nocnych zadań, o oknach na prace planowe i o tym, przy jakiej ciszy w danych warto kogokolwiek zawiadomić. Wartości ustawione bez tego etapu są poprawne technicznie i bezużyteczne w praktyce.

Zmiana składu zespołu w trakcie wdrożenia niczego nie przerywa, bo pracujemy na rolach. Wymieniamy kontakt w jednym miejscu i idziemy dalej.

Co spisujemy, zanim włączymy powiadomienia?

Jedną kartkę, którą nazywamy listą zdarzeń wolno budzących. Trafia na nią wyłącznie to, przy czym człowiek na miejscu może cokolwiek zrobić albo czego skutek rośnie z każdą godziną zwłoki. Wszystko pozostałe czeka do dnia roboczego, mimo że technicznie da się wysłać z tego wiadomość o każdej porze.

Zdarzenie	Kto jest adresatem	Co ma zrobić w pierwszej kolejności
Zanik zasilania w szafie	dyspozytor na zmianie	potwierdzić, czy prąd jest w całym budynku
Cisza w danych z pojazdów	dyspozytor na zmianie	zapisać godzinę i przekazać dalej bez logowania do systemu
Zerwane połączenie między budynkami	dyspozytor na zmianie	sprawdzić zasilanie szafy, nic poza tym
Zapełniający się dysk	kolejka do dnia roboczego	nic, sprawa ma właściciela po naszej stronie
Nieudane zadanie kopiowania	kolejka do dnia roboczego	nic, wraca w porannym przeglądzie
Kończąca się ważność certyfikatu	kolejka do dnia roboczego	nic, termin i tak jest z wyprzedzeniem

Ostatnie trzy wiersze są tam po to, żeby pierwsze trzy w ogóle ktoś przeczytał. Monitoring wysyłający wszystko o każdej porze uczy ludzi ignorowania wiadomości w dwa tygodnie, a odzyskanie tej uwagi zajmuje potem miesiące.

Osobno zapisujemy, że gwarantowana reakcja po naszej stronie biegnie od poniedziałku do piątku, między 8:00 a 18:00. Dyżur w pozostałych godzinach jest usługą osobno płatną, wycenianą po ustaleniu zakresu, i albo jest w umowie, albo nie ma go wcale. Wdrożenie, które sugeruje coś pośredniego, kończy się pretensją przy pierwszej nocnej awarii.

Które sprawdzenia piszemy sami?

Te, które dotyczą Waszych systemów, bo żaden szablon producenta ich nie zna. W firmie transportowej są to zwykle trzy rzeczy: czas ostatniego zapisu w bazie z odczytami, liczba nowych rekordów w oknie czasu oraz stan kolejki przetwarzania, jeżeli system taką prowadzi.

Każde z tych sprawdzeń wymaga rozmowy z osobą znającą aplikację, a nie tylko dostępu do bazy. Wartość graniczna dobrana bez tej rozmowy zwykle jest o rząd wielkości obok i produkuje albo ciszę, albo hałas. Zapytania uzgadniamy i zapisujemy w dokumentacji razem z uzasadnieniem, żeby po roku dało się je odczytać bez zgadywania.

Co robimy z kontami, żeby przetrwały zmianę osoby?

Konta ludzi trzymamy osobno od kont używanych przez integracje i skrypty. Każde ma wpisane przeznaczenie i właściciela w postaci roli, a uprawnienia wiążemy z grupami urządzeń, więc kierownik warsztatu widzi swoje szafy i nic poza nimi. W instalacjach, które przejmujemy, prawie zawsze znajdujemy konto o nazwie sugerującej pełne uprawnienia, którego przeznaczenia nikt już nie pamięta i przy którym nikt nie chce zaryzykować usunięcia.

Do tego dochodzi kopia konfiguracji, odtwarzalna na czystej maszynie. Odejście administratora przestaje być wtedy zdarzeniem, po którym trzeba budować monitoring od nowa, i staje się zwykłym przekazaniem obowiązków.

Co dostajecie przy odbiorze?

Działający serwer z kopią konfiguracji, komplet podłączonych urządzeń z przypisanymi szablonami, wartości graniczne ustawione po obserwacji, listę zdarzeń wolno budzących z adresatami opisanymi rolą, pulpit dla osoby technicznej i skrócony dla dyspozytorni, dokumentację oraz szkolenie dla tych, którzy będą z tego korzystać.

Wizualizację tych danych opisuje dashboard w Grafanie dla firmy z Lublina, a stały nadzór z jednym rejestrem zdarzeń i zestawieniem miesięcznym to monitoring infrastruktury IT w Lublinie. Rozpoznanie umawiamy z biura przy Kresowej 6 w Lublinie, telefon +48 888 777 822 albo formularz kontaktowy.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026