Monitoring serwerów Olsztyn

Dlaczego działający serwer nie znaczy działającego meldunku?

Bo między maszyną a recepcją stoi zwykle kilka warstw i każda potrafi zawieść osobno. Baza odpowiada w milisekundach, obciążenie jest niskie, miejsce na dysku w porządku, a przy ladzie nie da się zameldować gościa, bo zatrzymała się usługa pośrednicząca między programem obiektowym a bazą albo skończyła się sesja do systemu dostawcy.

Klasyczny zestaw odczytów tego nie pokaże i nie ma takiego obowiązku. Procesor, pamięć i kolejka dysku opisują stan maszyny, nie stan procesu, który na niej biegnie. W biurze różnica bywa akademicka, bo ktoś zgłosi problem w ciągu kwadransa. W obiekcie nad jeziorem kwadrans wypełnia się kolejką i telefonami do właściciela.

Dlatego na Warmii dokładamy do zwykłego zestawu drugą warstwę: sprawdzenia opisujące pojedyncze czynności. Zapytanie o wolne terminy, zapis pozycji kontrolnej i jej skasowanie przechodzą dokładnie tę samą drogę co pracownik recepcji, tylko robi to system co kilka minut i o każdej porze.

Które maszyny stoją w obiekcie i co z nich czytamy?

Środowisko obiektu turystycznego wygląda inaczej niż środowisko firmy biurowej tej samej wielkości. Maszyn jest mało, za to każda odpowiada za inny fragment pobytu gościa, więc awaria każdej z nich wygląda przy ladzie zupełnie inaczej.

Maszyna	Co czytamy poza zasobami	Po czym gość poznaje awarię
Host wirtualizacji	migawki, zajętość magazynu, stan macierzy	wszystko naraz przestaje odpowiadać
Serwer bazy systemu obiektowego	czas zapisu rezerwacji, blokady, długie zapytania	meldowanie trwa minutami albo nie kończy się wcale
Pośrednik do systemu dostawcy	świeżość danych i stan sesji	pokój pokazuje się jako wolny, choć jest zajęty
Serwer plików i dokumentów	miejsce, tempo przyrostu, zadania kopii	nie da się wydrukować rachunku ani umowy
Rejestrator obrazu	zapis z kamer, temperatura, stan dysków	brak nagrania odkrywany dopiero przy sporze
Sterowanie dostępem do pokoi	dostępność usługi i odpowiedź kontrolera	karta nie otwiera drzwi po zameldowaniu
Zasilanie gwarantowane szafy	praca na bateriach i czas podtrzymania	nagła cisza we wszystkich systemach naraz

Trzeci wiersz jest najbardziej kosztowny z całej listy i jednocześnie najtrudniejszy do zauważenia. Pośrednik, który przestał wymieniać dane, nie wywołuje żadnego przekroczenia progu, a skutkiem jest podwójna sprzedaż tego samego pokoju w szczycie sezonu, czyli sytuacja rozwiązywana zwykle na koszt obiektu.

Jak planujemy pojemność, skoro luty nic nie mówi o lipcu?

Porównaniem rok do roku, nie tydzień do tygodnia. W obiekcie pracującym sezonowo zestawienie z ostatnimi dniami jest bezużyteczne, bo opisuje inne obłożenie, inną liczbę osób przy stanowiskach i inną liczbę zapisów w bazie. Jedyną sensowną odpowiedzią na pytanie, czy maszyna wytrzyma sierpień, jest zapis z poprzedniego sierpnia.

Stąd decyzja, którą podejmujemy przy uruchomieniu: odczyty w pełnej rozdzielczości trzymamy przez miesiąc, a dane uśrednione przez trzynaście miesięcy. Ten trzynasty miesiąc nie jest ozdobnikiem, tylko całym sensem układu, ponieważ pozwala postawić obok siebie ten sam tydzień dwóch kolejnych sezonów, zamiast porównywać szczyt z zimowym postojem.

Praktyczny efekt widać przy rozmowie o wydatku. Zdanie o tym, że serwer bywa obciążony, nie przekonuje nikogo. Zestawienie pokazujące, że w tym roku ten sam tydzień lipca ma o połowę dłuższy czas zapisu rezerwacji niż rok wcześniej, jest argumentem, który da się zamienić na decyzję o zakupie jeszcze przed sezonem.

Czego nie instalujemy na serwerze systemu rezerwacyjnego?

Niczego, jeżeli jego dostawca zastrzegł to w umowie serwisowej, a robi tak większość dostawców oprogramowania dla obiektów. Taka maszyna trafia pod obserwację prowadzoną wyłącznie z sieci: sprawdzamy dostępność jej usług, czas odpowiedzi, obecność świeżych danych po stronie, którą widzimy, oraz to, czy nadal przyjmuje połączenia ze stanowisk przy ladzie.

Do wykrycia zatrzymania to w zupełności wystarcza. Bez agenta nie zobaczymy wnętrza maszyny, czyli obciążenia i miejsca na dyskach, i mówimy o tym wprost zamiast obiecywać pełen obraz. Jeżeli dostawca udostępnia własny interfejs z danymi o stanie usługi, podpinamy go jako kolejne źródło i wtedy część brakującego obrazu wraca.

Osobno ustalamy, co robimy przy zdarzeniu na takiej maszynie. Restart bywa zakazany, więc zdarzenie idzie do dostawcy z opisem i godziną, a Wasza obsługa w tym samym momencie dostaje informację, że sprawa jest zgłoszona i jak długo zwykle trwa. To jedyny uczciwy sposób prowadzenia nadzoru nad cudzym sprzętem.

Co zostaje poza pomiarem maszyn?

Naprawa, wymiana podzespołów i praca po stronie dostawcy oprogramowania. Przy samym pomiarze dostajecie zdarzenie z opisem i rekomendacją, a wykonanie zostaje u Was albo trafia do nas jako osobne zlecenie rozliczane godzinowo. Przy stałej administracji serwerami działanie rusza bez czekania na zgłoszenie.

Pomiar nie odpowie też na pytanie, czy dane są poprawne. Baza może odpowiadać natychmiast i pokazywać dostępność sprzed dwóch dni, bo synchronizacja z portalami stanęła. Takie sprawdzenie piszemy osobno, razem z osobą znającą ten proces po Waszej stronie, i to ono ratuje przed dwoma gośćmi w jednym pokoju.

Kiedy trzeba stanąć przy szafie, przyjeżdża inżynier z biura przy Grudziądzkiej 136 w Toruniu, w umówionym dniu roboczym, a stroną umowy pozostaje biuro główne przy Baczyńskiego 24 w Gorzowie Wielkopolskim. Warunki w pomieszczeniach i całą warstwę zdarzeń opisuje monitoring infrastruktury IT w Olsztynie, drogę między budynkami monitoring sieci w Olsztynie, a narzędzie, na którym to stoi, wdrożenie Zabbiksa w Olsztynie. Listę maszyn przejdziemy pod numerem +48 888 777 822 albo przez formularz kontaktowy.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026