Wdrożenie Zabbix Toruń

Dlaczego termin wdrożenia dobieramy pod kalendarz przyjęć?

Bo monitoring strojony jest na danych, a zakład przetwórczy dostarcza ich dwa zupełnie różne komplety. Przez większość roku obciążenie ma powtarzalny rytm dobowy, ruch w komorach jest umiarkowany, a dokumentacja przyrasta powoli. W czasie przyjęcia surowca zmienia się jedno i drugie, a razem z nimi to, co w ogóle należy uznać za wartość nietypową.

Wdrożenie zaczęte kilka tygodni przed sezonem daje układ najwygodniejszy: obserwacja obejmuje spokojny rytm, strojenie kończy się przed startem, a pierwsze tygodnie kampanii służą do sprawdzenia, czy komplet sezonowy trzyma. Wdrożenie zaczęte w szczycie też się udaje, tylko trzeba wtedy zaplanować drugie strojenie po zakończeniu przyjęć, inaczej zakład wchodzi w zimę z progami, które przepuszczą praktycznie wszystko.

Jest jeszcze trzecia droga, po którą sięgamy najczęściej przy firmach niemających wyraźnego sezonu: obserwacja przez dwa tygodnie, uruchomienie zdarzeń i przegląd po miesiącu, gdy widać już, które sprawdzenia niosą informację, a które szum.

Co podłączamy poza serwerami?

Pozycja	Jak podłączamy	Co z tego mamy	Na co uważamy
Rejestrator temperatury w komorze	odczyt sieciowy albo plik raportu	wyjście poza zakres i brak danych	rejestrator bywa zamknięty przez producenta
Czujnik w pomieszczeniu z szafą	własny czujnik przez SNMP	temperatura i wilgotność	montaż w miejscu, gdzie mierzy powietrze, nie ścianę
Waga przy linii	sprawdzenie z sieci, bez agenta	zatrzymanie wymiany danych	zakaz instalacji z umowy serwisowej
Etykieciarka	dostępność usługi i kolejka wydruku	przerwa w wydruku partii	urządzenie odpowiada, choć nie drukuje
Zasilacz awaryjny	karta zarządzająca przez SNMP	praca na bateriach i czas podtrzymania	karta bywa w osobnej podsieci
Przełącznik w hali	SNMP i wybrany syslog	stan portów, zasilanie portów, temperatura	trzeba włączyć protokół, często wyłączony
Serwer z bazą	agent Zabbiksa	zasoby, usługi, zadania cykliczne	ciężkie zapytania planujemy rzadziej

Czwarty wiersz jest przykładem, dla którego w ogóle piszemy własne sprawdzenia. Etykieciarka potrafi odpowiadać na każde pytanie o dostępność i jednocześnie nie wypuszczać ani jednej etykiety, bo zatrzymała się kolejka. Sprawdzenie oparte wyłącznie na dostępności urządzenia pokaże wtedy spokój, a linia stoi.

Które sprawdzenia piszemy sami, bo żaden szablon ich nie zna?

Szablony producentów pokrywają systemy operacyjne, przełączniki i zasilanie, czyli warstwę, która w każdej firmie wygląda tak samo. Kończą się dokładnie tam, gdzie zaczyna się to, na czym zakładowi zależy najbardziej: czy dane z linii docierają tam, gdzie mają docierać.

Najczęściej piszemy trzy rodzaje sprawdzeń. Pierwszy to świeżość danych: zapytanie sprawdzające, czy w bazie jest wpis nowszy niż kilkanaście minut, bo brak nowych odczytów wygląda w metrykach systemowych identycznie jak spokój. Drugi to plik wymiany: obecność, rozmiar i czas modyfikacji pliku, który jedna aplikacja zostawia dla drugiej. Trzeci to kolejka: liczba pozycji czekających na przetworzenie, rosnąca wtedy, gdy coś stanęło po drugiej stronie.

Wszystkie trzy mają wspólną cechę. Są niewidoczne dla monitoringu opartego wyłącznie na szablonach, a odpowiadają za większość sytuacji, w których produkcja zauważa problem wcześniej niż dział IT.

Jak układamy ścieżkę powiadamiania w zakładzie na zmiany?

Zaczynamy od pytania, kto jest w budynku o danej porze, a nie od schematu organizacyjnego. W zakładzie pracującym na zmiany adresat zdarzenia zmienia się kilka razy na dobę i przypisanie go do stanowiska w strukturze kończy się wiadomością wysłaną do kogoś, kto śpi.

Ścieżka ma trzy poziomy i wszystkie trzy powstają na papierze przed uruchomieniem. Pierwszy to osoba obecna na zmianie, z jedną czynnością do wykonania. Drugi to człowiek wywoływany po kwadransie ciszy, zwykle utrzymanie ruchu albo Wasz technik. Trzeci to eskalacja do kierownictwa przy zdarzeniu zatrzymującym produkcję. Do tego dochodzi lista rzeczy, które nie wołają nikogo i czekają w kolejce do rana.

Podział między zdarzenia wywołujące a czekające jest decyzją zakładu, nie naszą. My mówimy, co technicznie da się wykryć i jak szybko, Wy mówicie, co jest warte wywołania człowieka w środku nocy. Zapisujemy to razem, bo bez tego zapisu każda nocna sytuacja jest improwizacją.

Osobno zapisujemy godziny, w jakich biegnie nasza reakcja. Sam pomiar pracuje bez przerwy, natomiast gwarantowany czas reakcji człowieka po naszej stronie liczy się od poniedziałku do piątku, między 8:00 a 18:00. Obecność dyżurnego poza tym przedziałem to osobno płatna usługa, wyceniana po ustaleniu zakresu.

Co robimy na odbiorze, zanim przyjdzie pierwszy prawdziwy alert?

Wywołujemy zdarzenie kontrolne i patrzymy, co się dzieje dalej. To najkrótszy punkt całego wdrożenia i jednocześnie ten, który najczęściej pokazuje błąd: wiadomość idzie do skrzynki, której nikt nie ma na telefonie, numer w ścieżce należy do osoby, która odeszła pół roku temu, albo powiadomienie nie wychodzi w ogóle, bo serwer pocztowy odrzuca nadawcę.

Próba obejmuje dwie sytuacje. Pierwsza to zdarzenie w godzinach pracy, gdzie sprawdzamy całą drogę do naszego helpdesku i z powrotem. Druga to zdarzenie poza tymi godzinami, gdzie sprawdzamy, czy wiadomość dotarła do osoby wskazanej na zmianie i czy wiedziała, co z nią zrobić.

Wynik próby zapisujemy w protokole odbioru razem z czasem dotarcia. Jeżeli coś nie zadziałało, poprawiamy to od razu, bo poprawianie ścieżki powiadamiania w trakcie prawdziwej awarii jest najgorszym możliwym momentem na taką pracę.

Kiedy wystarczy uporządkowanie tego, co już stoi?

Wtedy, gdy Zabbix pracuje, tylko nikt na niego nie patrzy, a to sytuacja częstsza niż brak monitoringu. Objawy są powtarzalne: progi z instalatora zostawione na produkcji, brak zależności między urządzeniami, przez co jedna awaria przełącznika wysyła kilkadziesiąt wiadomości, konfiguracja robiona bezpośrednio na hostach zamiast w szablonach i brak sprawdzenia braku danych, przez które martwe urządzenie wygląda na spokojne.

Taki przegląd trwa około dnia pracy i kosztuje 1 900 zł netto. Przechodzimy grupy, szablony, makra, wyzwalacze i akcje, wyłączamy pozycje, które nie niosą informacji, ustawiamy zależności i dokładamy sprawdzenia świeżości danych. Na koniec zostaje lista poprawek podzielona na wykonane przez nas i te do wykonania po Waszej stronie.

Co przekazujemy do rąk Waszego technika?

Komplet przekazania obejmuje opis architektury z adresami i wersjami, listę urządzeń z przypisanymi szablonami, wykaz wartości granicznych razem z uzasadnieniem, schemat powiadamiania z nazwiskami i przypisaniem do zmian, protokół z próby alarmowej oraz kopię konfiguracji odtwarzalną na czystej maszynie.

Do tego dochodzą dwie procedury, po które sięga się najczęściej: dodanie nowego urządzenia i wyciszenie monitoringu na czas mycia albo postoju technologicznego. Druga jest w zakładzie ważniejsza, niż się wydaje, bo bez okien serwisowych każde zaplanowane zatrzymanie linii produkuje falę zdarzeń, a po kilku takich falach ludzie przestają je czytać.

Szkolenie prowadzimy u Was, a nie zdalnie, bo połowa pytań pada dopiero przy szafie. Wizyty umawiamy z biura przy Grudziądzkiej 136 w dniu roboczym, a stroną umowy i wystawcą faktur jest biuro główne przy Baczyńskiego 24 w Gorzowie Wielkopolskim.

Wizualizację danych z wdrożenia opisuje dashboard w Grafanie dla firm z Torunia, a stały nadzór z obsługą zdarzeń i zestawieniem miesięcznym monitoring infrastruktury IT w Toruniu. Zakres wdrożenia przejdziemy pod numerem +48 888 777 822 albo przez formularz kontaktowy.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026