Monitoring serwerów Wrocław

Która maszyna naprawdę wymaga alarmu?

W firmie produktowej z Wrocławia liczba serwerów rośnie szybciej niż liczba osób, które mają czas na nie patrzeć. Zaczyna się od produkcji i jednej maszyny testowej, po roku jest staging, środowisko przeglądowe zakładane do każdej gałęzi kodu, maszyna pod demo dla klienta i dwie instancje po projekcie, którego nikt już nie prowadzi.

Jeżeli wszystkie dostaną te same progi, monitoring zamienia się w strumień zdarzeń bez wagi. Zapełniony dysk na maszynie przeglądowej wygląda wtedy tak samo jak zapełniony dysk pod bazą produkcyjną, a po dwóch tygodniach obie kategorie są ignorowane z równą starannością.

Dlatego pierwszym krokiem nie jest instalacja agenta, tylko spis maszyn z rolą przy każdej. Rola decyduje o zestawie sprawdzeń, o wadze zdarzenia i o tym, kto je dostaje.

Środowisko	Co pilnujemy najpierw	Waga zdarzenia	Do kogo trafia
Produkcja aplikacji	dostępność usługi, kolejka dysku, liczniki bazy	krytyczna	kolejka zdarzeń i dyżurny
Baza produkcyjna	zapas miejsca, zapytania blokujące, replikacja	krytyczna	administrator baz danych
Staging	dostępność i zajętość dysku	ostrzeżenie	zespół deweloperski
Środowiska przeglądowe	sam fakt istnienia i zajęte zasoby węzła	informacja	zespół deweloperski
Maszyna pod demo	dostępność w godzinach prezentacji	ostrzeżenie	osoba prowadząca demo
Host wirtualizacji	wolne zasoby, migawki, stan macierzy	krytyczna	administrator
Środowiska bez właściciela	zużycie zasobów i data ostatniego logowania	informacja	raport miesięczny

Ostatni wiersz zwykle płaci za całą usługę w pierwszym kwartale. Maszyny, do których nikt się nie loguje od pół roku, zajmują pamięć na hoście i miejsce w kopii, a znikają dopiero wtedy, gdy ktoś je wypisze na liście z datami.

Skąd biorą się serwery, o których nikt nie pamięta?

Z tempa pracy, nie z niedbalstwa. Środowisko zakładane na dwa dni testów zostaje na dwa lata, bo nikt nie zamyka rzeczy, które nie przeszkadzają. Widać to najwyraźniej u firm, które w rok podwoiły zespół: każda nowa osoba dostawała własną instancję do eksperymentów, a proces kasowania nie powstał, bo nikt go nie potrzebował, dopóki maszyn było pięć.

Monitoring rozwiązuje to bez regulaminu. Każdy host ma w spisie właściciela i datę ostatniej aktywności, a raport miesięczny zawiera listę maszyn bez ruchu. Decyzja o wyłączeniu należy do Was, ale podejmuje się ją na podstawie zestawienia z liczbami, a nie w trakcie porządków po zapełnionym hoście wirtualizacji.

Co mierzymy pod kontenerami, a co pod bazą?

Na hoście z Dockerem albo z węzłem Kubernetes sam procesor i pamięć maszyny mówią mało. Liczy się liczba restartów kontenera, przekroczenia limitów pamięci, czas życia procesu i miejsce zajęte przez obrazy oraz warstwy, które potrafią wypełnić dysk bez żadnego wzrostu ruchu. Kontener restartujący się co godzinę przez tydzień nie generuje ani jednego przekroczenia progu na poziomie hosta.

Pod bazą patrzymy na zupełnie inne rzeczy: liczbę aktywnych połączeń wobec limitu, opóźnienie replikacji, czas najdłuższego zapytania, blokady oraz przyrost plików danych. PostgreSQL, MySQL i MS SQL mają własne liczniki i żaden z nich nie zostawia śladu w metrykach systemowych, więc baza potrafi stać w miejscu przy całkowicie spokojnym wykresie obciążenia maszyny.

Osobno pilnujemy czasu systemowego i wersji jądra po aktualizacjach, bo rozjechany zegar wywraca uwierzytelnianie w usługach i psuje korelację zdarzeń między maszynami, co przy analizie incydentu kosztuje więcej niż sama awaria.

Dlaczego progi z produkcji nie pasują do środowiska testowego?

Bo maszyny mają inny rytm pracy. Serwer produkcyjny ma przewidywalny profil dobowy i każde odchylenie coś znaczy. Maszyna testowa przez trzy dni stoi bez obciążenia, a czwartego zjada wszystko, co dostanie, bo ktoś uruchomił na niej odtworzenie bazy z produkcji. Ten sam próg obsługuje jedną sytuację i produkuje fałszywe zdarzenia w drugiej.

Dlatego przez pierwsze dwa tygodnie monitoring pracuje w trybie obserwacji, zbierając dane bez wysyłania powiadomień. Dopiero z tych danych ustawiamy wartości graniczne, osobno dla każdej klasy maszyn, i trzymamy je w makrach na poziomie szablonu, żeby zmiana progu dla wszystkich serwerów baz danych była jedną edycją, a nie dwudziestoma.

Kto ogląda odczyty po osiemnastej?

Rozdzielenie dwóch rzeczy jest tu warunkiem uczciwej umowy. Pomiar trwa bez przerwy, przez całą dobę, także w weekendy, więc historia z nocy jest kompletna i incydent da się odtworzyć co do minuty. Gwarantowany czas reakcji człowieka liczymy natomiast wyłącznie w godzinach pracy helpdesku, od poniedziałku do piątku, 8:00 do 18:00.

Reakcja poza tymi godzinami to dyżur, czyli osobno płatna usługa wyceniana indywidualnie po ustaleniu zakresu. Przy jej zamawianiu ustalamy, które zdarzenia są budzące, a które czekają do rana, bo lista, na której wszystko jest krytyczne, jest listą, z której nikt nie korzysta.

Czego ten nadzór nie obejmuje?

Nie obejmuje pracy nad kodem, strojenia zapytań ani wdrażania zmian, choć wskazujemy zapytanie i godzinę, w której zaczęło szkodzić. Nie zastępuje kopii zapasowych: sprawdzamy, czy zadanie się wykonało, ale odtworzenie środowiska to osobna praca. Nie obejmuje też sieci, przez którą maszyny są dostępne.

Łącza, tunele i sieć w wynajmowanym biurze opisuje monitoring sieci we Wrocławiu, pełny nadzór ze sprawdzaniem ścieżki zakupowej z zewnątrz to monitoring infrastruktury IT we Wrocławiu, a narzędzie stojące pod tymi odczytami opisuje wdrożenie Zabbiksa dla firm z Wrocławia. Spis maszyn i wagi zdarzeń ustalimy pod numerem +48 888 777 822.

Treść sprawdzona i zaktualizowana: 31 lipca 2026