Monitoring serwerów Gdańsk

Co robi z serwerem rok podzielony na dwie nierówne części?

Zamienia większość zebranych danych w materiał bezużyteczny do przewidywania czegokolwiek. Trójmiejska firma żyjąca z ruchu turystycznego, obsługi grup albo wynajmu obiektów ma przez osiem miesięcy środowisko, które pracuje na ułamku możliwości. Wykresy są płaskie, kolejki puste, czas odpowiedzi wzorowy i nic w tym obrazie nie zapowiada tego, co wydarzy się w lipcu.

Potem w kilka tygodni wszystko rośnie naraz. Ruch na stronie, liczba rezerwacji na godzinę, zapisy do bazy, wywołania płatności, korespondencja i skanowane dokumenty. Maszyna, która w marcu nudziła się przy dwóch procentach wykorzystania, pracuje przy granicy zapasu i robi to codziennie, przez kilka miesięcy z rzędu.

Nadzór ustawiony pod taką firmę musi więc odpowiadać na inne pytanie niż nadzór nad środowiskiem pracującym równo. Nie chodzi o to, czy dziś jest dobrze, bo zwykle jest. Chodzi o to, ile zostało zapasu względem poprzedniego szczytu i czy tegoroczny szczyt będzie od niego większy.

Które odczyty z lutego nie opisują lipca?

Praktycznie żadne, jeżeli czytać je wprost. Poniższe zestawienie pokazuje, co się w tych dwóch trybach pracy rozjeżdża najmocniej i czym zastępujemy odczyt bieżący, żeby cokolwiek z niego wynikało.

Odczyt	Jak wygląda poza sezonem	Jak wygląda w szczycie	Czym go zastępujemy
Obciążenie procesora	kilka procent przez całą dobę	skoki w godzinach wieczornych	udział czasu powyżej progu w dobie
Kolejka zapisu na dysku	zerowa, poza nocnymi zadaniami	rosnąca przy każdej fali rezerwacji	wartość szczytowa wobec zeszłego sezonu
Czas odpowiedzi bazy	stały i niski	zależny od liczby równoczesnych sesji	najdłuższe zapytanie i liczba blokad
Wolne miejsce	maleje wolno i przewidywalnie	przybiera skokowo z dokumentami	data wyczerpania liczona z tempa sezonu
Pamięć po zadaniach nocnych	wraca do poziomu wyjściowego	nie wraca, bo zadania się nakładają	różnica między porankami kolejnych dni
Liczba sesji do systemu	kilka jednocześnie	kilkadziesiąt w godzinach szczytu	rozkład w dobie, nie średnia dobowa
Zadania kopiowania	kończą się w nocy z zapasem	wchodzą w godziny porannej pracy	czas trwania wobec dostępnego okna

Ostatni wiersz jest tym, który zaskakuje najczęściej. Kopia wykonująca się w lutym w dwie godziny potrafi w lipcu trwać sześć, bo urosła baza i doszły zdjęcia obiektów. Nikt tego nie zauważa, dopóki zadanie nie zacznie kończyć się o dziewiątej rano i obciążać maszyny dokładnie wtedy, gdy zaczynają dzwonić klienci.

Skąd wiadomo w lutym, czy maszyna wytrzyma lipiec?

Z zestawienia trzech liczb, których żadna firma nie ma pod ręką bez pomiaru prowadzonego przez pełny rok. Pierwsza to wartość szczytowa z poprzedniego sezonu, i to nie średnia, tylko rzeczywisty najwyższy odczyt utrzymujący się dłużej niż kilkanaście minut. Druga to przyrost bazy i archiwum od tamtej pory, bo dokumenty z zeszłego roku nigdzie nie zniknęły. Trzecia to zmiana skali działalności, czyli liczba obiektów, umów albo kanałów sprzedaży dołożonych przez ostatnie miesiące.

Z tych trzech rzeczy wychodzi odpowiedź na pytanie zadawane zawsze w tym samym momencie: czy dokładamy zasobu, czy zostawiamy jak jest. Odpowiedź podana w lutym pozwala kupić spokojnie i zamontować w martwym miesiącu. Ta sama odpowiedź podana w lipcu oznacza pracę pod presją, przy pełnym obciążeniu i zwykle drożej.

Firmie, która zaczyna pomiar tuż przed sezonem, mówimy wprost, że rzetelnej prognozy nie dostanie, bo nie ma jej skąd wziąć. Dostanie natomiast normę dnia spokojnego, a to wystarczy, żeby w trakcie szczytu odróżnić wzrost ruchu od usterki.

Dlaczego martwy sezon jest najlepszym terminem na prace?

Bo jest jedynym terminem, w którym przerwa nie kosztuje. W firmie pracującej równomiernie okno serwisowe wybiera się z wykresu godzinowego i zwykle wypada w nocy. Tutaj wykres godzinowy nie ma znaczenia, bo od czerwca do września każda godzina jest zajęta, a od listopada do lutego każda jest wolna.

Praktyczny wniosek jest prosty i układa całą pracę w roku. We wrześniu, gdy jeszcze pamięta się przebieg sezonu, powstaje lista rzeczy do zrobienia: wymiana nośnika zgłaszającego błędy, przejście na nowszą wersję bazy, uporządkowanie archiwum, poprawa okna kopiowania, dołożenie pamięci. Od listopada ta lista idzie do realizacji, spokojnie i po kolei.

Odwrócenie tej kolejności zdarza się częściej, niż wypada przyznać, i wygląda zawsze tak samo. Prace odkłada się do stycznia, w styczniu nikt już nie pamięta, co dokładnie się działo, a lista powstaje z pamięci zamiast z odczytów, więc połowa rzeczy z niej wypada.

Co mierzymy na maszynie przyjmującej rezerwacje i płatności?

Trzy warstwy naraz, bo psują się niezależnie od siebie. Pierwsza to sam system: zasoby, usługi, czas pracy. Druga to baza, i to na niej skupia się większość uwagi, ponieważ w systemach rezerwacyjnych prawie wszystko przechodzi przez zapis. Liczniki PostgreSQL albo MS SQL pokazują najdłuższe zapytanie, liczbę połączeń i blokady, czyli rzeczy, których metryki systemu operacyjnego w ogóle nie widzą. Serwer raportujący kilkanaście procent obciążenia i trzymający jednocześnie zapytanie blokujące od czterech minut jest w kłopocie, choć wygląda na wypoczęty.

Trzecia warstwa to droga do usług, za które nie odpowiadacie: bramki płatniczej, systemu dostawcy noclegów, kanału sprzedaży pośrednika. Mierzymy je osobno, bo przerwa po ich stronie zatrzymuje sprzedaż tak samo skutecznie jak awaria maszyny, a rozdzielenie tych dwóch przypadków zajmuje potem kilkanaście sekund zamiast kwadransa telefonów.

Osobno pilnujemy dat: ważności certyfikatu, terminu odnowienia domeny oraz wyniku nocnego zadania kopiowania. Wszystkie trzy są tanie w pomiarze i wszystkie trzy bolą nieproporcjonalnie mocno, gdy zostaną przeoczone w środku sezonu.

Gdzie kończy się ten nadzór?

Na zdarzeniu z opisem i rekomendacją. Wymiana nośnika, zmiana konfiguracji bazy, migracja na większą maszynę i poprawka w systemie rezerwacyjnym są osobnym zleceniem, rozliczanym godzinowo albo projektowo. Przy naszej stałej administracji serwerami pomiar i roboty mieszczą się w tej samej umowie, więc zalecenie idzie do realizacji bez zakładania kolejnego zlecenia.

Nie zastępujemy autora oprogramowania rezerwacyjnego ani dostawcy platformy sprzedażowej. Odczyt pokazuje wydłużoną odpowiedź usługi i pozwala rozstrzygnąć, czy zawiniła maszyna. Poprawka w aplikacji należy do tego, kto ją napisał, a korzyść z pomiaru polega na tym, że zgłoszenie do jego wsparcia zawiera minutę i wykres.

Do serwerowni w Oliwie, na Przymorzu, w rejonie Kokoszek oraz w obiektach przy trasach wylotowych dojeżdżamy z biura przy Matemblewskiej 63 w umówionym dniu roboczym. Nie trzymamy tu magazynu części zamiennych, więc przy maszynie, której awaria zatrzymuje sprzedaż w szczycie, doradzamy trzymanie nośnika zapasowego na miejscu jeszcze przed czerwcem.

Sieć, przez którą te maszyny są widoczne, opisuje monitoring sieci w Gdańsku, wariant obejmujący całe środowisko jedną umową to monitoring infrastruktury IT w Gdańsku, a narzędzie stojące pod tymi odczytami wdrożenie Zabbiksa w Gdańsku. Listę maszyn i daty sezonu omówimy pod numerem +48 888 777 822 albo przez formularz kontaktowy.

Treść sprawdzona i zaktualizowana: 2 sierpnia 2026