Jak monitorować wydajność serwera Linux: polecenia, metryki i narzędzia

Aby monitorować wydajność serwera Linux, sprawdzaj cztery zasoby: CPU, pamięć, I/O dysku i sieć. Do bieżącej diagnostyki używaj wbudowanych poleceń, takich jak top, vmstat, free, iostat i ss, a do przechowywania historii i wysyłania alertów narzędzia z agentem, takie jak Prometheus z node_exporter, Zabbix lub agent CloudWatch.

Najważniejsze wnioski

• Dla każdego zasobu sprawdzaj wykorzystanie, nasycenie i błędy (metoda USE). Samo wysokie wykorzystanie nie jest problemem; problemem są kolejki i błędy.
• Porównuj średnie obciążenie (load average) z liczbą rdzeni CPU i obserwuj %wa (oczekiwanie na I/O) oraz %st (steal time) na maszynach wirtualnych w chmurze.
• W przypadku pamięci czytaj kolumnę available polecenia free, a nie free. Linux celowo używa wolnej pamięci jako cache.
• Informacje o presji (pressure stall information) w /proc/pressure/ pokazują wprost, jak długo zadania czekają na CPU, pamięć lub I/O.
• Polecenia pokazują stan bieżący. Do trendów i alertów potrzebujesz agenta monitorującego i bazy szeregów czasowych.

Które metryki wydajności Linuksa mają znaczenie?

Zacznij od metody USE inżyniera wydajności Brendana Gregga: dla każdego zasobu sprawdź wykorzystanie (utilisation), nasycenie (saturation) i błędy (errors). Daje Ci to listę kontrolną zamiast zgadywania.

Jak sprawdzić użycie CPU i obciążenie w Linuksie?

Uruchom top (lub htop) i odczytaj wiersz CPU, a następnie porównaj load average z liczbą rdzeni z nproc.

top # widok na żywo; naciśnij 1, aby zobaczyć każdy rdzeń
nproc # liczba rdzeni CPU
uptime # load average z 1, 5 i 15 minut
mpstat -P ALL 1 # użycie na rdzeń co sekundę (pakiet sysstat)

Według strony man proc_loadavg load average liczy zadania, które działają lub czekają na I/O dysku, uśrednione z 1, 5 i 15 minut. Obciążenie 6 na serwerze z 8 rdzeniami jest w porządku. Obciążenie 6 na serwerze z 2 rdzeniami oznacza, że praca czeka w kolejce. Ponieważ obciążenie obejmuje procesy czekające na dysk, wysokie obciążenie przy niskim użyciu CPU zwykle wskazuje na problem z magazynem danych.

W wierszu CPU polecenia top na serwerach w chmurze liczą się dwa pola:

• wa: czas, w którym CPU był bezczynny w oczekiwaniu na I/O. Długotrwale wysokie wartości wskazują na wolne dyski lub magazyn sieciowy.
• st: według strony man top to „czas odebrany tej maszynie wirtualnej przez hypervisor”. Długotrwały steal na maszynie wirtualnej w chmurze oznacza, że host jest zajęty albo instancja z możliwością zrywu (burstable) wyczerpała kredyty CPU.

Jak sprawdzić użycie pamięci w Linuksie?

Uruchom free -h i odczytaj kolumnę available. Strona man free definiuje ją jako oszacowanie pamięci dostępnej dla nowych aplikacji bez użycia swapu, z uwzględnieniem page cache.

free -h # podsumowanie pamięci w czytelnej formie
vmstat 1 5 # kolumny si/so pokazują swap in/out na sekundę
journalctl -k | grep -i "out of memory" # zdarzenia OOM killera

Serwer z małą ilością „wolnej” pamięci, ale dużą ilością „dostępnej” jest zdrowy: Linux wypełnia wolną pamięć RAM cache dysku i zwalnia ją, gdy programy jej potrzebują. Sygnały ostrzegawcze to spadająca przez dni pamięć available (możliwy wyciek), stała aktywność swapu w vmstat i wpisy OOM killera w logu jądra.

Jak sprawdzić wydajność i miejsce na dysku?

Użyj iostat -xz 1 do oceny wydajności I/O, a df do sprawdzenia miejsca i i-węzłów.

iostat -xz 1 # wykorzystanie, kolejka i opóźnienia na urządzenie (sysstat)
df -h # miejsce na dysku na system plików
df -i # użycie i-węzłów: wiele małych plików może je wyczerpać w pierwszej kolejności
du -sh /var/log/* | sort -h # sprawdź, co zajmuje miejsce

W iostat obserwuj r_await i w_await (średni czas w milisekundach na żądanie) oraz aqu-sz (długość kolejki). Strona man iostat zaznacza, że w przypadku urządzeń obsługujących żądania równolegle, takich jak macierze RAID i nowoczesne dyski SSD, %util nie odzwierciedla granic ich wydajności. Lepszymi oznakami nasycenia są rosnące opóźnienia i długość kolejki.

Jak monitorować wydajność sieci?

sar -n DEV 1 # przepustowość na interfejs
sar -n TCP,ETCP 1 # połączenia TCP i retransmisje
ss -s # podsumowanie gniazd
ip -s link # błędy i odrzucone pakiety na interfejs

Rosnące retransmisje, odrzucone pakiety lub błędy interfejsu wskazują na problemy z siecią, nawet jeśli przepustowość wygląda normalnie. Na maszynach wirtualnych w chmurze porównuj przepustowość z limitem sieciowym danego typu instancji.

Czym są informacje o presji (PSI)?

PSI to funkcja jądra, która raportuje, jak długo zadania czekają na CPU, pamięć lub I/O. Dokumentacja jądra wyjaśnia, że każdy plik w /proc/pressure/ ma wiersz „some” (część czasu, w której co najmniej część zadań jest wstrzymana) oraz, dla pamięci i I/O, wiersz „full” (wszystkie nieczekające zadania wstrzymane jednocześnie, co jądro opisuje jako thrashing).

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

PSI odpowiada wprost na pytanie „czy ten zasób spowalnia pracę?”, co czyni go dobrym sygnałem do alertowania. Jeśli tych plików nie ma, Twoje jądro zostało zbudowane lub uruchomione bez obsługi PSI.

Jakich narzędzi użyć do ciągłego monitorowania?

Polecenia pokazują, co dzieje się teraz. Aby wychwytywać problemy w nocy, widzieć trendy i powiadamiać właściwą osobę, zainstaluj agenta monitorującego, który wysyła metryki do bazy szeregów czasowych.

Jakie alerty ustawić w pierwszej kolejności?

1. Miejsce na dysku i i-węzły powyżej 80–85% w dowolnym systemie plików, z alertem prognozy „zapełni się w ciągu 24 godzin”.
2. Niska dostępna pamięć przez ponad 10 minut lub jakiekolwiek zdarzenie OOM killera.
3. Load average powyżej liczby rdzeni przez ponad 15 minut albo rosnąca presja CPU.
4. Opóźnienie dysku lub presja I/O wyraźnie powyżej normalnego poziomu bazowego serwera.
5. Kontrole usług: port aplikacji odpowiada, a adres URL kontroli stanu zwraca sukces.
6. Kopie zapasowe i wygasanie certyfikatów, które zawodzą po cichu.

Te progi są punktami wyjścia. Dostosuj je do normalnego zachowania każdego serwera, aby alerty pozostawały użyteczne. Nasz przewodnik po monitorowaniu wydajności serwera omawia Windows i ogólne praktyki, a monitorowanie infrastruktury chmurowej obejmuje usługi zarządzane wykraczające poza serwer.

Jak pomaga Opsio

Opsio monitoruje i prowadzi serwery Linux w AWS, Azure i lokalnie w ramach naszych zarządzanych usług IT, w tym reagowania na alerty 24/7, instalacji poprawek i przeglądów pojemności, z użyciem Prometheus i Grafana lub narzędzi natywnych dla chmury. Na przykład platforma AWS, którą zbudowaliśmy dla WorkBuster, działa na instancjach EC2 w grupie autoskalowania, z pulpitami i alarmami CloudWatch na potrzeby codziennych operacji.

Najczęściej zadawane pytania

Jakie jest najlepsze polecenie do sprawdzenia wydajności serwera Linux?

Zacznij od top dla widoku na żywo, potem vmstat 1 dla trendów CPU, pamięci i swapu oraz iostat -xz 1 dla dysków. Razem pokazują większość wąskich gardeł w ciągu minuty.

Jaki load average jest dobry dla serwera Linux?

Zależy od liczby rdzeni CPU. Load average równy liczbie rdzeni lub niższy zwykle oznacza brak kolejkowania. Długotrwałe obciążenie powyżej liczby rdzeni oznacza, że zadania czekają na CPU lub dysk.

Dlaczego Linux pokazuje prawie zerową ilość wolnej pamięci?

Linux używa niewykorzystanej pamięci RAM jako cache dysku i oddaje ją, gdy aplikacje jej potrzebują. Sprawdź zamiast tego kolumnę available w free -h; to pamięć faktycznie dostępna dla nowej pracy.

Jak sprawdzić, który proces zużywa najwięcej CPU lub pamięci?

W top naciśnij P, aby posortować według CPU, i M, aby posortować według pamięci. W skrypcie użyj ps aux --sort=-%cpu | head lub ps aux --sort=-%mem | head.

Jak monitorować serwer Linux zdalnie?

Zainstaluj agenta, takiego jak node_exporter, agent Zabbix lub agent CloudWatch, i wysyłaj metryki do centralnego serwera lub usługi chmurowej. Dzięki temu masz historię, pulpity i alerty bez logowania się na każdą maszynę.