Monitoring serwerów Białystok

Ile wcześniej musi ostrzegać serwer pilnowany z odległości?

Wystarczająco wcześnie, żeby dało się coś zrobić dostępnymi środkami. To brzmi oczywiście, a przesądza o całej konfiguracji, bo dostępne środki wyglądają inaczej u firmy z informatykiem na miejscu i inaczej w hurtowni pod Białymstokiem, gdzie najbliższa osoba potrafiąca wymienić dysk musi ten dysk najpierw zamówić.

Ostrzeżenie przychodzące na dwie godziny przed zatrzymaniem maszyny jest w takiej firmie prawie bezużyteczne. To samo ostrzeżenie wysłane trzy tygodnie wcześniej zmienia awarię w pozycję na liście zakupów i w punkt najbliższego przeglądu. Cała robota przy strojeniu polega więc na przesunięciu momentu ostrzeżenia tak daleko w tył, jak pozwala na to charakter odczytu.

Nie każdy odczyt na to pozwala i o tym też mówimy wprost. Zasilacz potrafi paść bez zapowiedzi, a łącze zniknąć w sekundę. Dlatego dzielimy odczyty na te, które kupują dni, i te, które nie kupują nic, a dla drugiej grupy szukamy zabezpieczeń zamiast wcześniejszych ostrzeżeń.

Które odczyty dają zapas w dniach, a które w minutach?

Odczyt	Jaki zapas zwykle daje	Co z nim robimy
Tempo przyrostu danych na dysku	tygodnie	data wyczerpania miejsca i decyzja o rozbudowie
Pierwszy błąd odczytu dysku w macierzy	dni	zamówienie części pod najbliższą wizytę
Bateria zasilacza awaryjnego tracąca pojemność	tygodnie	wymiana wpisana do przeglądu okresowego
Rosnąca temperatura w szafie	dni	sprawdzenie wentylacji przez Waszą osobę
Pamięć nieodzyskiwana po nocnych zadaniach	dni	poprawka po stronie aplikacji, bez pośpiechu
Zadanie kopii kończące się błędem	godziny	prace zdalne tego samego dnia
Usługa przestająca odpowiadać	minuty	restart z konsoli, bez udziału kogokolwiek u Was
Awaria zasilacza w serwerze	brak zapasu	praca na drugim zasilaczu, wymiana przy wizycie

Dwa dolne wiersze pokazują, dlaczego sama czułość niczego nie załatwia. Przy zdarzeniach bez zapasu czasu ratuje wyłącznie nadmiarowość kupiona wcześniej: drugi zasilacz, dysk w macierzy z zapasem, druga maszyna. Dlatego przy każdym przeglądzie wypisujemy miejsca, w których pojedyncza część zatrzymuje pracę całej firmy.

Dlaczego pierwszy błąd dysku traktujemy tutaj poważniej?

Bo między zgłoszeniem błędu a wypadnięciem dysku mieści się cała logistyka. Trzeba potwierdzić model, sprawdzić gwarancję, zamówić część, poczekać na dostawę i dopiero wtedy ktoś staje przy szafie. W firmie mającej informatyka na korytarzu ta sekwencja trwa dzień. Bez niego trwa tyle, ile trwa, i właśnie dlatego zaczynamy ją od pierwszego zgłoszonego błędu, a nie od momentu, w którym macierz przechodzi w stan awaryjny.

Skutek jest praktyczny i tani. Wymiana pojedynczego dysku kosztuje tyle, ile kosztuje dysk, i mieści się w umówionym przyjeździe. Odbudowa macierzy po wypadnięciu drugiego kosztuje przestój, wyjazd poza planem i czasem dane, których nikt nie odtworzy w całości.

Co leży u Was na półce i kto to wymienia?

Zestaw zapasu ustalamy przy starcie i jest krótki: dysk tego samego typu co w macierzy, komplet baterii do zasilacza awaryjnego oraz zasilacz do serwera, o ile maszyna ma tylko jeden. Wszystko podpisane, z numerami i zdjęciem miejsca, w którym ma trafić.

Wymianę prowadzi Wasza osoba z kluczem do serwerowni, a my prowadzimy ją przez telefon, mając przed sobą stan kontrolera i widok maszyny. Kolejność czynności jest zapisana wcześniej i sprowadza się do kilku kroków, bo tak wygląda wymiana dysku w kieszeni, gdy sprzęt jest opisany, a nie odgadywany po lampkach.

Tam, gdzie takiej osoby nie ma albo praca wykracza poza wymianę modułu, robotę bierzemy na siebie przy przyjeździe z Warszawy. Termin ustalamy przy zgłoszeniu, razem z listą rzeczy do zrobienia u Was w międzyczasie.

Co sprawdzamy inaczej na Windows Server, a co na Linuksie?

Na Windows Server pilnujemy stanu usług, replikacji katalogu, czasu systemowego oraz zadań aktualizacji, bo restart po poprawkach wypadający w środku przyjęcia towaru zatrzymuje przyjęcie towaru. Na Linuksie zbieramy obciążenie średnie, stan usług w systemd, zajętość i-węzłów oraz stan macierzy programowej, która potrafi pracować w stanie awaryjnym miesiącami, nie mówiąc o tym nikomu.

Bazy danych traktujemy osobno na obu systemach. MS SQL, PostgreSQL i MySQL mają własne liczniki, a długie zapytanie blokujące resztę nie zostawia po sobie śladu w metrykach systemowych. W podlaskich firmach handlowych i przetwórczych to najczęstsza przyczyna zgłoszeń o programie, który „chodzi wolno”, przy zupełnie spokojnym procesorze.

Jak wygląda przegląd maszyn przy wizycie?

Przyjazd jest jedynym momentem, w którym oglądamy rzeczy niewidoczne w żadnym odczycie, więc ma stałą listę. Otwieramy obudowy i sprawdzamy zapylenie, bo w zakładzie przetwórczym i w hali magazynowej filtr zapycha się szybciej niż w biurze. Mierzymy temperaturę w szafie przy zamkniętych drzwiach. Sprawdzamy wiek dysków i zasilaczy pod kątem tego, co planować na kolejny rok. Testujemy przełączenie na zasilanie awaryjne, bo to jedyny sposób, żeby dowiedzieć się o zużytej baterii przed prawdziwym zanikiem.

Z takiej wizyty zostaje wykaz sprzętu z wiekiem i stanem oraz lista pozycji do zaplanowania na najbliższe miesiące. Dzięki temu rozmowa o wydatku odbywa się przy budżecie, a nie przy stojącej maszynie.

Czego ten nadzór nie obejmuje?

Nie obejmuje napraw sprzętowych, obsługi gwarancji u producenta ani dostawy części, bo to osobne pozycje z własnym rozliczeniem. Nie sprawdza też poprawności danych: baza potrafi odpowiadać w milisekundach i zwracać wyniki sprzed tygodnia, gdy integracja przestała je wgrywać, a takie sprawdzenie piszemy osobno, gdy wiadomo, co konkretnie ma być pilnowane.

Łącza i urządzenia, przez które te maszyny są dostępne, opisuje monitoring sieci, pełny nadzór z jednym rejestrem i raportem to monitoring infrastruktury IT, a narzędzie stojące pod spodem to wdrożenie Zabbiksa.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026