sar i sysstat: długoterminowe monitorowanie serwerów z systemem Linux

sar sysstat dostarcza mi historyczne dane dotyczące serwerów z systemem Linux, dzięki którym mogę dokładnie śledzić w czasie wzorce obciążenia, wąskie gardła i nietypowe zachowania. W ten sposób analizuję z perspektywy czasu wykorzystanie procesora, pamięci RAM, operacji wejścia/wyjścia oraz sieci i wykrywam powtarzające się szczyty obciążenia, które zwykłe narzędzie działające w czasie rzeczywistym łatwo przeoczy.

Punkty centralne

Poniższe kluczowe tezy podsumuję w sposób zwięzły i jasny.

• Historia Zamiast pojedynczego pomiaru: regularne rejestrowanie pozwala dostrzec wzorce obciążenia.
• Połączenie z gromadzenia i analizy: sysstat gromadzi dane, a sar je przetwarza.
• Szerokość wskaźniki: procesor, pamięć RAM, obszar wymiany, operacje wejścia/wyjścia na dysku, sieć i inne.
• Diagnoza przyczyny: precyzyjne dostosowanie przedziałów czasowych i ich porównanie.
• Planowanie z uwzględnieniem trendów: realistyczne określanie zdolności produkcyjnych.

Jakie funkcje pełnią sar i sysstat w codziennej pracy?

Używam sar jako narzędzie do raportowania aktywności systemu, które pozwala na odczytanie danych zapisanych przez sysstat. sysstat regularnie gromadzi dane dotyczące procesora, pamięci, operacji wejścia/wyjścia oraz sieci, podczas gdy za pomocą sar mogę wygenerować raporty dotyczące konkretnych przedziałów czasowych. Dzięki temu bez zgadywania rozpoznaję powtarzające się okresy obciążenia spowodowane tworzeniem kopii zapasowych, zadaniami cron lub szczytami ruchu sieciowego. W przeciwieństwie do Narzędzia na żywo W przeciwieństwie do poleceń typu „top” czy „htop” nie oceniam tylko chwilowego stanu, lecz uwzględniam również zmiany w czasie. Takie podejście pozwala uniknąć błędnych diagnoz, ponieważ oddziela przyczynę od skutku i dostarcza mi wiarygodnych wskazówek.

Instalacja i aktywacja w popularnych dystrybucjach

Instaluję sysstat Za pomocą menedżera pakietów włącz rejestrowanie i sprawdź timery systemd. W systemach Debian/Ubuntu zazwyczaj wystarczy apt install sysstat oraz rzut oka na /etc/default/sysstata następnie systemctl enable --now sysstat. W systemach RHEL, CentOS i Oracle Linux korzystam z dnf install sysstat i steruj timerami za pomocą systemctl. Następnie pliki dzienne są zazwyczaj zapisywane w folderze /var/log/sa/ o nazwach takich jak sa10 na 10. dnia miesiąca. Sprawdzam poprawność wpisu za pomocą sar bez parametrów lub z sar -u 1 3 w celu przeprowadzenia krótkiej kontroli doraźnej.

Wyjaśnienie najważniejszych poleceń sar

Jeśli chodzi o procesor, używam sar -u oraz, w razie potrzeby, na każdy rdzeń sar -u -P ALLw celu Wskazówki nie da się tego przeoczyć. Pamięć i buforowanie traktuję jako sar -r oraz zamiana z sar -S. Aktywność płyty odczytuję za pomocą sar -d, sieć z sar -n DEV,ETCP,TCP,UDP. Pliki historyczne otwieram za pomocą sar -f /var/log/sa/sa10 oraz ogranicz przedział czasowy za pomocą -s GG:MM -e GG:MM . Aby uzyskać szczegółowe analizy dotyczące czasów oczekiwania, uzupełniam sar o Analiza czasów oczekiwania na operacje wejścia/wyjścia, ponieważ w ten sposób mogę lepiej ocenić kolejki i przepustowość oraz Wąskie gardła dokładnie zidentyfikować.

Jak prawidłowo odczytywać wyniki pomiarów: procesor, pamięć, wejścia/wyjścia, sieć

Analizuję kilka wskaźników, które szybko dają mi wiarygodny obraz sytuacji i które porównuję w czasie. CPU-Bezczynność Wartość bliska 0 oraz wysoki wskaźnik %iowait wskazują na kolejki przy dysku. Wysoki wskaźnik %steal wskazuje na niedobór mocy obliczeniowej procesora w środowisku wirtualnym. W przypadku pamięci RAM zwracam uwagę na wolne strony pamięci, zachowanie pamięci podręcznej stron oraz operacje swap-in/swap-out. W przypadku sieci wskaźniki błędów pakietów, utraty pakietów i retransmisji pomagają rozpoznać ograniczenia przepustowości lub zakłócenia.

Metryki	przełącznik sar	Wartości odbiegające od normy	środek natychmiastowy
CPU	sar -u [-P ALL]	%idle bardzo niski, %iowait wysoki	Sprawdź operacje wejścia/wyjścia, rozdziel wątki, zweryfikuj zapotrzebowanie na moc procesora
Pamięć	sar -r	mało wolnego miejsca, znaczna utrata zawartości pamięci podręcznej stron	Optymalizacja usług, zwiększenie pamięci RAM, ocena buforowania
Zamiana	sar -S	częste zmiany w składzie	Odciąż pamięć roboczą, dostosuj limity
Dysk I/O	sar -d	wysokie wartości await/svctm, kolejka się powiększa	Sprawdź profil wejścia/wyjścia, dostosuj warstwowanie pamięci masowej lub okno przetwarzania wsadowego
Sieć	sar -n DEV,ETCP	Utrata pakietów, błędy, ponowne transmisje	Testowanie MTU/offloadingu, analiza przepustowości i opóźnień

Analiza danych historycznych i przedziałów czasowych

Prawie zawsze pracuję z Okna czasowe, na przykład sar -u -f /var/log/sa/sa10 -s 01:00:00 -e 05:00:00 do zadań wykonywanych w nocy. W ten sposób porównuję identyczne przedziały czasowe w różnych dniach i dostrzegam trendy, a nie pojedyncze przypadki. W celu automatycznej analizy zapisuję dane z sadf -d w formacie CSV i wgrywam je do własnego pulpitu nawigacyjnego. W przypadku nietypowych skoków analizuję sąsiednie przedziały czasowe, aby wykluczyć efekty uboczne. Uważam tę metodę za prostą, ponieważ dostarcza mi szybko przydatnych wskazówek bez konieczności długich przygotowań.

Analiza trendów i planowanie zdolności produkcyjnych

Wykorzystuję zarchiwizowane wartości do Prognozy i dobieram zasoby na podstawie rzeczywistych danych, a nie intuicji. Jeśli obciążenie procesora rośnie z tygodnia na tydzień, planuję dodanie rdzeni lub rezerw częstotliwości taktowania. Jeśli zapotrzebowanie na pamięć operacyjną rośnie z powodu pamięci podręcznej, porównuję korzyści z rozbudową pamięci RAM. Jeśli ścieżka wejścia/wyjścia wykazuje wydłużone czasy oczekiwania, decyduję się na szybszą pamięć masową lub oddzielne okna przetwarzania wsadowego. W celu wizualizacji alternatywnie łączę dane z Grafana i Prometheus i połącz trendy SAR z wskaźnikami z eksporterów.

Przykład z praktyki: serwer WWW z okresowymi szczytami obciążenia

Przedstawię przypadek, w którym strony WordPress każdego wieczoru reagują z opóźnieniem i Użytkownicy Zgłaszaj przerwy. Za pomocą sar -u -s 18:00:00 -e 20:00:00 oraz sar -d Zauważam jednoczesne szczyty obciążenia wejścia/wyjścia podczas tworzenia kopii zapasowych. Równolegle widać sar -n DEV rosnącą przepustowość sieci, co dopełnia obraz obciążenia. Test porównawczy przeprowadzony następnego dnia bez kopii zapasowej potwierdza ten schemat. Przenoszę zadanie, optymalizuję zapytania do bazy danych i wyrównuję pamięć podręczną, dzięki czemu wieczorne szczyty obciążenia znikają, a czasy odpowiedzi znów pozostają stałe.

Wskazówki dotyczące przechowywania danych, rotacji i archiwizacji

Sprawdzam Przechowywanie w /etc/sysconfig/sysstat lub /etc/default/sysstat i dostosowuję okres przechowywania danych w zależności od potrzeb. W przypadku krytycznych hostów zachowuję dane przez 30–90 dni, aby móc wykrywać zjawiska sezonowe. Rozmiar plików pozostaje na rozsądnym poziomie, o ile interwały są sensowne i nie jest aktywna nadmierna częstotliwość rejestrowania co sekundę. Starsze archiwa przenoszę do centralnego katalogu lub umieszczam w prostym systemie długoterminowego przechowywania danych. W ten sposób zapewniam dostępność danych bez obciążania systemu ani spowalniania analizy.

Integracja ze stosami monitorującymi i logami

Używam „sar” jako Surowe dane-dostawcy i łączę to z centralnym monitorowaniem, analizą logów oraz systemem alarmowym. Stos APM lub zestaw narzędzi do analizy logów dostarcza mi zdarzenia, podczas gdy narzędzie sar porządkuje wartości infrastruktury w porządku chronologicznym. W przypadku szczególnie „głośnych” hostów korzystam dodatkowo z pidstat oraz iostat, aby przypisać procesy i ścieżki wejścia/wyjścia. Dodatkowo pomaga mi Rozliczanie procesów, aby precyzyjnie zidentyfikować procesy wymagające dużych zasobów. To połączenie widoku zdarzeń i metryk pozwala uniknąć działania „na ślepo” i znacznie skraca czas potrzebny na wykrywanie błędów.

Precyzyjna regulacja konfiguracji: interwały, sa1/sa2 i timer

Umieściłem Odstępy czasowe rejestracji tak, aby były dostosowane do dynamiki systemu. Standardowo zaleca się interwał minutowy, natomiast w przypadku hostów o dużej zmienności sensowne może być również ustawienie interwału 10–30 sekund. Zbiórka danych odbywa się sa1 (częste pomiary), podsumowanie dnia sa2 (Raporty z dnia). W systemie systemd sprawdzam odpowiednie timery lub usługi i dostosowuję częstotliwość. W systemach Debian/Ubuntu często wyraźnie uruchamiam zbieranie danych za pomocą ENABLED="true" w /etc/default/sysstat. Dokumentuję przedziały czasowe dla każdego środowiska, aby późniejsze porównania były prawidłowe i nikt nie wyciągał błędnych wniosków na podstawie próbek z 5 sekund w porównaniu z danymi z 1 minuty.

Przegląd zaawansowanych opcji sar

Oprócz standardowych przycisków pomagają mi dodatkowe przełączniki do Pełny widok: sar -b przedstawia zagregowaną przepustowość operacji wejścia/wyjścia blokowego, sar -B sposób działania mechanizmu stronicowania jądra oraz sar -W Szczegółowe informacje na temat transakcji swapowych. Z sar -q Widzę kolejkę Runqueue (procesy oczekujące na procesor) oraz zmiany obciążenia. sar -H dostarcza dane z Hugepage, jeśli jest to istotne. W przypadku płyt, w razie potrzeby korzystam z sar -d -p, aby przeglądać partycje osobno. Podchodzę ostrożnie do svctm: W nowoczesnych jądrach wartość ta bywa czasami niewiarygodna lub wynosi 0; wolę więc czekać (opóźnienie od początku do końca) oraz avgqu-sz/aqu-sz (rozmiar kolejki). A jeśli potrzebuję szybkiego ogólnego obrazu sytuacji, to sar -A ogólny zarys, który następnie zawężam.

Jak prawidłowo oceniać maszyny wirtualne i kontenery

Na stronie Wirtualizacja Zwracam szczególną uwagę na wskaźnik %steal: wysokie wartości Steal oznaczają, że hiperwizor pobiera czas procesora z maszyny wirtualnej. Może to łatwo prowadzić do błędnych ocen, jeśli analizuję wyłącznie wskaźnik %idle. Dlatego też koreluję obciążenie procesora, wskaźnik Steal oraz Runqueue (sar -q) razem. W środowiskach kontenerowych rozdzielam perspektywę hosta i obciążenia: narzędzie sar monitoruje hosta, a nie poszczególne kontenery. Jeśli potrzebuję szczegółowych informacji dotyczących poszczególnych usług, uzupełniam to za pomocą pidstat (na proces) oraz uwzględniam limity cgroups. Sprawdzam również skalowanie częstotliwości procesora i stany zasilania (zmiany taktowania), ponieważ mogą one powodować krótkotrwałe opóźnienia, które bez kontekstu mogą wyglądać jak niedobór mocy obliczeniowej procesora.

Odniesienie czasowe: strefy czasowe, czas letni i wiarygodna korelacja

Zwracam uwagę na stała skala czasu, aby porównania były miarodajne. sar domyślnie zapisuje dane w czasie lokalnym; w przypadku klastrów warto stosować jednolitą strefę czasową (często UTC). W okresie zmiany czasu na letni sprawdzam, czy nie ma zduplikowanych lub brakujących przedziałów czasowych, i w razie potrzeby korzystam z wyników polecenia sadf z sygnaturami czasowymi w formacie ISO. W celu korelacji z logami lub zdarzeniami APM dostosowuję strefy czasowe, aby precyzyjnie powiązać szczyty w metrykach ze zdarzeniami (wdrożenia, kopie zapasowe, zadania cron). Precyzyjne odniesienia czasowe znacznie ograniczają nieporozumienia podczas analizy przyczyn incydentów.

Automatyzacja i eksportowanie za pomocą sadf

W celu tworzenia raportów i pulpitów nawigacyjnych eksportuję dane za pomocą sadf. Na co dzień korzystam z sadf -d (CSV) do prostych analiz, alternatywnie sadf -j (JSON) do elastycznych potoków danych. Typowy eksport wygląda następująco: sadf -d /var/log/sa/sa10 -- -u -r -b -n DEV,ETCP -s 18:00 -e 20:00 > sar_abend.csv. W ten sposób generuję plik zawierający wskaźniki dotyczące procesora, pamięci RAM, operacji wejścia/wyjścia blokowego oraz sieci dla okna wieczornego. W skryptach automatycznie porównuję te dane z poszczególnymi dniami tygodnia, obliczam medianę i 95. percentyl oraz zaznaczam wartości odstające. Celowo ograniczam liczbę wskaźników, aby zachować czytelność danych i uniknąć fałszywych alarmów.

Przykład z praktyki: serwer bazy danych z obciążeniem wynikającym z buforowania stron

Serwer MySQL zgłasza sporadyczne opóźnienia w realizacji zapytań. sar -r pokazuje spadek wielkości pamięci podręcznej stron wieczorem, sar -S sporadyczne zamiany. Równolegle rośnie w sar -d die czekać-czas, oraz sar -b wskazuje na zwiększony przepływ operacji zapisu. Korelacja z rotacjami logów i zadaniem ETL wyjaśnia ten wzorzec: duże sekwencyjne fale zapisu wypierają zawartość pamięci podręcznej i powodują, że operacje odczytu z bazy danych trafiają do operacji wejścia/wyjścia. Rozkładam zadania w czasie, umiarkowanie zwiększam pamięć RAM i celowo powiększam bufor bazy danych. W rezultacie wartości await i swap pozostają stabilne, opóźnienia maleją, a pamięć podręczna stron niezawodnie utrzymuje najczęściej używane zestawy danych w pamięci.

Aspekty operacyjne: koszty ogólne, listy urządzeń i filtry

Trzymam Nad głową niewielką, dokonując stosunkowo reprezentatywnego doboru próby. Program Sysstat odczytuje przede wszystkim z /proc i zapisuje w formacie binarnym; przy interwałach co minutę prawie nie odczuwam obciążenia. Na hostach z bardzo dużą liczbą urządzeń lub krótkotrwałymi urządzeniami blokowymi (np. w przypadku migawek) filtruję dane wyjściowe w sposób ukierunkowany i oceniam tylko istotne ścieżki. W przypadku dm-crypt, MD-RAID lub urządzeń wielodrożnych sprawdzam zarówno urządzenie logiczne, jak i – tam, gdzie to możliwe – urządzenie bazowe, aby prawidłowo zidentyfikować wąskie gardła. Dokumentuję przy tym nazwy urządzeń, aby późniejsze porównania nie zakończyły się niepowodzeniem z powodu zmiany nazw ścieżek.

Metodologia: wartości bazowe i dni porównawcze

Dla każdego hosta definiuję jedną Linia bazowa dla każdego przedziału czasowego (np. godz. 01–05 – przetwarzanie wsadowe, godz. 09–18 – praca biurowa, godz. 18–22 – szczyt). Dla każdego przedziału zapisuję typowe wartości mediany i dopuszczalne percentyle (np. CPU-%idle, czekać, avgqu-sz, retransmisje). W przypadku odchyleń najpierw szukam nowych zadań, wdrożeń lub wzorców ruchu – dopiero potem rozważam zwiększenie pojemności. Ta zdyscyplinowana kolejność zapobiega pochopnym decyzjom: często niewielka zmiana planu lub dostosowanie limitów przynosi większe korzyści niż kosztowne rozbudowy sprzętu. sar dostarcza mi w tym celu solidną bazę faktów zebranych na przestrzeni tygodni i miesięcy.

Ograniczenia i przydatne dodatki

Nie uważam tego za substytut Alarmowanie, ponieważ domyślnie nie monitoruje żadnych progów ani nie wysyła powiadomień. Powiadomienia w czasie rzeczywistym powinny być realizowane przez dedykowane systemy, które uwzględniają reguły, eskalacje i przepływy pracy zespołów. Również szczegółowe wskaźniki dotyczące aplikacji, baz danych czy maszyn JVM uwzględniam za pomocą narzędzi do eksportu danych i śledzenia. sar sprawdza się doskonale, gdy chcę porównać zasoby systemowe w ujęciu historycznym i zidentyfikować wąskie gardła w działaniu systemu. Podsumowując, wykorzystuję go celowo tam, gdzie potrzebne są szybkie, powtarzalne odpowiedzi na pytania dotyczące infrastruktury.

Krótkie podsumowanie

Używam sar oraz sysstat, aby na podstawie odczytów stworzyć przejrzystą historię obciążenia serwera. Połączenie regularnego gromadzenia danych i ukierunkowanej analizy przeszłości pozwala ustalić przyczyny, zamiast zgadywać, jakie są objawy. Za pomocą kilku poleceń wykrywam problemy związane z procesorem, pamięcią, operacjami wejścia/wyjścia i siecią oraz określam ich przebieg w czasie. Na tej podstawie podejmuję realistyczne decyzje dotyczące wydajności i identyfikuję nieefektywne procedury, takie jak źle zaplanowane kopie zapasowe. Osoby odpowiedzialne za serwery Linux zyskują dzięki tej metodzie niezawodną orientację i oszczędzają czas podczas analizy, planowania i eksploatacji.