Monitoring infrastruktury IT -
co warto monitorować?

„Wszystko działa" - to ulubione zdanie administratora, który nie ma monitoringu. Prawdziwa odpowiedź brzmi zwykle: „Nie wiem, bo nie sprawdzam". Dobry monitoring to różnica między odkryciem awarii o 3 w nocy dzięki alertowi a telefonem od wściekłego klienta o 9 rano.

Co monitorować - lista kontrolna

Dobry monitoring nie zatrzymuje się na CPU i RAM. To wielowarstwowe pokrycie, od sprzętu przez system operacyjny po poszczególne usługi aplikacyjne.

1. Zasoby systemowe serwerów

2. Dostępność usług (nie tylko ping)

Ping mówi tylko, że serwer jest włączony. Nie mówi, czy strona www się ładuje, czy baza danych odpowiada, ani czy aplikacja zwraca poprawne dane. Dlatego monitoring usług to osobna, kluczowa warstwa:

• › HTTP/HTTPS - sprawdzenie kodu odpowiedzi (200 OK), czasu odpowiedzi, treści (czy nie ma strony błędu 500)
• › Bazy danych - połączenie TCP + zapytanie testowe (SELECT 1), liczba otwartych połączeń, czas odpowiedzi
• › DNS - rozwiązywanie nazw przez własny resolver, czas odpowiedzi, propagacja zmian
• › SMTP/e-mail - dostępność portu 25/465/587, test połączenia, monitoring kolejki (mailq)
• › SSH - dostępność połączenia do zarządzania, kluczowa usługa dla remote administration
• › Docker/systemd - status kontenerów i serwisów, automatyczny restart i alerty gdy restart się zapętla

3. Certyfikaty SSL - najczęściej ignorowana kategoria

Wygaśnięty certyfikat SSL to awaria, na którą admin się nie przygotował, choć miał 90 dni ostrzeżenia. Monitoring certyfikatów powinien alertować na:

• › 30 dni do wygaśnięcia - ostrzeżenie
• › 14 dni - alert krytyczny
• › Certyfikat już wygasł - alarmowanie natychmiastowe
• › Zmiana odcisku certyfikatu (fingerprint SHA256) - szczególnie ważne: nieoczekiwana zmiana może sygnalizować atak MITM lub nieautoryzowaną podmianę

Zabbix od wersji 6.0 ma wbudowane sprawdzanie certyfikatów SSL (m.in. data wygaśnięcia i odcisk). Prometheus używa blackbox_exporter z modułem tls_connect. Let's Encrypt + certbot robi automatyczne odnawianie, ale to nie zwalnia z monitorowania - certbot może się nie uruchomić, domena może przestać odpowiadać przez chwilową niedostępność, rekord DNS może zniknąć.

4. Zadania backupu - czy faktycznie działają?

Monitoring, który pomija weryfikację backupów, to niekompletny monitoring. Należy monitorować:

• › Status ostatniego backupu - sukces/błąd, czas zakończenia, rozmiar kopii
• › Brak backupu przez X godzin - jeśli backup nie uruchomił się planowo
• › Miejsce na storage backupów - zapełnienie storage backupów blokuje nowe kopie
• › Weryfikacja integralności - Proxmox Backup Server robi to automatycznie; inne narzędzia wymagają osobnego testu

5. Sieć i łącza

• › Wykorzystanie interfejsów - alert przy > 80% przepustowości przez dłuższy czas
• › Błędy i porzucone pakiety - ifconfig/ethtool errors = hardware lub konfiguracja
• › Latencja i jitter - szczególnie krytyczne dla VoIP i aplikacji real-time
• › Dostępność bram i routerów - monitoring MikroTik/przełączników przez SNMP lub API

6. Sprzęt i środowisko fizyczne

• › Temperatura CPU i obudowy - alert przy > 75°C CPU, > 35°C w serwerowni
• › Status dysków (SMART) - Reallocated Sectors Count, Pending Sectors, wynik overall
• › Status RAID - degradowany lub rebuilding RAID wymaga natychmiastowej reakcji
• › UPS - stan baterii, tryb pracy (on battery), przewidywany czas podtrzymania

Narzędzia monitoringu - które wybrać?

Dla firm 20-150 pracowników z klasyczną infrastrukturą (serwery Linux, Proxmox, MikroTik) najczęściej polecamy Zabbix - gotowe szablony, kompleksowe pokrycie i sprawdzona baza integracji. Uptime Kuma sprawdza się jako lekkie uzupełnienie do monitorowania zewnętrznej dostępności usług.

Ile alertów to za dużo?

Monitoring generujący 200 alertów dziennie jest bezużyteczny. Zjawisko „alert fatigue" sprawia, że administratorzy zaczynają ignorować powiadomienia - co jest gorsze niż brak monitoringu, bo daje fałszywe poczucie bezpieczeństwa. Kilka zasad:

• › Alert powinien wymagać działania - jeśli wiesz, że możesz go zignorować, wyłącz go lub zmień próg
• › Stosuj progi z histerezie - alert przy > 85%, cofnięcie przy < 75% (nie flipping przy 84/86%)
• › Alerty krytyczne (P1/P2) przez SMS i telefon, pozostałe przez e-mail lub ticketing
• › Regularne przeglądy alertów - raz na kwartał usuń lub popraw alerty, które były fałszywe pozytywne

FAQ - monitoring infrastruktury IT

Podsumowanie

Monitoring infrastruktury IT to więcej niż sprawdzanie czy serwer odpowiada na ping. Pełne pokrycie obejmuje zasoby systemowe, dostępność usług aplikacyjnych, certyfikaty SSL, zadania backupu, parametry sieciowe i stan sprzętu fizycznego. Każda z tych warstw może być źródłem awarii, którą dobry monitoring wykryje z wyprzedzeniem. Dobry monitoring to też fundament skutecznej administracji serwerów Linux w firmie.

Najlepszy monitoring to taki, który alertuje rzadko - ale kiedy już alertuje, wymaga natychmiastowej reakcji. Budowanie go to proces iteracyjny: zaczynasz od podstaw, dodajesz warstwy i regularnie czyścisz to, co generuje szum. Przegląd i czyszczenie alertów raz na kwartał powinien stać się stałym elementem dobrej praktyki IT.