- usługi
- Monitoring serwerów
Co obejmuje monitoring serwerów?
Monitoring serwera to nie jeden wykres obciążenia. To zestaw kilkudziesięciu odczytów, z których każdy ma sens dopiero w kontekście tej maszyny i jej roli. Poniżej sześć obszarów, które obejmujemy na każdym serwerze, niezależnie od systemu i od tego, czy stoi u Was, czy w centrum danych.
- 01
Zasoby i wydajność
Procesor, pamięć, kolejka dysku i przepustowość, czytane razem, bo pojedyncza liczba niczego nie dowodzi.
- 02
Miejsce na dyskach z prognozą
Nie tylko procent zajętości, ale tempo przyrostu i data, w której miejsce się skończy.
- 03
Stan sprzętu
Dyski w macierzy, zasilacze, wentylatory i temperatura, czytane z kontrolera i z interfejsu zarządzającego.
- 04
Usługi i procesy
Baza danych, serwer aplikacji, kolejki i zadania cykliczne, sprawdzane osobno od samej maszyny.
- 05
Aktualizacje i restarty
Nieplanowany restart, oczekujące poprawki i czas nieprzerwanej pracy widoczne w jednym miejscu.
- 06
Logi zdarzeń
Wybrane wpisy systemowe, które zapowiadają awarię, zamiast całego dziennika, którego nikt nie czyta.
Ile kosztuje monitoring serwerów?
Monitoring pięciu serwerów zaczyna się od 290 zł netto miesięcznie i obejmuje agenty, progi dobrane do środowiska, dyżur w dni robocze oraz raport. Stawka od maszyny maleje wraz z ich liczbą. Przy stałej administracji serwerami monitoring jest już wliczony w opiekę i nie płacicie za niego drugi raz.
Tyle kosztuje: nadzór nad pięcioma serwerami, dyżur w dni robocze.
Wszystkie kwoty są netto. Tej usługi nie sprzedajemy z cennika, więc dokładną kwotę podajemy po rozmowie o zakresie, przed podpisaniem umowy.
Które liczby na serwerze naprawdę coś znaczą
Panel z dwudziestoma wykresami wygląda poważnie i nie mówi nic. Sens ma kilka odczytów czytanych razem, bo dopiero ich kombinacja odróżnia maszynę pracującą pod obciążeniem od maszyny, która za chwilę stanie.
| Odczyt | Kiedy zaczyna niepokoić | Co zwykle oznacza |
|---|---|---|
| Kolejka operacji dyskowych | utrzymuje się powyżej kilku operacji | dysk nie nadąża, baza zwalnia mimo wolnego procesora |
| Czas odpowiedzi dysku | powyżej kilkunastu milisekund | zużyty nośnik albo przeciążona macierz |
| Pamięć nieodzyskana po nocy | rośnie z dnia na dzień | wyciek w aplikacji, restart tylko odsuwa problem |
| Zajętość dysku systemowego | tempo przyrostu, nie procent | logi bez rotacji, kopie zapisywane w złe miejsce |
| Czas pracy bez restartu | zerowanie się bez planu | nieplanowany restart, zwykle po awarii zasilania |
| Obciążenie procesora | stałe wysokie przez godziny | zadanie, które się zapętliło, albo za mała maszyna |
| Stan dysku w macierzy | pierwszy błąd odczytu | dysk do wymiany, zanim wypadnie drugi |
Ostatni wiersz jest najtańszą pozycją z całej listy. Wymiana jednego dysku kosztuje tyle, ile kosztuje dysk. Odbudowa macierzy po wypadnięciu drugiego kosztuje weekend pracy i czasem dane.
Dlaczego domyślne progi generują hałas
Instalator monitoringu ustawia progi uniwersalne, na przykład ostrzeżenie przy osiemdziesięciu procentach zajętości dysku. Na serwerze plików, który rośnie o procent miesięcznie, taki alert przyjdzie rok za wcześnie i zostanie wyciszony. Na serwerze bazy danych, który potrafi zająć dziesięć procent w jedną noc, przyjdzie za późno.
Dlatego pierwsze dwa tygodnie po uruchomieniu monitoring pracuje w trybie obserwacji. Zbieramy dane, oglądamy dobowy i tygodniowy rytm maszyny, dopiero potem ustawiamy progi. Zwykle wychodzi z tego kilka rzeczy, o których nikt nie wiedział: nocne zadanie kopii kończące się nad ranem, aplikacja restartująca się w każdą niedzielę, raport księgowy obciążający bazę pierwszego dnia miesiąca.
Co sprawdzamy inaczej na Windows Server, a co na Linuksie
Na Windows Server patrzymy na dziennik zdarzeń systemowych i aplikacyjnych, stan usług, kolejki wydruku tam, gdzie mają znaczenie, replikację katalogu i czas systemowy, bo rozjechany zegar wywraca uwierzytelnianie w całej domenie. Osobno pilnujemy zadań aktualizacji, żeby restart po poprawkach nie wypadł w środku dnia pracy.
Na Linuksie zbieramy obciążenie średnie, pamięć podręczną, stan usług w systemd, użycie i-węzłów, które potrafią skończyć się przy pozornie wolnym dysku, oraz stan macierzy programowej. Na obu systemach osobno traktujemy bazy danych: MS SQL, PostgreSQL i MySQL mają własne liczniki, a długie zapytanie blokujące resztę nie zostawia śladu w metrykach systemowych.
Co się dzieje, gdy serwer przestaje odpowiadać w nocy
Alert idzie do dyżurnego, a nie do skrzynki ogólnej. Pierwsze pytanie brzmi zawsze tak samo: czy nie odpowiada serwer, czy droga do niego. Sprawdzamy to z dwóch stron, z sieci lokalnej i z zewnątrz, żeby nie budzić nikogo z powodu awarii łącza u operatora.
Jeśli maszyna faktycznie stoi, próbujemy zdalnego dostępu przez interfejs zarządzający, bo on działa nawet przy wyłączonym systemie. Dopiero wtedy zapada decyzja o restarcie albo o wyjeździe na miejsce. Cała ścieżka razem z listą osób do powiadomienia jest ustalona przy wdrożeniu i wpisana do umowy, więc nikt nie improwizuje o trzeciej w nocy.
Ile miejsca zostało i kiedy się skończy
Zapełniony dysk jest najczęstszą przyczyną zatrzymania serwera, jaką widujemy, i jednocześnie najłatwiejszą do przewidzenia. Wystarczy patrzeć na tempo, a nie na stan.
| Sytuacja | Co pokazuje sam procent | Co pokazuje trend |
|---|---|---|
| Serwer plików | zajęte 78 procent, spokojnie | przy tym tempie miejsce skończy się za pięć miesięcy |
| Baza danych po wdrożeniu modułu | zajęte 60 procent, spokojnie | przyrost dziesięciokrotny, dwie doby zapasu |
| Dysk systemowy z logami | zajęte 91 procent, alarm od tygodnia | stabilnie, rotacja działa, alarm do wyciszenia |
| Host wirtualizacji | zajęte 70 procent | migawki maszyn rosnące od miesiąca, nikt ich nie kasuje |
Trzeci wiersz tłumaczy, dlaczego alerty procentowe uczą ludzi ignorowania monitoringu. Serwer, który od roku pracuje na dziewięćdziesięciu procentach i ma stabilną rotację logów, wysyła ostrzeżenie codziennie, aż przestaje być czytany razem z całą resztą.
Czego monitoring serwerów nie powie
Nie powie, czy dane są poprawne, tylko czy usługa działa. Baza może odpowiadać w milisekundach i zwracać wyniki z zeszłego tygodnia, bo integracja przestała wgrywać dane. Takie rzeczy łapie się osobnym sprawdzeniem biznesowym, które piszemy razem z Waszym zespołem, gdy wiadomo, co dokładnie ma być sprawdzane.
Nie zastępuje też kopii zapasowych ani nadzoru nad siecią, przez którą wszystko to jest dostępne. Stan łączy i urządzeń opisuje monitoring sieci, narzędzie, na którym to stoi, to wdrożenie Zabbix, a pełny nadzór nad całą infrastrukturą razem z całodobowym czuwaniem systemu monitorującego to monitoring IT.
Treść sprawdzona i zaktualizowana: 30 lipca 2026
Od telefonu do działającego środowiska, pięć kroków
Nie przejmujemy środowiska w ciemno. Najpierw sprawdzamy, co macie, potem wyceniamy.
- Krok 1 Rozmowa i szybki przegląd tego, co macie i co boli najbardziej.
- Krok 2 Przegląd środowiska. Dostajesz listę ryzyk i kolejność ich naprawiania.
- Krok 3 Oferta z zakresem, czasem reakcji i ceną. Bez ukrytych pozycji.
- Krok 4 Przejęcie środowiska, dokumentacja, dostępy, monitoring.
- Krok 5 Praca bieżąca i przeglądy. Raport co miesiąc.
Pytania, które padają najczęściej
Odpowiedzi na to, o co pytają firmy przed podpisaniem umowy.
Częste pytania klientów na tym etapie:W praktyce nie. Agent Zabbiksa zbiera odczyty raz na minutę i zużywa ułamek procenta zasobów maszyny. Obciążenie potrafi pojawić się przy źle napisanych sprawdzeniach uruchamiających ciężkie zapytania, dlatego takie pomiary planujemy rzadziej i poza godzinami szczytu.
Jedne i drugie, w tym samym widoku. Maszyny w Azure, AWS i u dostawców hostingu obsługujemy tym samym agentem co serwery w Waszej serwerowni, a dane z platformy chmurowej dokładamy tam, gdzie dają coś, czego agent nie widzi, na przykład limity usług.
Przychodzi wtedy, gdy z tempa przyrostu wynika, że miejsce skończy się w ciągu kilku dni, a nie dopiero po przekroczeniu progu procentowego. Serwer, na którym zostało dwadzieścia procent, może mieć przed sobą pół roku albo dwie doby, i to jest cała różnica.
Zależy od umowy. Przy samym monitoringu dostajecie alert z opisem i rekomendacją, a naprawę wykonuje Wasz zespół albo my w rozliczeniu godzinowym. Przy stałej administracji serwerami reagujemy od razu i nie ma osobnego zgłoszenia.
Od jednego, jeśli od tego serwera zależy praca firmy. Pojedyncza maszyna z systemem magazynowym albo bazą danych bez nadzoru to ryzyko wyższe niż dziesięć serwerów testowych. Liczy się rola maszyny, nie ich liczba.
Tak, dostajecie dostęp do dashboardu z metrykami swoich maszyn i do historii zdarzeń. Nie prowadzimy monitoringu, którego wyniki widzi wyłącznie dostawca, bo wtedy nie da się sprawdzić ani stanu środowiska, ani jakości naszej pracy.
Gdzie nas znajdziesz
Pracujemy zdalnie w całym kraju, a w wymienionych miastach także u klienta na miejscu.
Nasze biura, 14 adresów
Umów bezpłatną konsultację
Krótka rozmowa wystarczy, żeby ocenić zakres prac i podać widełki kosztu. Bez zobowiązań.
Inne usługi z katalogu
Zestaw zmienia się codziennie, więc przy kolejnej wizycie zobaczysz inny wycinek katalogu.
Migracja poczty do Microsoft 365
Przenosimy pocztę firmową do Microsoft 365 razem z historią, kalendarzami i skrzynkami współdzielonymi, z przełączeniem poza godzinami pracy. Migracja do dwudziestu skrzynek zaczyna się od 2 900 zł netto. Stara poczta zostaje dostępna do czasu potwierdzenia, że wszystko się przeniosło.
Zobacz usługęKonteneryzacja Docker
Pakujemy aplikację razem z jej zależnościami w kontener, żeby działała tak samo na serwerze testowym i produkcyjnym, a wdrożenie nowej wersji trwało minutę zamiast wieczoru. Dockeryzacja jednej aplikacji zaczyna się od 3 900 zł netto, utrzymanie hosta to 250 zł miesięcznie.
Zobacz usługęLogowanie wieloskładnikowe i kontrola dostępu
Hasło pracownika prędzej czy później wycieknie, i nie stanie się to u Was, tylko w serwisie, w którym użył go drugi raz. Drugi składnik sprawia, że sam wyciek przestaje wystarczać do wejścia. Wdrożenie dla trzydziestu kont kosztuje od 2 900 zł netto jednorazowo.
Zobacz usługę