Dlaczego monitoring serwerów Linux to nie fanaberia, tylko konieczność
Różnica między „ping odpowiada” a realnym monitoringiem
Serwer, który odpowiada na ping, wcale nie musi działać poprawnie. ICMP może przechodzić, podczas gdy aplikacja webowa jest zawieszona, baza danych uduszona przez I/O, a użytkownicy patrzą na kręcące się kółeczko. Monitoring serwerów Linux to coś znacznie więcej niż zwykłe sprawdzanie dostępności hosta.
Prawdziwy monitoring śledzi stan zasobów (CPU, RAM, dysk, sieć), działanie usług (systemd, procesy, porty) oraz stan aplikacji (HTTP 200 vs 500, opóźnienia, kolejki, błędy). Dzięki temu da się wykryć problemy zanim użytkownik zauważy, że coś jest nie tak. Ping jest dobry jako absolutne minimum, ale jako jedyny wskaźnik bywa mniej więcej tak wiarygodny, jak „działa, bo świeci dioda na switchu”.
Różnica jakościowa polega na tym, że kompleksowy monitoring nie tylko mówi „żyje/nie żyje”, lecz opisuje, jak żyje: czy serwer jest obciążony, czy zaczyna brakować pamięci, czy na dysku pojawiają się błędy, czy aplikacja ma rosnący czas odpowiedzi. Taka wiedza przekłada się bezpośrednio na szybszą diagnostykę.
Główne cele monitoringu: dostępność, wydajność, bezpieczeństwo, pojemność
Monitoring serwerów Linux ma kilka bardzo konkretnych celów, które warto świadomie rozdzielić:
Dostępność – czy usługa w ogóle działa i jest osiągalna. Tu wchodzą w grę: testy HTTP, sprawdzanie portów, statusy usług systemd, monitoring procesów.
Wydajność – czy aplikacja działa wystarczająco szybko. Sam fakt, że serwer odpowiada, niewiele znaczy, jeśli czas odpowiedzi wynosi kilka sekund. Tu istotne są: CPU, RAM, I/O, metryki aplikacyjne, latency sieci.
Bezpieczeństwo – monitoring może wychwycić nietypowe wzorce: gwałtowny wzrost ruchu, masowe logowania nieudane, dziwne procesy, pełzającą saturację dysku przez logi. To nie zastępuje SIEM, ale jest mocną pierwszą linią.
Planowanie pojemności (capacity planning) – metryki historyczne pozwalają przewidzieć, kiedy skończy się miejsce na dysku, kiedy CPU będzie stale na granicy, kiedy trzeba dodać RAM albo kolejny węzeł klastra.
Bez monitoringu działasz na wyczucie: „ostatnio było wolno, może dorzućmy RAM”. Z monitoringiem widzisz trend: zużycie pamięci rośnie o X tygodniowo, dysk rośnie o Y miesięcznie, a CPU jest dławione przez iowait. To zupełnie inny poziom podejmowania decyzji.
Koszt braku monitoringu – kilka realnych scenariuszy
Typowe historie „bez monitoringu” mają bardzo podobny scenariusz. Nikt nic nie widzi, aż nagle:
dysk dochodzi do 100% zajętości, baza danych przestaje zapisywać dane, aplikacja sypie błędami, a wszystko dzieje się w piątek wieczorem,
serwer ma drobne błędy dysku od tygodni, ale nikt ich nie zbiera; dopiero przy poważnej awarii okazuje się, że od dawna było widać rosnącą liczbę błędów I/O,
logi aplikacji rosną szybciej niż ktokolwiek zakładał, bo bug generuje tysiące błędów na minutę – bez monitoringu logów i dysków nikt tego nie zauważa, aż do zapełnienia systemu plików,
na serwerze pojawia się malware kopiące kryptowalutę – CPU na 95%, ale „przecież działa”; dopiero monitoring ujawnia nienaturalne obciążenie poza oknem pracy.
W każdym z tych przypadków dało się to zobaczyć wcześniej: rosnące użycie dysku, ostrzeżenia SMART, wzrost liczby błędów w logach, nietypowe użycie CPU. Monitoring nie gwarantuje, że awarie się nie wydarzą, ale bardzo często przesuwa je z kategorii „niespodziewane” do „zignorowane”. A to już decyzja, nie przypadek.
Monitoring reaktywny i proaktywny – co jest naprawdę obowiązkowe
Reaktywny monitoring to stan, gdy system monitoringu alarmuje dopiero, gdy coś jest już wyraźnie popsute: usługa nie odpowiada, proces nie działa, dysk jest pełny. Proaktywny monitoring stara się wychwycić symptomy zanim dojdzie do pełnej awarii: rosnąca latencja, timeouty, warnings w logach, trend zapełnienia dysku.
Jako absolutne minimum „must have” dla serwera Linux można uznać:
zbieranie logów systemowych i aplikacyjnych z możliwością przeszukiwania.
Do kategorii „nice to have” można wrzucić np. zaawansowane dashboardy capacity planning, metryki biznesowe (rejestracje, koszyki, itp.), tracing rozproszony. Ale już prosty, solidny monitoring zasobów i usług to obowiązkowy element każdej poważniejszej infrastruktury, niezależnie od tego, czy mówimy o jednym VPS-ie, czy o klastra Kubernetes.
Co monitorować w Linuxie: metryki, logi i ślady wykonania
Kluczowe metryki systemowe: CPU, RAM, swap, dysk, sieć
Monitoring serwerów Linux zaczyna się od metryk systemowych. Bez nich trudno zrozumieć, czy problem leży w aplikacji, czy w infrastrukturze. Podstawowy zestaw obejmuje:
CPU – obciążenie (load average), wykorzystanie procentowe, iowait, steal (na VM),
Sieć – transfer (rx/tx), błędy, dropped packets, ilość połączeń, conntrack.
Same wartości nie wystarczą – istotne są trendy. Jednorazowy skok CPU do 90% w czasie backupu nie oznacza nic złego. Ale stale wysokie iowait, rosnące użycie swapu czy stały brak wolnej przestrzeni na dysku to sygnały, że coś jest nie tak z konfiguracją lub pojemnością.
Procesy i usługi: kto zjada zasoby i czy w ogóle żyje
Kiedy już wiadomo, że „serwer jest obciążony”, pojawia się pytanie: przez kogo? Dlatego kolejną warstwą są metryki dotyczące procesów i usług:
zużycie CPU i RAM przez konkretne procesy (np. top N najbardziej obciążających),
status usług systemd: active, failed, crashed, restart count,
czas działania procesów (uptime), liczba restartów,
otwarte pliki i deskryptory (np. liczba otwartych plików przez bazę danych),
nasłuchujące porty (czy usługa rzeczywiście publikuje się tam, gdzie powinna).
Monitoring powinien odpowiadać nie tylko na pytanie „czy nginx działa”, ale też „czy nie wycieka mu pamięć”, „czy nie restartuje się co kilka minut” oraz „czy nie blokuje go coś po stronie dysku lub sieci”. Dzięki temu korelacja problemów jest możliwa bez każdorazowego logowania się SSH i ręcznego grzebania w procesach.
Metryki aplikacyjne: HTTP, bazy danych, kolejki, cache
Same metryki systemowe nie pokażą, że np. połowa zapytań HTTP kończy się 500, bo aplikacja zgłasza wyjątek. Dlatego monitoring aplikacji jest kluczowym elementem pełnego obrazu. Typowe grupy metryk:
Aplikacje HTTP: statusy odpowiedzi (2xx/4xx/5xx), czas odpowiedzi (p95/p99), liczba requestów, liczba aktywnych połączeń, błędy aplikacyjne.
Bazy danych (PostgreSQL, MySQL): liczba połączeń, długie zapytania, blokady, replika w tyle, wielkość buffer cache, liczba deadlocków.
Kolejki (RabbitMQ, Kafka): długość kolejek, czas przetwarzania, liczba consumerów, ilość porzuconych wiadomości.
Cache (Redis, Memcached): hit ratio, wielkość pamięci, evictions, liczba połączeń.
Dopiero połączenie metryk systemowych i aplikacyjnych pozwala stwierdzić np. czy rosnący czas odpowiedzi wynika z tego, że baza jest przeładowana I/O, czy z błędu w kodzie, który generuje zbyt ciężkie zapytania.
Metryki, logi, trace’y – trzy różne perspektywy
Często wrzuca się „monitoring” i „logowanie” do jednego worka, ale to trzy różne źródła informacji:
Metryki – liczbowe, zagregowane dane w czasie (CPU %, liczba requestów, czas odpowiedzi). Idealne do wykresów, trendów i alertów.
Logi – szczegółowe wpisy tekstowe (komunikaty błędów, ostrzeżenia, zdarzenia). Dobre do diagnostyki, gdy wiadomo, kiedy i co się zepsuło.
Trace’y – śledzenie pojedynczych żądań przez wiele usług (distributed tracing). Ujawniają, gdzie dokładnie w rozproszonym systemie ginie czas.
Metryki odpowiadają na pytanie „czy jest problem i mniej więcej kiedy się zaczął”. Logi pomagają odpowiedzieć „co się dokładnie stało”. Trace’y mówią „gdzie w łańcuchu żądania leży problem”. Dobrze zorganizowany monitoring serwerów Linux wykorzystuje wszystkie trzy kategorie, ale metryki są zwykle pierwszą linią obserwacji.
Monitoring „na piechotę”: wbudowane narzędzia Linux
Podstawowy zestaw diagnostyczny: top, vmstat, iostat, free, df, ss, sar
Nawet bez wyszukanych systemów monitoringu Linux oferuje spory zestaw narzędzi do ręcznej diagnozy:
top / htop – bieżące obciążenie CPU, RAM, top procesy.
ss / netstat – połączenia sieciowe, nasłuchujące porty.
sar (z pakietu sysstat) – historyczne dane o CPU, IO, sieci.
Przykład: serwer „muli”. Sprawdzasz top – CPU 20%, RAM niby jest, więc niby OK. Uruchamiasz iostat -x 1 i widzisz, że jeden z dysków ma util 99%, await bardzo wysoki. Od razu wiadomo, że wąskim gardłem jest I/O, a nie CPU. Bez tej wiedzy debug może ciągnąć się długo.
Procesy i usługi: ps, pstree, systemctl, journalctl
Do bardziej szczegółowego podglądu tego, co się dzieje wewnątrz systemu, przydają się:
systemctl status – status usług systemd, logi ostatnich uruchomień.
systemd-analyze blame – które usługi długo się startują.
journalctl – logi systemowe i usług (journald).
Kiedy usługa „coś robi dziwnego”, systemctl status nazwa.service i journalctl -u nazwa.service w trybie live (-f) są absolutną podstawą diagnostyki. Monitoring powinien w jakimś stopniu zautomatyzować ten podgląd, ale znajomość ręcznych narzędzi bardzo się przydaje, gdy coś pójdzie naprawdę źle i wykresy przestaną być dostępne.
Plusy i minusy ręcznego monitoringu
Ręczny monitoring ma jedną dużą zaletę: niczego nie trzeba wdrażać. Narzędzia są dostępne od ręki, działają na każdym serwerze i pozwalają szybko ocenić sytuację. Problem w tym, że:
nie ma historii – jeśli nie uruchomiłeś sar wcześniej, nie zobaczysz trendów,
nie ma alertów – dowiadujesz się o problemie dopiero, gdy ktoś zgłosi,
diagnoza jest reaktywna – logujesz się, dopiero gdy już jest źle,
brak centralnego widoku – przy większej liczbie serwerów robi się chaos.
Ręczne narzędzia są więc świetne jako „śrubokręt diagnostyczny”, ale kiepskie jako docelowy system monitoringu. W praktyce służą do pogłębiania diagnozy po tym, jak system monitoringu podniesie alarm.
Z takiego „gołego” zestawu da się zbudować całkiem sensowny obraz sytuacji: wiesz, czy problem siedzi w CPU, pamięci, dysku czy sieci, potrafisz wskazać konkretny proces i podejrzeć jego logi. Brakuje tylko jednego: żeby ktoś robił to za ciebie 24/7, zapisywał wyniki i krzyczał, gdy zaczyna się dziać coś podejrzanego. I tu właśnie wchodzą na scenę pełnoprawne systemy monitoringu.
Przejście z trybu „SSH + top + journalctl” do zautomatyzowanego zbierania metryk zwykle zaczyna się od małych kroków: najpierw prosty agent na jednym serwerze, potem dołożenie kilku dashboardów, a dopiero później alerty i integracja z narzędziami on-call. Dobrze jest podejść do tematu jak do migracji systemu, a nie jednorazowego „zainstaluję sobie Grafanę i będzie z głowy”. Stabilny monitoring dojrzewa razem z infrastrukturą, a nie powstaje w jedno popołudnie.
Niezależnie od tego, czy kończy się na jednym VPS-ie, czy ląduje przy kilkudziesięciu węzłach w klastrze, fundament zostaje ten sam: wiedza, co mierzyć, jak to interpretować i kiedy włączyć syrenę. Reszta to już kwestia dobrania wygodnych narzędzi i odrobiny dyscypliny w ich utrzymaniu – czyli dokładnie tego samego, co przy każdym innym kawałku produkcyjnej infrastruktury.
Jak typowo wygląda architektura systemu monitoringu
Niezależnie od tego, czy używasz rozwiązań open source, czy komercyjnych, ogólny schemat jest podobny. Monitoring to nie „jeden program”, tylko kilka elementów, które razem składają się na całość:
agenty / eksporterzy na serwerach,
system zbierający i trzymający metryki (time-series database / TSDB),
warstwa wizualizacji (dashboardy),
silnik alertów,
czasem broker / bufor / kolejka pomiędzy nimi.
Różne narzędzia nazywają te klocki inaczej, ale rola jest ta sama: ktoś na serwerze zbiera dane, ktoś je trzyma, ktoś je wyświetla, a ktoś krzyczy, gdy coś się psuje.
Agenty i eksporterzy: oczy systemu monitoringu
Na pojedynczym serwerze najczęściej działa mały proces, który:
zbiera metryki lokalne (CPU, RAM, dyski, sieć, procesy),
czasem metryki aplikacji (np. Nginx, PostgreSQL),
wysyła je do centralnego systemu push albo udostępnia na porcie HTTP, skąd system je scrape’uje (pull).
Przykłady: Node Exporter w Prometheusie, Telegraf w InfluxDB, agent Zabbixa, Datadoga, New Relica itd. Niezależnie od logotypu robią bardzo podobną robotę.
Ważne parametry agentów:
lekkość – agent nie może sam być źródłem problemów z wydajnością,
bezpieczeństwo – dostęp do endpointów z metrykami powinien być ograniczony,
łatwość aktualizacji i konfiguracji – przy większej liczbie serwerów ręczne „grzebanie w confie” szybko się mści.
Pull vs push: kto do kogo dzwoni
Systemy monitoringu różnią się tym, kto inicjuje połączenie:
pull – centralny serwer monitoringu odpyta agentów (np. Prometheus, częściowo Nagios),
push – agenty wypychają dane do serwera (np. Zabbix, Influx + Telegraf w trybie output).
Pull jest wygodny, kiedy masz kontrolę nad siecią (VPN, SDN, własny DC) i możesz spokojnie skonfigurować routingi oraz firewalle. Push bywa prostszy w środowiskach z NAT-ami, dynamicznymi IP i cloudem, gdzie łatwiej jest „wyjść na zewnątrz” niż wpuścić centralny serwer do środka.
W praktyce często ląduje się przy hybrydach: część rzeczy jest w pullu (metryki systemowe), część w pushu (metryki aplikacji z krótkotrwałych jobów, batchy, lambd itp.).
Magazyn metryk: TSDB i retencja
Metryki to szeregi czasowe. Potrzeba więc bazy, która:
dobrze radzi sobie z zapisami typu „dużo małych punktów z wielu źródeł”,
pozwala robić agregacje w locie (średnie, percentyle, sumy),
umożliwia retencję – czyli trzymanie danych szczegółowych krótko, a zagregowanych dłużej.
Do tego służą m.in. Prometheus TSDB, InfluxDB, TimescaleDB, VictoriaMetrics, M3DB i cała reszta towarzystwa. Z zewnątrz użytkownika zwykle bardziej interesuje, czy:
da się prosto przeszukiwać dane (sensowny język zapytań),
obsługuje się to narzędzie w razie awarii (backup, replikacja, sharding),
kosztowo nie odstrzeli budżetu przy rosnącej liczbie metryk.
Typowy schemat retencji:
metryki „co 15 s” – przechowywane przez 7–30 dni,
zagregowane do „co 5 min / 1 h” – przechowywane kilka miesięcy lub lat.
Dzięki temu można zobaczyć, co się działo „co do sekundy” wczoraj, ale też przeanalizować obciążenie sprzed pół roku, nie trzymając absurdalnych ilości danych.
Dashboardy: warstwa dla ludzi
Same metryki w bazie nikomu nie pomagają, jeśli nie da się ich sensownie obejrzeć. Tu wchodzi warstwa wizualizacji – Grafana lub wbudowane UI danego systemu. Tu projektuje się:
dashboardy biznesowe (np. liczba zamówień/min, rejestracje, drop rate w lejku).
Dobry dashboard nie jest zrzutem wszystkiego, co się da zmierzyć, tylko zestawem odpowiedzi na konkretne pytania. Inaczej kończy się tablicą pięćdziesięciu wykresów, na które nikt nie patrzy, bo nie wiadomo, od czego zacząć.
Silnik alertów: cyfrowe „czujniki dymu”
Alerty można definiować albo w samym silniku metryk (Prometheus Alertmanager, Influx Kapacitor), albo w osobnym narzędziu, które czyta dane przez API. Niezależnie od implementacji, potrzebne są:
reguły alertów – warunki typu „CPU > 90% przez 5 minut”,
routing – do kogo wysłać alert (Slack, e-mail, SMS, on-call),
grupowanie – żeby 50 serwerów z tym samym problemem nie wysłało 50 powiadomień osobno,
wyciszenia (silence) – na czas maintenance, rolloutów, awarii upstreamu.
Bez sensownego routingu kończy się nocnym spamem w Slacku i błyskawiczną ślepotą alertową. Cel: mało alertów, ale za to takich, których naprawdę nie da się zignorować.
Przegląd popularnych narzędzi do monitoringu Linuxa
Prometheus + Grafana: standard de facto
Prometheus wyrósł na domyślny wybór wszędzie tam, gdzie są kontenery, Kubernetes i generalnie „nowoczesny” stack. Jego główne cechy:
model pull – Prometheus odpyta eksporterów (HTTP /metrics),
wbudowana TSDB zoptymalizowana pod metryki,
język zapytań PromQL, bardzo elastyczny do agregacji,
Na małej infrastrukturze wystarczy pojedynczy serwer Prometheusa. Przy większej skali dochodzi temat federacji, remote write do zewnętrznej TSDB i poziomego skalowania. Na start zwykle wystarczy „Prometheus + Grafana + Alertmanager na jednym VM-ie” i to już jest skok cywilizacyjny w porównaniu z trybem „top na SSH”.
Zabbix: klasyk infrastrukturalny
Zabbix od lat jest koniem roboczym w wielu firmach, szczególnie tam, gdzie:
infrastruktura jest bardziej tradycyjna (bare metal, VM-ki, routery, switche),
ważny jest monitoring SNMP,
chce się mieć „wszystko w jednym” (metryki, alerty, mapy, auto-discovery urządzeń).
Plusy:
agent potrafi dużo „z pudełka”,
dobry do monitoringu sieci, urządzeń i klasycznych serwerów,
scenariusze zdalnych checków (np. logowanie po SSH, sprawdzanie procesów).
Minusy to trochę cięższa administracja przy większej skali i mniej elastyczny język zapytań do metryk niż w PromQL. Za to osobom z doświadczeniem w „tradycyjnym” monitoringu zwykle łatwiej się w nim odnaleźć.
InfluxDB + Telegraf + Grafana: monitoring z TSDB ogólnego przeznaczenia
InfluxDB to baza szeregów czasowych, którą często łączy się z agentem Telegraf i Grafaną. Zaletą jest uniwersalność:
Telegraf może działać i w trybie push, i w trybie pull (input plugins + output plugins),
Influx nadaje się nie tylko do metryk systemowych, ale też np. IoT, danych biznesowych,
składnia zapytań dość intuicyjna (choć zmieniała się między wersjami).
Taki stack sprawdza się dobrze, gdy monitoring jest jednym z kilku zastosowań Influxa w organizacji. Jeśli celem jest tylko monitoring serwerów Linux, Prometheus zwykle wygrywa prostotą i gotowymi eksporterami.
Narzędzia SaaS: Datadog, New Relic, Grafana Cloud i spółka
Rozwiązania „w chmurze” kuszą tym, że nie trzeba stawiać i utrzymywać własnych serwerów monitoringu. Zwykle instalujesz agenta, podpinasz integracje (Nginx, Postgres, Docker, Kubernetes) i masz wszystko gotowe wraz z predefiniowanymi dashboardami.
Zalety:
brak troski o HA, storage, backup monitoringu,
wbudowane integracje i alerty z sensownymi domyślnymi progami,
dodatkowe funkcje typu APM, profiling, synthetics (testy zewnętrzne).
Wadą może być koszt przy rosnącej liczbie hostów i metryk oraz zależność od zewnętrznego dostawcy. W mniejszych firmach SaaS bywa jednak tańszy niż etat osoby, która ma ogarniać i utrzymywać on-premowy monitoring.
Nagios / Icinga: starzy wyjadacze od checków
Nagios i jego forki (np. Icinga) to narzędzia opierające się na koncepcji checków – skryptów, które zwracają status OK/WARNING/CRITICAL oraz ewentualnie metryki. Bardzo dobrze nadają się do:
sprawdzania dostępności usług (czy port 443 odpowiada, czy HTTP 200 itp.),
weryfikacji konkretnych warunków (np. „czy jest plik backupu z dzisiaj”).
Do masowego zbierania metryk systemowych i ich analizowania w czasie radzą sobie gorzej niż nowsze TSDB, ale nadal świetnie uzupełniają się z Prometheusem czy Zabbixem, zwłaszcza przy specyficznych checkach „biznesowych”.
Praktyczny przykład: prosty monitoring jednego serwera Linux
Założenia i minimalny zakres
Jeden serwer (np. VPS), na którym działa aplikacja webowa (Nginx + backend + baza lokalna lub zewnętrzna). Celem jest:
mieć wgląd w podstawowe metryki systemowe,
śledzić stan HTTP (kod odpowiedzi, czas),
dostawać proste alerty, gdy coś ewidentnie się psuje.
Do tego wystarczy mały stack: Prometheus + Node Exporter + Blackbox Exporter + Grafana + Alertmanager. Można to uruchomić nawet w docker-compose lub na goło.
Po starcie Node Exporter wystawia metryki na porcie (domyślnie 9100) pod adresem /metrics. Dostęp do niego najlepiej ograniczyć firewallem (np. tylko z IP Prometheusa).
Krok 2: prosty Prometheus
Na tym samym serwerze lub innym hostcie instalujemy Prometheusa. Minimalna konfiguracja w prometheus.yml może wyglądać słownikowo tak:
Prometheus co 15 sekund będzie odpytwać Node Exportera i zbierać metryki. Interfejs webowy Prometheusa (domyślnie port 9090) pozwala już na wykonywanie zapytań PromQL i szybkie podglądanie danych.
Krok 3: monitorowanie HTTP przez Blackbox Exporter
Sam fakt działania Nginxa nie oznacza jeszcze, że aplikacja odpowiada poprawnie. Tu przydaje się Blackbox Exporter, który potrafi:
wykonać zapytanie HTTP(s) pod wskazany URL,
zmierzyć czas odpowiedzi, status HTTP, TLS, redirecty,
oddać to wszystko jako metryki dla Prometheusa.
Schemat działania:
Blackbox Exporter udostępnia endpoint /probe.
Prometheus odpytuje ten endpoint z parametrem target=https://twoja-domena.
Blackbox wykonuje realne zapytanie HTTP i zwraca metryki, np. probe_success, probe_duration_seconds, probe_http_status_code.
W konfiguracji Prometheusa dodaje się kolejny scrape_config z modułem HTTP, który przekazuje docelowy URL jako parametr. Z pozoru wygląda to jak „monitoring portu 443”, ale w praktyce jest to już mały test syntetyczny.
Dobrze jest przygotować osobny moduł HTTP w konfiguracji Blackboxa (np. http_2xx) oraz dedykowany job w Prometheusie, który dla każdego monitorowanego URL-a ustawia osobną etykietę. Dzięki temu na wykresach i w alertach widzisz konkretną usługę (np. instance="front-prod"), a nie zagadkowy ciąg host:port. Taki prosty „robot” HTTP często szybciej wykrywa faktyczny problem aplikacji niż monitoring samego systemu.
Krok 4: podstawowe dashboardy w Grafanie
Grafana w tym układzie jest „kokpitem” – to na nią patrzysz, gdy coś zaczyna działać wolniej lub gdy przychodzi powiadomienie. Po podpięciu Prometheusa jako źródła danych można od razu użyć gotowych dashboardów z oficjalnego marketplace’u (np. Node Exporter Full) zamiast rysować wszystko od zera. W praktyce oszczędza to sporo czasu i od razu daje sensowny zestaw wykresów CPU, RAM, dysku i sieci.
Dobrym nawykiem jest zrobienie osobnego, minimalistycznego dashboardu „operacyjnego” z kilkoma kluczowymi panelami: obciążenie CPU, wolna pamięć, I/O wait, wykorzystanie dysków, latency HTTP i procent udanych probe’ów. Taki widok otwierasz podczas incydentu albo gdy „użytkownicy mówią, że muli” i zwykle da się w kilka minut ocenić, czy problem leży po stronie systemu, aplikacji, czy może sieci.
Krok 5: pierwsze alerty w Alertmanagerze
Gdy metryki już się zbierają, przychodzi moment na alerty. Na start wystarczą naprawdę proste reguły, np.:
CPU powyżej 90% przez 5 minut,
wolna pamięć poniżej określonego progu przez kilka minut,
dysk zapełniony powyżej 80–85%,
probe_success == 0 przez 1–2 minuty.
Reguły zapisuje się w plikach *.rules lub *.yml, a Alertmanager dba o to, by powiadomienia nie zalewały skrzynki: grupuje je, stosuje inhibition, wysyła w ustalone miejsca (mail, Slack, PagerDuty itp.). Lepiej zacząć od mniejszej liczby alertów, ale dobrze przemyślanych, niż od 50 reguł, które po tygodniu wszyscy filtrują w inboxie.
Przy pojedynczym serwerze widać też szybko, które progi są za ostre, a które za łagodne. Jeśli alarm o wysokim CPU przychodzi przy każdym nightly backupie i nic złego się nie dzieje – podnosisz próg albo wydłużasz czas trwania warunku. Monitoring działa najlepiej wtedy, gdy operatorzy traktują alerty poważnie, a nie jak „kolejny szum w tle”.
Krok 6: małe usprawnienia po pierwszych tygodniach
Po kilku tygodniach zbierania danych dobrze dorzucić parę drobiazgów, które procentują przy pierwszym poważniejszym incydencie. Przede wszystkim etykiety: dodanie do metryk takich tagów jak env="prod", service="frontend", owner="team-a" ogromnie ułatwia filtrowanie i budowanie sensownych dashboardów. W PromQL i w Grafanie te same zapytania można wtedy wykorzystać w różnych środowiskach, tylko zmieniając wartości etykiet.
Przydaje się też kilka prostych wskaźników „bliskich biznesowi”: np. liczbę requestów na sekundę, odsetek odpowiedzi 5xx albo czas generowania kluczowego endpointu API. Takie wykresy bardzo jasno pokazują, czy problem systemowy rzeczywiście przekłada się na doświadczenie użytkownika, czy tylko „ładnie wygląda na grafie”. W małych projektach to często różnica między paniką a spokojnym „ok, mamy chwilowy spike, ale użytkownicy tego nie widzą”.
Dobrze poukładany monitoring Linuxa zaczyna się od jednego hosta, kilku eksporterów i paru prostych alertów, a dopiero potem rośnie razem z infrastrukturą. Zamiast od razu projektować „idealny system na 5 lat”, lepiej szybko zdobyć pierwszą telemetrię, poobserwować własne wzorce awarii i na tej podstawie dokładać kolejne metryki, checki i automatyzacje.
Źródło: Pexels | Autor: panumas nikhomkhai
Metryki systemowe w praktyce – jak na nie patrzeć bez paniki
CPU: kiedy 100% to problem, a kiedy tylko „pracuje, bo musi”
Wysokie użycie CPU samo w sobie nie jest zbrodnią. Serwer po to istnieje, żeby liczyć. Problem zaczyna się wtedy, gdy:
użytkownicy zgłaszają spowolnienia,
czas odpowiedzi HTTP rośnie,
a wykresy CPU wiszą przy 90–100% przez dłuższy czas.
W metrykach z Node Exportera (albo innych agentów) przydają się zwłaszcza:
node_cpu_seconds_total z podziałem na mode="user", "system", "iowait",
Typowe progi ostrzegawcze dla CPU w prostym systemie alertów mogą wyglądać tak:
WARNING: średnie użycie CPU > 80% przez 10–15 minut,
CRITICAL: średnie użycie CPU > 95% przez 5 minut i jednocześnie rośnie latency HTTP.
Samo 100% CPU przez krótką chwilę (kompresja backupu, nightly batch) nie jest dramatem. Jeżeli jednak load average przez dłuższy czas przekracza liczbę vCPU (np. 4 vCPU i load > 6–7), a przy tym rośnie kolejka procesów oczekujących, to znak, że serwer dostaje więcej zadań, niż jest w stanie ogarnąć.
Pamięć RAM: wolne megabajty vs cache i swappiness
„Linux zjada całą pamięć” – ten cytat żyje wiecznie. W praktyce większość RAM-u u zdrowego serwera jest wykorzystana jako cache i to jest prawidłowe. Większym problemem jest:
node_memory_SwapUsed_bytes – ile swapu już weszło do gry,
liczba OOM-ów (np. z logów kernela lub osobnych exporterów).
Przy prostym monitoringu można trzymać się następujących zasad:
WARNING: MemAvailable < 15–20% RAM przez 10 minut,
CRITICAL: istotny przyrost użycia swapu w krótkim czasie (np. +100–200 MB w kilka minut),
osobny głośny alarm na każde zdarzenie OOM.
Jeżeli na serwerze aplikacyjnym zaczyna pracować swap, często objawia się to skokami opóźnień HTTP i nagłym „muleniem” całego systemu. Wtedy same dokręcanie CPU zwykle nie pomaga – trzeba albo ograniczyć pamięciożerne procesy, albo zwiększyć RAM.
Dyski: miejsce, IOPS i I/O wait
Dyski mają kilka wymiarów problemów: możesz nie mieć miejsca, możesz mieć za mało IOPS, albo po prostu za wolne storage w stosunku do tego, co robi aplikacja. Klasyka gatunku to:
brak miejsca na logi i zderzenie z ENOSPC,
przeciążone I/O (baza danych na HDD w 2026 nadal się zdarza),
niekontrolowany wzrost katalogów typu /var/log czy /tmp.
Podstawowe metryki z Node Exportera:
node_filesystem_avail_bytes – wolne miejsce,
node_disk_read_bytes_total / _write_bytes_total,
node_disk_io_time_seconds_total,
w samym CPU: udział czasu iowait.
Przykładowe progi:
WARNING: wolne miejsce < 20% lub < 10 GB,
CRITICAL: wolne miejsce < 10% lub < 5 GB,
WARNING: iowait > 10–15% CPU przez 10 minut (system „stoi na dysku”).
Przy dyskach szczególnie pomaga prosta ekstrapolacja: w Grafanie można łatwo zrobić wykres „czas do zapełnienia” (na podstawie trendu wzrostu zużycia). Dzięki temu nie ma klasycznego scenariusza „logi rosną od miesięcy, ale dopiero dziś się zapełniło i nikt nie wie czemu”.
Sieć: throughput, błędy i „czy to już DDoS?”
Nie każdy problem z siecią to atak. Czasami to po prostu:
duży zrzut backupu, migracja danych albo klient, który odkrył „nowy feature” API i mocno go polubił. Z metryk sieciowych przy serwerach Linux przydają się:
liczba otwartych połączeń (np. przez exporter od firewalla lub samej aplikacji).
Proste reguły:
WARNING, gdy ruch zbliża się do fizycznego limitu interfejsu (np. 70–80% stałego obciążenia),
CRITICAL przy znacznym wzroście błędów/dropped packetów w krótkim czasie,
osobne alerty aplikacyjne na nagły skok liczby połączeń HTTP/DB.
Sam wysoki throughput bez błędów nie musi być zły. Problem jest wtedy, gdy rośnie ruch, rośnie latency, a do tego pojawiają się błędy po stronie aplikacji albo load balancera. Wtedy wykresy sieciowe pomagają ustalić, czy problem leży po stronie łącza, czy po prostu aplikacja nie wyrabia.
Łączenie metryk: korelacje zamiast pojedynczych strzałów
Największą moc monitoring pokazuje wtedy, gdy zamiast patrzeć na jedną linię, łączysz kilka. Klasyczne kombinacje:
CPU + latency HTTP + liczba requestów – czy wysokie CPU idzie w parze z większym ruchem i spowolnieniami?
RAM + użycie cache + I/O wait – czy braki pamięci powodują „przegrzanie” dysków?
ruch sieci + 5xx z aplikacji – czy nagły skok ruchu powoduje błędy serwera?
W praktyce pomaga jeden widok typu „incident dashboard”, na którym masz zestaw tych kilku korelowanych wykresów na wspólnej osi czasu. Podczas awarii zamiast klikać 10 dashboardów, odpalasz jeden i w ciągu minuty widzisz, w którą stronę kopać.
Monitoring usług i aplikacji – co poza „up/down”
Prosty healthcheck to za mało
Sprawdzenie, czy port 80/443 nasłuchuje, to odpowiednik stwierdzenia, że w budynku świeci się światło. Nadal nie wiesz, czy ktoś w środku pracuje, czy tylko zostawił lampę. Przy aplikacjach webowych przynajmniej trzy poziomy sprawdzeń dają zauważalnie lepszy obraz:
czy proces żyje (systemd, port nasłuchuje),
czy endpoint healthchecka odpowiada (HTTP 200),
czy kluczowe funkcje biznesowe działają poprawnie (np. można zalogować się i pobrać listę zamówień).
Blackbox Exporter załatwia punkt drugi, natomiast trzeci zwykle wymaga już dedykowanych checków – krótkich skryptów lub testów syntetycznych.
Metryki aplikacyjne: co warto wypuścić na zewnątrz
Aplikacja powinna mówić, jak się czuje, zamiast liczyć, że wszystko „jakoś będzie”. Najprostsza forma to endpoint typu /metrics w formacie Prometheusa. Z niego można wystawić np.:
liczbę requestów HTTP z podziałem na kody odpowiedzi,
czas obsługi requestów w postaci histogramów,
liczbę aktywnych workerów, sesji, połączeń do bazy,
wewnętrzne kolejki (długość, czas oczekiwania).
Przykładowo, w aplikacji HTTP metryki mogą wyglądać tak:
Na tej podstawie da się zbudować alerty bliższe biznesowi, np. „czas generowania /api/orders > 2 sekundy dla 5% requestów przez 10 minut”. Ta informacja bywa cenniejsza niż sam wykres CPU.
Monitoring baz danych: nie tylko „czy port 5432 otwarty”
Bazy danych często są sercem systemu, a bywa, że w monitoringu dostają najmniej uwagi. Typowe metryki dla PostgreSQL/MySQL/MariaDB (zależnie od exportera) to:
czas trwania zapytań,
liczba aktywnych połączeń i sesji w stanie idle,
liczba blokad, konflikty blokad, deadlocki,
wielkość buffer cache, hit ratio,
liczba replik i opóźnienie replikacji.
Proste, ale skuteczne alerty:
WARNING: liczba połączeń > 80% maksymalnej wartości,
CRITICAL: opóźnienie replikacji > X sekund/minut, jeśli opierasz się na read-replicach,
CRITICAL: deadlocki pojawiają się częściej niż „rzadko”.
Nawet podstawowy exporter bazy + kilka wykresów potrafi oszczędzić wiele godzin „debugowania w ciemno” podczas incydentów typu „aplikacja nagle bardzo wolno działa, ale CPU serwera jest OK”.
Kolejki, cache, message brokerzy
Systemy oparte na kolejkach (RabbitMQ, Kafka, Redis jako kolejka, SQS i podobne) wymagają osobnego podejścia. Najważniejsze wskaźniki to:
długość kolejki w czasie (czy rośnie, czy maleje),
czas przetwarzania wiadomości,
liczba niedostarczonych / odrzuconych wiadomości,
zajętość pamięci i dysku w brokerze.
Krytyczny sygnał: kolejka rośnie przez dłuższy czas, ale liczba przetworzonych wiadomości na sekundę pozostaje stała lub spada. To klasyczny objaw, że workerów jest za mało, są za wolni albo coś blokuje przetwarzanie. Prosty alert: „długość kolejki > X przez Y minut” w praktyce wykrywa sporo realnych problemów, szczególnie po większych deployach.
Logi vs metryki: co gdzie trzymać
Monitoring to nie tylko metryki numeryczne. Logi są niezbędne, ale ich rola jest inna:
metryki – do szybkiego wykrywania i ogólnego zarysu problemu,
logi – do szczegółowej diagnostyki, kiedy już wiesz, gdzie patrzeć.
Dobrym kompromisem jest podejście:
z logów generujesz metryki agregowane (np. liczba 5xx/min, liczba błędów konkretnego typu),
a same logi trzymasz w ELK / Loki / Graylog lub innym systemie do „kopania szczegółów”.
Przykład z praktyki: aplikacja zaczyna zwracać więcej 500-tek. W metrykach widzisz tylko skok http_5xx_total. Z poziomu alertu przechodzisz do logów z tego samego okresu i w minutę łapiesz konkretny stack trace lub błąd SQL zamiast próbować odtwarzać, co się mogło stać.
Alerty oparte na SLO i błędach biznesowych
Na pewnym etapie sensowniej jest myśleć nie tylko o CPU i RAM-ie, lecz o tym, co realnie boli użytkowników. Pomagają w tym:
SLO (Service Level Objectives) – np. 99.9% requestów musi mieć latency < 300 ms,
błędy biznesowe – np. odsetek nieudanych płatności, problemów z logowaniem.
Do tego przydają się metryki typu RED/USE (Request rate, Errors, Duration / Utilization, Saturation, Errors). Prosty przykład:
mierzymy RPS (requests per second) dla danego serwisu,
liczymy procent odpowiedzi 5xx z ostatnich 5–10 minut,
mierzymy czas odpowiedzi percentylem (p95, p99).
Alert może brzmieć: „Więcej niż 2% requestów kończy się 5xx przez 10 minut lub p95 latency > 1s”. CPU może sobie w tym czasie stać na 40% – użytkownikom i tak jest wszystko jedno, jeśli nie mogą wykonać przelewu.
Małe, ale skuteczne checki syntetyczne
Oprócz Blackboxa można stosunkowo łatwo dorobić małe skrypty (bash, Python, Go), które:
logują się testowym kontem do aplikacji,
wykonują prostą akcję (np. utworzenie zasobu testowego),
sprawdzają odpowiedź pod kątem treści (np. JSON zawiera określone pole),
sprzątają po sobie (usuwają testowe dane).
mierzą czas wykonania całej akcji end‑to‑end (np. od logowania do zobaczenia listy zamówień).
Taki check możesz odpalać z zewnątrz (np. z innego DC czy chmury), żeby złapać też problemy z DNS, TLS, WAF-em czy load balancerem. To często jedyny sposób, by wychwycić sytuację, w której wszystkie „wewnętrzne” metryki krzyczą, że jest idealnie, a użytkownik widzi tylko kręcące się kółko.
Przy projektowaniu testów syntetycznych dobrze trzymać je maksymalnie prosto: jeden skrypt = jeden konkretny scenariusz biznesowy. Łatwiej to utrzymać, przejrzeć log z błędu i powiązać z alertem. Zbyt skomplikowane „super‑testy”, które robią wszystko naraz (logowanie, zakupy, płatność, generowanie PDF-ów i wysyłkę maila), psują się non stop i po kilku miesiącach nikt już nie pamięta, co właściwie miały sprawdzać.
Przydaje się też wersjonowanie i testowanie samych checków. Skrypt healthchecka to też kod – warto wrzucić go do repo, mieć review, pipeline, a zmianę w scenariuszu biznesowym wdrażać razem z aplikacją. Unikasz wtedy klasyki: alert leci o „błędzie logowania”, a w rzeczywistości tylko zmienił się tekst przycisku z „Zaloguj” na „Wejdź”.
Dobrze ułożony monitoring serwerów Linux, usług i aplikacji przestaje być zestawem losowych wykresów i piskliwych alertów, a staje się normalnym narzędziem pracy – takim samym jak git czy ssh. Wtedy przy kolejnej awarii zamiast „gaszenia pożaru wiadrem” masz szansę zachować spokój, spojrzeć na metryki, logi i checki syntetyczne, po czym w kilka minut dojść do przyczyny, zamiast przez godzinę zgadywać, gdzie tym razem wszystko się rozjechało.
Monitoring w środowiskach wieloserwerowych i klastrach
Na jednym serwerze wszystko jest dość proste: kilka exporterów, dashboard, parę alertów. Schody zaczynają się, gdy masz kilkanaście–kilkadziesiąt maszyn, kilka środowisk (dev/stage/prod) i parę klastrów Kubernetesa po drodze. Wtedy monitoring musi być traktowany jak normalny komponent infrastruktury, a nie „doklejka na koniec”.
Grupowanie i tagowanie serwerów
Przy większej liczbie hostów kluczowe staje się sensowne oznaczanie ich w metrykach. Zamiast 100 anonimowych nazw hostów w grafanie lepiej mieć zestaw etykiet, które pozwalają jednym kliknięciem odfiltrować:
środowisko: env="dev|stage|prod",
rolę: role="web|db|queue|cache",
region/DC: region="eu-west|eu-central|onprem",
zespół właścicielski: team="payments|search|core".
Te same etykiety przydają się potem w alertach i dashboardach. Zamiast definiować 30 razy ten sam alert „CPU > 90%”, konfigurujesz go raz z warunkiem typu: „dla wszystkich hostów z env="prod" i role!="batch"”.
Federacja i sharding Prometheusa
Jeden Prometheus zbierający metryki z setek maszyn szybko zacznie się pocić. Typowy kierunek to:
wiele instancji „lokalnych” (per DC/region/klaster) scrape’ujących konkretne hosty,
jedna lub kilka instancji „federacyjnych”, które zbierają tylko zagregowane metryki (np. job="federate" z prefiltracją lub recording rules na niższym poziomie).
Na poziomie lokalnych Prometheusów trzymasz szczegół (metryki per pod, per instancja). Wyżej – tylko to, co potrzebne do ogólnego widoku i alertów globalnych („czy połowa EU właśnie nie wstała lewą nogą”). Przy awarii DC monitoring reszty świata dalej działa, bo nie zależy od jednej centralnej instancji.
Monitoring w Kubernetesie i środowiskach kontenerowych
W klastrach kube klasyczne patrzenie na pojedyncze hosty przestaje mieć sens. Bardziej interesują cię:
metryki per pod / deployment / namespace,
statusy Ready, restarty kontenerów,
użycie zasobów na poziomie requestów/limitów, a nie tylko „gołego” CPU hosta.
Typowy zestaw to kube-state-metrics + node_exporter + cAdvisor (lub metryki wbudowane w kubelet). Dobrą praktyką jest trzymanie etykiet app, component, team i konsekwentne używanie ich w dashboardach. Zamiast listy stu podów dostajesz widok „płatności”, „wyszukiwarka”, „CRM”, każdy z osobnym health widgetem.
Przy kontenerach szczególnie przydatne są alerty typu:
„liczba restartów kontenera > N w ciągu ostatnich M minut”,
„pod w stanie Pending dłużej niż X minut” (np. brakuje zasobów lub node’ów),
„użycie CPU > 90% limitu przez dłuższy czas” – bo limit to realne „szkło sufitowe”, a nie tylko sugestia.
Organizacja alertów – od chaosu do sensownego on-call
Sam fakt, że system umie wysłać powiadomienie, nic nie znaczy. Liczy się to, czy ktoś na to zareaguje i nie będzie miał ochoty wyrzucić telefonu przez okno po trzecim nieistotnym alercie o 3:00.
WARNING – do ogarnięcia w godzinach pracy lub przy najbliższym „okienku”,
INFO – raczej sygnał do przeglądu/dokumentacji niż do czegokolwiek na już.
Jeśli wszystko jest CRITICAL, to nic nie jest CRITICAL. Alert o tym, że dysk ma 70% zajętości, nie powinien konkurować z informacją, że cała produkcja stoi. Ten pierwszy niech leci na Slacka, drugi niech robi hałas.
Redukcja szumu – mniej alertów, ale sensowniejszych
„Alert fatigue” to realny problem. Kilka prostych trików bardzo poprawia sytuację:
de-duplikacja – Alertmanager (lub inny system) powinien łączyć podobne alerty w jeden „incident” zamiast wysyłać 50 wiadomości z rzędu,
inhibicja – jeśli istnieje alert „Brak połączenia z bazą”, to nie ma sensu dostawać równocześnie kilkunastu alertów z usług zależnych typu „błąd w zapytaniu SQL: connection refused”,
histereza – reagowanie na trend, a nie pierwszy skok. Lepsze jest „CPU > 90% przez 10 minut” niż „CPU > 90% w jednej 15-sekundowej próbce”.
Dobrze jest też raz na jakiś czas zrobić „przegląd alertów”, czyli przejrzeć, które w ostatnich miesiącach były ignorowane, wyciszane lub zawsze okazywały się fałszywym alarmem – i po prostu je poprawić albo wyrzucić. Monitoring ma pomagać, nie być pasywną agresją w formie notyfikacji.
Runbooki i kontekst przy alercie
Alert bez kontekstu to tylko krzyk. W jego treści powinno się znaleźć nie tylko „cpu_usage > 90%”, ale też:
krótki opis co to znaczy (np. „host web-03 ma bardzo wysokie użycie CPU, aplikacja może odpowiadać wolniej”),
link do dashboardu z odpowiednim filtrem,
link do prostego runbooka typu „sprawdź A, B, C”,
kontakt do zespołu właścicielskiego (jeśli są różne „strefy własności”).
Prosty przykład runbooka przy alercie „Połączenia do PostgreSQL > 80% limitu”: sprawdź liczbę aktywnych sesji, posortuj po czasie trwania, zerknij, czy nie ma jednego problematycznego zapytania w logach, rozważ zwiększenie puli w aplikacji lub limitu w bazie. Dla kogoś świeżego w zespole to bezcenne, nawet jeśli weteran zrobiłby to „z głowy”.
Bezpieczeństwo i niezawodność samego systemu monitoringu
Paradoks: monitoring ma dbać o resztę, a bardzo często jest jedną z najmniej chronionych i najmniej HA części infrastruktury. Do czasu pierwszej większej awarii, oczywiście.
Dostęp i uprawnienia
Prometheus, Grafana, Loki, Alertmanager – wszystko to jest często wystawiane „na pałę” w wewnętrznej sieci, bez autoryzacji, bo „przecież to tylko monitoring”. Kilka prostych zasad mocno poprawia sytuację:
logowanie z SSO / LDAP / OIDC zamiast jednego wspólnego hasła typu admin/admin,
role: read-only dla większości użytkowników, modyfikacje dashboardów i alertów tylko dla uprawnionych,
brak możliwości wpisywania dowolnych zapytań „na zewnątrz” (np. do baz prod) z poziomu narzędzi monitoringu.
Monitoring z racji swojej natury widzi dużo: IP-ki, nazwy hostów, niekiedy nawet fragmenty payloadów w logach. To kopalnia wiedzy dla intruza. Lepiej nie pomagać za bardzo.
Odporność na awarie – monitoring nie może padać pierwszy
Sam system monitoringu powinien być traktowany jak krytyczna usługa:
replikacja instancji (np. Prometheus w trybie HA, podwójna Grafana),
trzymanie danych na niezależnym storage (RAID, replikacja, snapshoty),
oddzielne backupy konfiguracji (alerty, dashboardy, reguły nagrywania).
Jeśli cała infrastruktura logów i metryk stoi w jednej chmurze/regionie, łatwo zakończyć z sytuacją: „wiemy, że było źle, ale monitoring też padł, więc nie wiemy jak źle”. Czasem wystarczy drugorzędowa instancja Grafany i kopia Prometheusa w innym DC, choćby mniej wydajna, tylko do „odgrania” sytuacji po fakcie.
Bezpieczne zbieranie logów i metryk
Agentów monitoringu i logowania nie uruchamia się zazwyczaj z wielkimi uprawnieniami, ale warto unikać pokusy:
skriptów exporterów jako root bez powodu,
dostępu z exporterów DB do pełnego superuser w bazie – często wystarczy rola tylko do odczytu widoków systemowych,
wysyłania logów w formie „raw” z danymi wrażliwymi (np. numery kart, pełne dane osobowe).
Jeśli logi mogą zawierać wrażliwe dane, dobrze mieć mechanizm maskowania (w agentach lub po stronie log collectora). Z metrykami jest prościej, ale i tam można przesadzić z labelami – im więcej „identyfikatorów użytkownika” w metrykach, tym większy potencjalny problem compliance.
Budowanie kultury pracy z monitoringiem
Monitoring to nie tylko serwery i konfiguracja, ale też nawyki ludzi. Da się mieć najpiękniejsze dashboardy, których nikt nie ogląda, i alerty, których nikt nie rozumie.
Dashboardy dla ludzi, nie dla maszyn
Kilka prostych zasad przy projektowaniu dashboardów robi ogromną różnicę:
jeden dashboard = jedno główne pytanie (np. „czy aplikacja X działa poprawnie?”),
na górze stan ogólny (SLO, błędy, latency, RPS), niżej szczegóły (CPU, RAM, DB, kolejki),
maksymalnie mało „ozdób” – bez gradientów, dziesięciu kolorów i zegarków analogowych CPU, które fajnie wyglądają na TV, ale nic nie mówią,
Dobry test: czy osoba, która pierwszy raz widzi dashboard, jest w stanie w 30 sekund powiedzieć, czy system jest zdrowy. Jeśli nie, to coś poszło nie tak.
Retrospekcje po incydentach z wykorzystaniem metryk i logów
Po większym incydencie warto przejść przez zapisane metryki i logi z okresu awarii. Nie tylko pod kątem tego, co się stało, ale też:
czy mieliśmy metrykę, która sygnalizowała problem wcześniej,
czy istniał alert, który powinien był zareagować, ale był źle ustawiony,
czy dashboardy pomagały, czy wprowadzały w błąd.
Z takich retrospekcji wychodzą bardzo konkretne działania: dodanie nowego checka syntetycznego, podniesienie/obniżenie progów, dodanie nowego wykresu „korelacyjnego” (np. błędy aplikacji vs opóźnienie bazy). Po kilku takich iteracjach monitoring naprawdę zaczyna „rozumieć” twoją infrastrukturę.
Monitoring jako część procesu deweloperskiego
Nowa usługa bez metryk i alertów to prośba o nocny telefon po pierwszym większym deployu. Dobrze jest ustalić prostą zasadę: „feature gotowy” oznacza także:
przynajmniej podstawowe metryki RED/USE dla nowej usługi,
podstawowe alerty (np. błędy 5xx, brak ruchu, wzrost latency),
aktualizację dashboardów, jeśli dotyczy kluczowego komponentu.
Do tego dochodzi CI/CD: testy jednostkowe i integracyjne mogą również sprawdzać, czy endpoint /metrics istnieje, czy metryki są poprawnie nazwane, czy exporter działa. Brzmi nudno, ale oszczędza masę drobnych „zdziwień” po wdrożeniu.
Automatyzacja i infrastruktura jako kod w monitoringu
Ręczne klikanie dashboardów, reguł alertów i konfiguracji Prometheusa kończy się tym, że po pół roku nikt nie wie, co gdzie jest ustawione i dlaczego. Monitoring bardzo dobrze poddaje się podejściu „infrastructure as code”.
Konfiguracja Prometheusa i Alertmanagera w repozytorium
Pliki prometheus.yml, reguły nagrywania, definicje alertów – wszystko to można (i warto) trzymać w Git. W połączeniu z pipeline’ami CI/CD dostajesz:
review zmian (ktoś zobaczy, że nowy alert jest zbyt czuły, zanim trafi na produkcję),
historię – kiedy, kto, dlaczego zmienił próg z 80% na 95%,
możliwość odtworzenia konfiguracji na innym środowisku (stage/preprod) 1:1.
Podobnie z Grafaną – zamiast „dashboardów klikalnych”, które giną przy pierwszym poważniejszym rebuildu instancji, lepiej generować je jako JSON/yaml i trzymać w repo, importować przy starcie kontenera lub poprzez API.
Automatyczne odkrywanie serwerów i usług
Ręczne dopisywanie hostów do targets w Prometheusie ma sens tylko w najmniejszych instalacjach. Dalej warto użyć service discovery:
integracja z Consul / etcd / Eureka,
service discovery wbudowany w Kubernetesa (serwisy, endpointy),
odczyt z chmury (AWS EC2 SD, Azure, GCE itp.).
odczyt z inwentarza CMDB / Ansible / Terraform state – jeśli infrastruktura już jest opisana jako kod.
Dzięki temu nowy serwer czy usługa pojawia się w monitoringu automatycznie: dostaje metryki, trafia na właściwe dashboardy, łapie się pod odpowiednie alerty. Mniej kopii‑wklejek, mniej „zapomnianych” hostów, które żyją sobie poza radarem aż do pierwszej poważniejszej awarii.
Monitoring jako część szablonów infrastruktury
Jeżeli używasz Terraform, Ansible, Helm chartów czy innego narzędzia do standaryzacji, monitoring można wpleść w szablony. Nowa aplikacja dostaje od razu:
sidecara/exporter z poprawnie skonfigurowanym endpointem,
tagi/labelki ułatwiające filtrowanie w Grafanie i w regułach alertów,
podstawowy zestaw dashboardów generowany z jednego „wzorca”.
Deweloper nie musi pamiętać o wszystkich krokach, bo są zaszyte w infrastrukturze. Zespół SRE nie goni każdego projektu z osobna, tylko rozwija wspólne moduły – jedna poprawka w module Helm/Terraform i nagle wszystkie nowe usługi mają już poprawioną konfigurację exporterów.
Testowanie i walidacja konfiguracji monitoringu
Reguły PromQL, wyrażenia w Alertmanagerze czy JSON‑y Grafany da się testować przed wdrożeniem na produkcję. Najprostszy wariant to osobna instancja testowa, ale da się pójść krok dalej:
lintowanie reguł Prometheusa (np. promtool, checki w CI),
symulacje alertów na podstawie zarchiwizowanych metryk,
testy „smoke” w pipeline: czy po starcie Prometheus w ogóle akceptuje nową konfigurację.
To zabiera trochę czasu przy pierwszym podejściu, za to ratuje przed klasyką gatunku: „wrzuciliśmy nowy zestaw alertów, a Prometheus od dwóch godzin stoi, bo w jednym pliku brakuje nawiasu”. Monitoring, który jest testowany jak kod, zachowuje się przewidywalnie jak kod, a nie jak magiczne pudełko w rogu serwerowni.
Standaryzacja metryk i etykiet
Automatyzacja ma sens tylko wtedy, gdy jest do czego ją przyłożyć. Spójne nazewnictwo metryk i labeli między usługami sprawia, że możesz używać jednego szablonu dashboardu dla wielu komponentów, a jedna reguła alertu obejmuje całe środowisko. Pomaga prosty „style guide” w repo: prefiksy (np. app_, db_), wspólne labelki (service, env, region), zakaz „radosnej twórczości” w rodzaju czasOdpowiedziMs obok latency_seconds.
Przy pierwszym projekcie wydaje się to przesadą, ale przy dziesiątym nagle okazuje się, że można dodać globalny alert „rate(app_http_requests_total{status=~"5.."}[5m]) > N” i z głowy – bez kopiowania tej samej reguły do dwudziestu różnych plików z drobnymi różnicami w nazwach.
Dobrze zrobiony monitoring staje się z czasem czymś w rodzaju dodatkowego zmysłu dla zespołu: nie tylko pokazuje, że „coś dymi”, ale też podpowiada, gdzie zajrzeć i czego dotknąć pierwszego. Dojście do takiego stanu wymaga trochę rzemiosła, kilku wtop i cierpliwego oswajania ludzi z metrykami, logami i alertami, ale później trudno sobie wyobrazić prowadzenie poważniejszej infrastruktury Linux bez tego zaplecza.
Najczęściej zadawane pytania (FAQ)
Co konkretnie powinienem monitorować na serwerze Linux?
Absolutna podstawa to metryki systemowe: CPU (obciążenie, iowait, steal na VM), RAM (zużycie, cache/buffers), swap (ile jest używane i jak szybko), dyski (zajętość, IOPS, opóźnienia, błędy I/O) oraz sieć (ruch, błędy, porzucone pakiety). Bez tego trudno rozróżnić, czy winna jest aplikacja, czy sama infrastruktura.
Druga warstwa to procesy i usługi: status usług systemd, zużycie zasobów przez konkretne procesy, liczba restartów, otwarte pliki, nasłuchujące porty. Trzeci element to metryki aplikacyjne – kody HTTP, czasy odpowiedzi, statystyki baz danych, kolejek i cache. Dopiero połączenie tych trzech poziomów daje sensowny obraz tego, co się dzieje na serwerze.
Jaka jest różnica między pingiem a „prawdziwym” monitoringiem serwera?
Ping odpowiada na jedno pytanie: „czy host jest w ogóle osiągalny w sieci?”. Nie mówi nic o tym, czy aplikacja działa poprawnie, czy baza danych nie dławi się na I/O, ani czy użytkownicy nie oglądają pustego ekranu przez 10 sekund.
Monitoring systemowy i aplikacyjny sprawdza zasoby, procesy, usługi, porty, kody HTTP, czasy odpowiedzi, błędy w logach i trendy w czasie. Dzięki temu zamiast informacji „żyje/nie żyje” dostajesz odpowiedź „żyje, ale od tygodnia ma zadyszkę na dysku i pamięci”. Ping to latarka z telefonu, monitoring to już porządna czołówka.
Jakie są minimalne elementy monitoringu serwera Linux w małej firmie?
Dla małej firmy, nawet z jednym VPS-em, sensowne minimum to:
podstawowe metryki systemowe (CPU, RAM, swap, dyski, sieć) z historią,
alerty dla krytycznych progów: np. 80–90% dysku, długotrwałe 90–100% CPU, wysoki iowait,
centralne zbieranie logów systemowych i aplikacyjnych z możliwością przeszukiwania.
Nie trzeba od razu stawiać całego „enterprise stacka”. Nawet prosty monitoring, który przyśle maila lub powiadomienie na Slacka, gdy dysk zbliża się do 100% lub usługa przestaje odpowiadać, potrafi uratować weekend.
Jakie metryki są najważniejsze dla wydajności serwera Linux?
Przy problemach z wydajnością zwykle patrzy się najpierw na CPU (użycie i iowait), RAM (czy nie dobija do limitu i nie korzysta agresywnie ze swapu) oraz dyski (opóźnienia, błędy, kolejki I/O). Do tego dochodzi sieć – przepustowość, błędy, porzucone pakiety, liczba połączeń.
Po stronie aplikacji kluczowe są czasy odpowiedzi (p95, p99), liczba zapytań, kody HTTP, w bazie danych – długie zapytania, blokady, liczba połączeń. Jeżeli CPU jest spokojne, RAM ma zapas, a użytkownicy nadal widzą „kręcące się kółeczko”, to zwykle problem siedzi właśnie w metrykach aplikacyjnych lub bazodanowych.
Czym się różni monitoring reaktywny od proaktywnego i co wdrożyć najpierw?
Monitoring reaktywny uderza, gdy już jest źle: usługa padła, dysk pełny, proces nie działa. W praktyce oznacza to alerty typu „HTTP 500”, „brak odpowiedzi na porcie 443”, „dysk 100%”. Ratowanie sytuacji zaczyna się dopiero po awarii.
Monitoring proaktywny wychwytuje symptomy: rosnące użycie dysku, wzrost opóźnień, coraz więcej błędów w logach, ostrzeżenia SMART. Wdrożyć trzeba jedno i drugie, ale w kolejności: najpierw twarde alerty „coś już wybuchło”, potem stopniowo dokładane progi ostrzegawcze i analiza trendów. Inaczej mówiąc – najpierw gaśnica, potem czujniki dymu.
Jak monitoring Linuxa pomaga w bezpieczeństwie, skoro to nie jest SIEM?
Monitoring systemowy nie zastąpi SIEM-a, ale jest świetną pierwszą linią obrony. Pozwala zauważyć nietypowe wzorce: nagły skok zużycia CPU (np. koparka krypto), gwałtowny wzrost ruchu na jednym porcie, dziwną liczbę nieudanych logowań, szybkie puchnięcie logów.
Dobrze skonfigurowany monitoring może wysłać alert przy podejrzanych zmianach: np. nagle pojawia się nowy proces z wysokim CPU, dysk zaczyna się szybko zapełniać przez logi błędów, sieć notuje nietypowy ruch w godzinach nocnych. To nie jest pełna analityka bezpieczeństwa, ale często właśnie te sygnały jako pierwsze zdradzają, że coś „nie gra”.
Po co mi metryki historyczne, skoro widzę aktualne obciążenie serwera?
Bieżące metryki mówią, czy teraz jest problem. Historyczne pokazują, czy dzisiejszy „pik” to norma, czy nowa rzeczywistość. Bez historii planowanie pojemności sprowadza się do zgadywania i „dorzućmy trochę RAM-u, może pomoże”.
Dzięki trendom widać np. że dysk rośnie o kilka procent miesięcznie, RAM jest coraz bardziej dociśnięty, a iowait utrzymuje się od tygodni na niepokojącym poziomie. Na tej podstawie można podjąć decyzję: rozbudowa, optymalizacja aplikacji, przeniesienie bazy na osobny serwer. Krótko mówiąc – mniej gaszenia pożarów, więcej planowania z wyprzedzeniem.
Najważniejsze punkty
Sam ping to atrapa monitoringu – serwer może „odpowiadać”, podczas gdy aplikacja wisi, baza się dusi na I/O, a użytkownicy widzą tylko kręcące się kółko.
Sensowny monitoring obejmuje zasoby (CPU, RAM, dysk, sieć), usługi (systemd, procesy, porty) i samą aplikację (HTTP 200/500, opóźnienia, błędy), dzięki czemu pokazuje nie tylko „żyje/nie żyje”, ale też w jakiej kondycji.
Monitoring realizuje cztery główne cele: pilnuje dostępności usług, trzyma w ryzach wydajność, pomaga wyłapać anomalie bezpieczeństwa i dostarcza danych do planowania pojemności.
Brak monitoringu kończy się zwykle tym samym scenariuszem: pełny dysk, niewidoczne od tygodni błędy I/O, logi zalewające system plików albo malware mielące CPU – wszystko „nagle” i zwykle po godzinach.
Proaktywny monitoring (trendy, ostrzeżenia przed progami, analiza logów) przesuwa awarie z kategorii „szok” do „świadomie zignorowane”, co jest już decyzją, a nie pechem.
Absolutne minimum dla serwera Linux to: monitoring dostępności (HTTP/TCP), podstawowe metryki systemowe, alerty na krytyczne progi oraz centralne zbieranie logów z możliwością ich przeszukiwania.
Kluczowe metryki systemowe trzeba oglądać w czasie: pojedynczy skok CPU do 90% w trakcie backupu jest normalny, ale stały wysoki iowait, rosnące użycie swapu czy chronicznie zapchany dysk to już sygnał, że coś poszło nie tak z konfiguracją lub pojemnością.
