Teoria monitoringu brzmi pięknie – alerty, dashboardy, proaktywna reakcja. Ale jak to wygląda w praktyce, gdy klient z Tczewa zgłasza się do nas z problemem: serwery padają, a pracownicy są pierwszą linią wykrywania awarii? W tym artykule pokazujemy krok po kroku, jak przeprowadziliśmy wdrożenie Zabbixa w firmie produkcyjnej zatrudniającej 60 osób i co konkretnie osiągnęliśmy po trzech miesiącach.
Profil firmy i punkt wyjścia
Klient prowadzi zakład produkcyjny w okolicach Tczewa. Infrastruktura IT: 3 serwery Windows (ERP, poczta, pliki), 2 serwery Linux (aplikacja webowa, baza danych), 45 stacji roboczych i sieć VPN łącząca dwie lokalizacje. Przed wdrożeniem monitoring praktycznie nie istniał – jedynym mechanizmem wykrywania awarii byli... sami pracownicy. Gdy aplikacja ERP przestawała odpowiadać, ktoś dzwonił do działu IT. Średni czas od wystąpienia problemu do jego wykrycia wynosił 25 minut.
Co monitorowaliśmy?
Na etapie audytu ustaliliśmy priorytety – nie wszystko naraz. Zaczęliśmy od elementów krytycznych dla ciągłości produkcji:
- Dostępność usług: ERP, poczta Exchange, serwer plików, baza PostgreSQL – ping i port check co 60 sekund
- Zasoby systemowe: CPU, RAM, swap – próg alertu 85%, krytyczny 95%
- Przestrzeń dyskowa – alert przy 80%, krytyczny przy 90% (partycje C:, D:, /var, /data)
- Tunele VPN – sprawdzanie co 2 minuty, alert gdy link zerwany dłużej niż 3 minuty
- Czas odpowiedzi bazy danych – zapytanie testowe, alert gdy > 2 sekundy
- Temperatura i stan dysków (SMART) na serwerach fizycznych
- Kopie zapasowe – Zabbix sprawdza co noc, czy plik backupu powstał i ma niezerowy rozmiar
Konfiguracja alertów – kto dostaje co i kiedy?
Jeden z najczęstszych błędów przy wdrożeniu monitoringu to efekt alert flood – wszyscy dostają wszystko i po tygodniu nikt nie czyta powiadomień. Wprowadziliśmy trzystopniowy model eskalacji: poziom informacyjny (tylko log), poziom ostrzegawczy (e-mail do administratora) i poziom krytyczny (SMS + telefon do osoby dyżurnej). Dla każdego hosta zdefiniowaliśmy maintenance windows – np. planowane restarty serwerów w niedzielę w nocy nie generują alertów.
Kluczowa zasada: alert musi wymagać działania. Jeśli powiadomienie nie wiąże się z żadną konkretną czynnością, to nie jest alert – to szum informacyjny. Regularnie przeglądaj listę triggerów i bezlitośnie wyłączaj te, na które IT i tak nie reaguje.
Przykładowy scenariusz: dysk serwera ERP się zapełnia
Zobaczmy, jak wygląda obsługa realnego zdarzenia po wdrożeniu Zabbixa:
- 1Poniedziałek, 14:23 – Zabbix wykrywa, że partycja D: na serwerze ERP osiągnęła 81% zajętości. Trigger "Disk space warning" zmienia status na Problem.
- 214:23 – administrator otrzymuje e-mail z informacją: serwer, partycja, aktualny poziom wypełnienia i trend wzrostu (Zabbix oblicza, za ile dni dysk się zapełni przy obecnym tempie).
- 314:31 – admin sprawdza dashboard, identyfikuje katalog z logami aplikacji jako winowajcę (8 GB starych plików). Czyści logi, wolne miejsce wraca do 55%.
- 414:33 – trigger automatycznie zamyka się ze statusem Resolved. Zdarzenie zostaje zapisane w historii zdarzeń z opisem działań.
- 5Koniec tygodnia – raport tygodniowy pokazuje ten incydent i sugeruje skonfigurowanie automatycznej rotacji logów.
Bez Zabbixa ten dysk zapełniłby się w ciągu 4 dni – ERP przestałoby zapisywać dane, produkcja stanęłaby. Czas reakcji wyniósł 8 minut od wykrycia do rozwiązania. Wcześniej taki problem trwałby minimum kilka godzin.
Dashboardy i raporty
Dla klienta przygotowaliśmy trzy widoki: dashboard operacyjny dla administratora (stan wszystkich hostów, aktywne problemy, wykresy zasobów w czasie rzeczywistym), dashboard zarządczy (dostępność usług w procentach za ostatni miesiąc, liczba incydentów, MTTR) oraz automatyczny raport PDF wysyłany co poniedziałek rano na skrzynkę prezesa. Ten ostatni element okazał się nieoczekiwanie ważny – zarząd zaczął widzieć wartość z IT nie jako centrum kosztów, ale jako zabezpieczenie ciągłości biznesu.
Wyniki po 3 miesiącach
- Średni czas wykrycia awarii: z 25 minut do 2 minut (–92%)
- Czas reakcji IT: skrócony o 80% dzięki natychmiastowym alertom z pełnym kontekstem
- Liczba nieplanowanych przestojów produkcji: z 4 do 0 w ostatnim miesiącu
- Dwa incydenty z dyskami i jeden z bazą danych wykryte i rozwiązane zanim wpłynęły na użytkowników
- Koszty wdrożenia zwróciły się w pierwszym miesiącu po zapobieżeniu przestojowi, który historycznie kosztował firmę ok. 12 000 zł za godzinę
Jeśli Twoja firma w Tczewie, Trójmieście lub gdziekolwiek na Pomorzu nadal dowiaduje się o awariach od pracowników zamiast od systemu – skontaktuj się z nami. Wdrożenie Zabbixa możemy przeprowadzić zdalnie w ciągu jednego tygodnia roboczego, a efekty zobaczysz już w pierwszych dniach działania monitoringu.