Monitoring serwerów Barlinek

Co zapowiada awarię serwera, zanim ktokolwiek ją zauważy?

Prawie zawsze te same trzy rzeczy. Pierwsza to dysk zgłaszający błędy odczytu. Kontroler macierzy widzi je od tygodni i notuje, ale nikt nie zagląda do jego panelu, więc dysk pracuje dalej, aż wypadnie z macierzy. Wtedy zaczyna się odbudowa, w trakcie której obciążenie rośnie i drugi dysk potrafi pójść śladem pierwszego.

Druga to kończące się miejsce. Baza programu handlowego rośnie o kilkaset megabajtów miesięcznie, do tego dochodzą skany faktur i kopie robione na tym samym dysku. Firma dowiaduje się o problemie w chwili, gdy program przestaje zapisywać dokumenty, zwykle w najgorszym możliwym dniu miesiąca.

Trzecia to pamięć i restarty. Serwer, który zaczyna restartować się w nocy, robi to zwykle z powodu, który da się znaleźć, ale nikt tego nie widzi, bo rano wszystko działa. Dopiero zapis czasu nieprzerwanej pracy pokazuje, że maszyna wstawała pięć razy w ciągu miesiąca.

Co czytamy z maszyny co minutę?

Odczyt	Próg, przy którym reagujemy	Typowa przyczyna
Miejsce na dysku	80 procent lub prognoza poniżej 30 dni	logi, kopie, archiwum poczty
Kolejka dysku	utrzymująca się przez kilkanaście minut	za mało pamięci, wolna macierz
Pamięć	brak wolnej przez dłuższy czas	wyciek w aplikacji, za mała maszyna
Stan dysku w macierzy	pierwszy zgłoszony błąd	naturalne zużycie po latach
Czas pracy maszyny	reset licznika	nieplanowany restart, przerwa w prądzie
Usługa bazy	brak odpowiedzi przez minutę	zapełniony dysk, blokada, awaria

Progi z drugiej kolumny są punktem wyjścia. Po dwóch tygodniach obserwacji zmieniamy je na dopasowane do konkretnej maszyny, bo serwer plików i serwer bazy zachowują się zupełnie inaczej i te same wartości byłyby dla jednego z nich bezużyteczne.

Dlaczego usługi sprawdzamy osobno od maszyny?

Bo serwer potrafi być włączony i odpowiadać na pytanie o stan, podczas gdy program, dla którego istnieje, nie działa. Baza może być zatrzymana, usługa wydruku zawieszona, a zadanie nocne przerwane w połowie. Z punktu widzenia maszyny wszystko jest w porządku.

Dlatego dla każdego serwera spisujemy, po co on jest, i sprawdzamy dokładnie te rzeczy. W zakładzie jest to zwykle baza programu handlowego, usługa udostępniania plików, kolejka wydruku etykiet i zadania nocne. W gabinecie albo w biurze rachunkowym lista wygląda inaczej i układamy ją od nowa.

Ta lista bywa pierwszym dokumentem, w którym w firmie spisano, co właściwie robi jej serwer. Zaskakująco często okazuje się przy tym, że działają na nim usługi, z których nikt nie korzysta od lat.

Co dostajecie po awarii, której nie dało się uniknąć?

Zapis. Wiemy, co działo się w godzinach poprzedzających zdarzenie: kiedy zaczęło brakować pamięci, kiedy wzrosła kolejka dysku, o której maszyna przestała odpowiadać. Bez tego zapisu analiza po awarii sprowadza się do zgadywania, a rozmowa z serwisem sprzętu albo z producentem programu do wymiany przypuszczeń.

Ten sam zapis rozstrzyga spory. Kiedy producent programu twierdzi, że problem leży w serwerze, a Wy podejrzewacie program, dane z monitoringu pokazują, co naprawdę było obciążone. W małej firmie, która nie ma jak takiej rozmowy wygrać, jest to argument rozstrzygający.

Kiedy jeden serwer to za mało i co wtedy?

Kiedy stoi na nim wszystko naraz: katalog domenowy, pliki, baza handlowa i kopie. Wtedy każda pojedyncza awaria zatrzymuje firmę w całości, a każda aktualizacja wymaga okna serwisowego dla wszystkich usług jednocześnie.

Monitoring pokazuje to czarno na białym, bo widać, że jedna maszyna obsługuje kilka niezależnych zadań i że obciążenie jednego psuje pracę pozostałych. Rozdzielenie ról na maszyny wirtualne jest wtedy naturalnym następnym krokiem i opisaliśmy je przy administracji serwerami.

Szerszy zakres, obejmujący także sieć, łącze i kopie, opisaliśmy przy monitoringu infrastruktury, a własny system w Waszej firmie przy wdrożeniu Zabbiksa.

Treść sprawdzona i zaktualizowana: 31 lipca 2026