Monitoring serwerów Łódź

Jak wygląda doba maszyny w firmie wysyłkowej?

Zupełnie inaczej niż doba serwera biurowego i to jest jedyny powód, dla którego ta strona wygląda inaczej od pozostałych. W łódzkiej firmie realizującej zamówienia z własnej hali obciążenie nie rozkłada się równomiernie ani nie zależy od tego, ilu ludzi siedzi przy biurkach. Wyznaczają je trzy rzeczy: pora, o której kupujący składają zamówienia, godzina odbioru towaru przez kuriera i moment, w którym uruchamiają się zadania wsadowe.

Efekt jest taki, że pojedyncza wartość graniczna dla całej doby albo alarmuje co wieczór bez powodu, albo milczy wtedy, gdy powinna się odezwać. Po dwóch tygodniach pomiaru rozkład widać wyraźnie i dopiero z niego wyprowadzamy progi.

Pora doby	Co obciąża maszyny	Odczyt o najwyższej wadze	Objaw przy braku zapasu
Noc	przeliczenia, kopie, import z hurtowni	czas trwania zadania wobec poprzedniej doby	zadanie wchodzące w poranny rozruch
Wczesny ranek	przekazanie zamówień do systemu magazynowego	wiek najstarszej pozycji w kolejce	kompletacja startująca z opóźnieniem
Przedpołudnie	skanowanie, wydruki, praca na terminalach	kolejka zapisu i czas odpowiedzi bazy	terminal czekający po każdym skanie
Wczesne popołudnie	ruch na sklepie w godzinach największej sprzedaży	czas odpowiedzi aplikacji sklepu	koszyki porzucane przed kasą
Godzina przed odbiorem	wydruk listów przewozowych i zamknięcie wysyłek	dostępność usługi kurierskiej i drukarek	paczki zostające na następny dzień
Wieczór	druga fala zamówień po pracy	pamięć nieodzyskana po zadaniach dnia	sklep zwalniający przy największym ruchu
Weekend	ruch bez zmian, obsada minimalna	zadania zakończone błędem bez odbiorcy	usterka odkryta dopiero w poniedziałek

Ostatni wiersz jest tym, który klienci dopisują sami po pierwszym sezonie. Zadanie kopiowania kończące się błędem w sobotę rano potrafi zostać niezauważone przez dwa dni, a to jedyny rodzaj usterki, której skutków nie da się cofnąć.

Które odczyty psują się pierwsze przy fali zamówień?

Prawie zawsze te związane z zapisem, a nie z obliczeniami. Wykres obciążenia procesora bywa przy tym spokojny do końca, co jest głównym powodem, dla którego przy pierwszym zgłoszeniu wszyscy szukają nie tam, gdzie trzeba.

Pierwszy odzywa się czas oczekiwania na dysk, bo każde zamówienie to zapis w kilku tabelach naraz, a przy fali te zapisy ustawiają się w kolejkę. Drugie są blokady w bazie: dwie operacje sięgające po ten sam rekord stanu magazynowego czekają na siebie, a przy kilkuset zamówieniach na godzinę czekanie robi się widoczne na ekranie kupującego. Trzecia to pamięć, która przestaje wracać do poziomu sprzed porannego importu, przez co wieczorna fala trafia na maszynę z mniejszym zapasem, niż wynikałoby ze specyfikacji.

Dlatego liczniki PostgreSQL, MySQL albo MS SQL czytamy osobno od metryk systemu i to one dostają wyższą wagę. Serwer, który raportuje kilkanaście procent obciążenia i jednocześnie trzyma zapytanie blokujące od czterech minut, jest w kłopocie, choć w prostym pomiarze wygląda na wypoczęty.

Co znaczy zapas policzony na najbliższy szczyt?

Znaczy, że zamiast procentów podajemy odpowiedź na jedno pytanie: czy ta maszyna dociągnie do kampanii bez dokładania zasobów. Liczymy ją z tempa przyrostu z ostatnich tygodni i doliczamy skok zaobserwowany w poprzednim sezonie, o ile mamy z czego go odczytać.

Wychodzi z tego data albo zdanie o tym, że danych jest za mało, i tę drugą odpowiedź też podajemy wprost. Firma, która uruchomiła pomiar we wrześniu, nie dostanie od nas rzetelnej prognozy na listopad, bo nie ma jej skąd wziąć. Dostanie natomiast normę dnia zwykłego i to wystarcza, żeby w trakcie szczytu odróżnić wzrost od usterki.

Ta sama zasada dotyczy archiwum dokumentów sprzedażowych i zdjęć towaru. Rozszerzenie asortymentu przesuwa datę wyczerpania miejsca o kilka miesięcy, a informacja o tym powinna trafić do osoby układającej budżet, nie do skrzynki administratora.

Dlaczego wolny sklep bywa winą jednego zapytania?

Bo w sklepie internetowym prawie wszystko idzie przez bazę, a jedno źle zaplanowane zapytanie potrafi zająć zasoby, których brakuje potem wszystkim pozostałym. Najczęstsze przypadki są powtarzalne: raport sprzedaży uruchamiany w środku dnia przez osobę z działu handlowego, wyszukiwanie po opisie towaru bez przygotowanego indeksu, integracja pobierająca stany magazynowe w pętli zamiast jednym wywołaniem.

Metryki systemu nie pokazują żadnej z tych rzeczy. Pokazuje je licznik najdłuższego zapytania i lista sesji oczekujących, dlatego trafiają do pomiaru od pierwszego dnia. Wynik takiego odczytu bywa przy tym niewygodny dla wszystkich, bo wskazuje przyczynę w oprogramowaniu, a nie w sprzęcie.

Dla firmy jest to jednak najtańszy możliwy wynik. Zmiana jednego zapytania kosztuje ułamek tego, co kosztuje maszyna kupiona po to, żeby udźwignąć błąd, którego nikt nie znalazł.

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 kodzie sklepu są osobną pracą, rozliczaną godzinowo albo projektowo. Firmy korzystające z naszej stałej administracji serwerami mają pomiar i prace w jednej umowie, więc zalecenie idzie do realizacji bez zakładania odrębnego zlecenia.

Nie zastępujemy też autora oprogramowania sklepowego ani dostawcy systemu magazynowego. Widzimy, że usługa odpowiada wolniej, i potrafimy wskazać, czy przyczyna leży po stronie maszyny. Poprawka w aplikacji należy do tego, kto ją napisał, a wartość pomiaru polega na tym, że rozmowa z jego wsparciem zaczyna się od wykresu z konkretnej minuty.

Do serwerowni w halach na Olechowie, w Teofilowie i przy węźle autostrad dojeżdżamy z biura przy Zakładowej 13 w umówionym dniu roboczym. Sieć, przez którą te maszyny są widoczne z hali, opisuje monitoring sieci w Łodzi, wariant obejmujący sklep i magazyn jedną umową to monitoring infrastruktury IT w Łodzi, a narzędzie stojące pod tymi odczytami wdrożenie Zabbiksa w Łodzi. Listę maszyn omówimy pod numerem +48 888 777 822 albo przez formularz kontaktowy.

Treść sprawdzona i zaktualizowana: 2 sierpnia 2026