管理

sar と sysstat：Linux サーバーの長期モニタリング

sar sysstat Linuxサーバーの過去のメトリクスを提供してくれるため、負荷の傾向、ボトルネック、異常な動作などを時間軸に沿って明確に追跡できます。これにより、CPU、RAM、I/O、ネットワークを遡って分析し、単なるリアルタイムツールでは見落としがちな繰り返し発生するピークを特定することができます。.

中心点

以下の要点を簡潔かつ明確にまとめます。.

歴史「その場限りの記録」ではなく、定期的な記録によって負荷の傾向が明らかになります。.
コンビネーション 収集と解析：sysstatがデータを収集し、sarが処理を行う。.
幅監視対象の指標：CPU、RAM、スワップ、ディスクI/O、ネットワークなど。.
診断原因の特定：時間枠を的確に調整し、比較する。.
プランニング トレンドを踏まえて：生産能力を現実的に設定する。.

sarとsysstatは、日常的にどのような役割を果たしているのでしょうか？

私はこうしている。サル sysstatが保存したデータを可読形式に変換する「システムアクティビティレポーター」として機能します。sysstatはCPU、メモリ、I/O、ネットワークの値を定期的に収集しますが、私はsarを使って特定の時間帯のレポートをピンポイントで取得しています。これにより、バックアップやcronジョブ、トラフィックのピークによる繰り返し発生する負荷の時間帯を、当て推量することなく把握できます。これとは対照的に、 ライブツール top や htop のように、私はその瞬間の状態だけを評価するのではなく、時間的な推移も考慮に入れます。この視点は、原因と結果を区別し、信頼性の高い手がかりを与えてくれるため、誤った診断を防ぐことができます。.

一般的なディストリビューションでのインストールと有効化

インストールする sysstat パッケージマネージャーを使用して、収集機能を有効にし、systemdタイマーを確認してください。Debian/Ubuntuでは、通常は以下の操作で十分です。 apt install sysstat そして、中を覗いてみると /etc/default/sysstat続いて systemctl enable --now sysstat. RHEL／CentOS／Oracle Linux では、私は以下を使用しています dnf install sysstat そして、以下の方法でタイマーを制御します systemctl. その後、日次ファイルは通常、以下の場所に保存されます。 /var/log/sa/ 次のような名前で sa10 今月の10日分。入力内容を確認します。サル引数なし、または引数あり sar -u 1 3 簡単なその場での確認のために。.

主要なsarコマンドの解説

CPUには以下を使用しています sar -u また、必要に応じてコアごとに sar -u -P ALLのために ヒント 見逃せない。ストレージとキャッシュについては、私は次のように考えている。 sar -r およびスワッピングによる sar -S. プレート活動は次のように読み取ります sar -d, そのネットワークは sar -n DEV,ETCP,TCP,UDP. 過去のファイルは次のように開きます sar -f /var/log/sa/sa10 そして、時間枠を -s HH:MM -e HH:MM 。待ち時間に関する詳細な分析については、sar に以下を追加します。 I/O待機時間の分析, 、そうすることで待ち行列や処理能力をより適切に評価できるからであり、 ボトルネック 明確に特定する。.

測定値の正しい読み方：CPU、メモリ、I/O、ネットワーク

私は、信頼できる状況を素早く把握でき、経時的に比較できる少数の指標に注目しています。CPU-アイドル 0に近い値と高い%iowaitは、ディスクの待ち行列を示唆している。 %stealの値が高い場合は、仮想化環境におけるCPUリソースの不足を示しています。RAMに関しては、空きメモリページ、ページキャッシュの挙動、およびスワップイン/アウトに注目しています。ネットワークについては、パケットエラー、ドロップ、再送信の数値を参考に、容量の限界や障害の有無を把握しています。.

指標	sarスイッチ	目立つ数値	緊急措置
CPU	`sar -u [-P ALL]`	%idle が非常に低く、%iowait が高い	I/Oの確認、スレッドの割り当て、CPU要件の検証
メモリ	`sar -r`	空き容量が少なく、ページキャッシュの消失が激しい	サービスの最適化、RAMの増設、キャッシュの評価
スワップ	`sar -S`	頻繁なスワップイン／スワップアウト	メモリの負荷を軽減し、制限値を調整する
ディスクI/O	`sar -d`	await／svctmの値が高く、キューが膨れ上がっている	I/Oプロファイルを確認し、ストレージ・ティアリングまたはバッチウィンドウを調整する
ネットワーク	`sar -n DEV,ETCP`	ドロップ、エラー、再送信	MTU/オフローディングのテスト、帯域幅と遅延の分析

過去のデータと時間枠を分析する

私はほとんどいつも 時間枠, 、例えば sar -u -f /var/log/sa/sa10 -s 01:00:00 -e 05:00:00 夜間の仕事について。こうして、異なる日の同じ時間帯のデータを比較し、個別の事例ではなく傾向を把握しています。機械による分析のために、データを sadf -d CSV形式でエクスポートし、独自のダッシュボードに読み込みます。異常なピークが見られた場合は、周辺の区間も確認して、副作用の可能性を排除します。この方法は、長い準備作業を必要とせずに、すぐに活用できる手がかりが得られるため、シンプルにしています。.

トレンド分析と生産能力計画

私はアーカイブされた値を以下の目的で使用しています予想そして、直感ではなく実際のデータに基づいてリソースの規模を決定します。CPU使用率が週単位で上昇している場合は、コア数やクロックの余裕を確保するように計画します。キャッシュによってメモリ需要が増加している場合は、そのメリットとRAMの増設を比較検討します。I/Oパスで待ち時間が長くなっている場合は、より高速なストレージの導入か、バッチ処理ウィンドウの分離のいずれかを決定します。可視化については、代わりにデータを GrafanaとPrometheus sarのトレンドとエクスポーターからのメトリクスを組み合わせて分析する。.

実例：負荷のピークが発生するWebサーバー

WordPressのサイトが毎晩応答が遅くなるという事例について概説します。そして、 ユーザー 中絶を報告する。以下を使用して sar -u -s 18:00:00 -e 20:00:00 そして sar -d バックアップ中に同時発生するI/Oのピークを確認しました。並行して、 sar -n DEV ネットワークスループットの増加が、負荷状況に拍車をかけている。翌日、バックアップを行わずに再検証したところ、この傾向が確認された。ジョブのスケジュール変更、データベースクエリの最適化、キャッシュの調整を行った結果、夕方のピークが解消され、応答時間は再び安定した状態に戻った。.

データの管理、ローテーション、保管に関するヒント

をチェックする。 ストレージ に於いて /etc/sysconfig/sysstat 或いは /etc/default/sysstat そして、必要に応じて保持期間を設定します。重要なホストについては、季節的な傾向を把握できるよう、30～90日間データを保持しています。間隔が適切であり、過度な秒単位の更新が行われていない限り、ファイルサイズは管理しやすい範囲に収まります。古いアーカイブは、中央のディレクトリに移動するか、シンプルな長期保存ストレージに格納します。これにより、システムに負荷をかけたり、分析の速度を低下させたりすることなく、データの可用性を確保しています。.

モニタリング・スタックおよびログとの統合

私はsarを次のように設定しています 生データ-サプライヤーを導入し、それを一元的な監視、ログ分析、アラート機能と組み合わせます。APMやログスタックからイベント情報が提供され、sarがインフラのメトリクスを時間軸に沿って整理します。特に負荷の高いホストに対しては、さらに pidstat そして iostat, 、プロセスとI/Oパスを関連付けるために。さらに、以下のものが役立ちますプロセス会計, 、リソースを大量に消費するプロセスを明確に特定すること。イベントとメトリクスの両方の視点から情報を組み合わせることで、手探りでの作業を回避し、トラブルシューティングの時間を大幅に短縮できます。.

設定の微調整：間隔、sa1/sa2、タイマー

を置いた。 記録間隔 システムの動的特性に合わせて設定します。標準としては1分間隔が適していますが、変動の激しいホストの場合は10～30秒間隔も有効です。収集は sa1 （頻繁なサンプリング）、その日のまとめ sa2 （その日のレポート）。systemd では、該当するタイマーやサービスを確認し、実行頻度を調整します。Debian/Ubuntu では、多くの場合、次のように明示的に収集を有効にします。 ENABLED="true" に於いて /etc/default/sysstat. 環境ごとの間隔を記録しておき、後で正確に比較できるようにしています。そうすれば、5秒間のサンプルデータと1分間のデータを比較して、誤った結論を導き出すようなことがなくなります。.

sarオプションの高度な機能の概要

定番の機能に加え、追加のスイッチが 全体像: sar -b ブロックI/Oスループットの集計値を示しており、, sar -B カーネルのページング動作と sar -W スワップ取引の詳細。以下のように sar -q ランキュー（CPUを待機しているプロセス）と負荷の推移を確認しています。. sar -H 該当する場合は、Hugepageデータを提供します。ディスクについては、必要に応じて sar -d -p, 、パーティションを個別に確認するためです。私は svctm: この値は、最新のカーネルでは信頼性が低い場合や0になる場合があるため、私はむしろ待つ（エンドツーエンドの遅延）および avgqu-sz/aqu-sz （キューのサイズ）を選択します。そして、全体像を素早く把握したい場合は、 sar -A 大まかな概要を把握した上で、そこから焦点を絞っていきます。.

仮想マシンとコンテナを適切に評価する

時点では 仮想化 私は特に%stealに注目しています。スティール値が高いということは、VMのハイパーバイザーがCPU時間を奪っていることを意味します。%idleだけを評価していると、誤った判断を招きやすくなります。そのため、私はCPU使用率、スティール、およびランキューを相関分析しています（sar -q) を併用します。コンテナ環境では、ホストとワークロードの視点を分けています。sarは個々のコンテナではなく、ホストを監視します。サービスごとの詳細が必要な場合は、 pidstat （プロセス単位）およびcgroupsの制限を考慮に入れます。また、CPU周波数のスケーリングやパワーステート（クロック切り替え）についても確認します。これらは一時的なレイテンシを引き起こす可能性があり、文脈がなければCPUリソース不足のように見えるためです。.

時間に関する事項：タイムゾーン、サマータイム、および信頼性の高い相関関係

私は次のことに注意を払っている。 一定時間基準, 、比較が正確に行えるようにするためです。sarはデフォルトでローカルタイムで保存されますが、クラスタ環境では、タイムゾーンを統一する（多くの場合UTC）ことが推奨されます。夏時間の切り替え前後には、重複や欠落している時間枠がないか確認し、必要に応じて sadf ISO形式のタイムスタンプ付き。ログやAPMイベントとの相関分析を行う際は、タイムゾーンを調整し、メトリクスのピークをイベント（デプロイ、バックアップ、cronジョブ）と正確に照合するようにしています。正確な時間参照情報があれば、インシデントの事後分析における誤解を大幅に減らすことができます。.

sadf を使った自動化とエクスポート

レポートやダッシュボード用に、以下の方法でデータをエクスポートしています。 sadf. 普段、私は sadf -d (CSV) による簡単な集計、あるいは sadf -j （JSON）は、フレキシブルパイプライン用です。典型的なエクスポートは次のようになります： sadf -d /var/log/sa/sa10 -- -u -r -b -n DEV,ETCP -s 18:00 -e 20:00 > sar_abend.csv. このようにして、夕方の時間帯におけるCPU、RAM、ブロックI/O、ネットワークの主要指標をまとめたファイルを作成します。スクリプトでは、これを使って曜日ごとのデータを自動的に比較し、中央値や95パーセンタイルを算出し、外れ値を特定しています。可読性を保ち、誤検知を防ぐため、測定項目の数は意図的に最小限に抑えています。.

実例：ページキャッシュの負荷がかかるデータベースサーバー

あるMySQLホストで、時折クエリの遅延が発生しているという報告がある。. sar -r 夕方にはページキャッシュが減少していることが示されており、, sar -S 時折行われるスワップアウト。これと並行して、 sar -d その待つ-の時期、そして sar -b 書き込みトラフィックの増加を示しています。ログローテーションやETLジョブとの相関関係から、このパターンが説明できます。大規模な連続的な書き込みの波がキャッシュを押し出し、データベースへの読み取りをI/Oに追いやってしまうのです。そこで、ジョブの分散を図り、RAMを適度に増やし、DBバッファを意図的に拡大しました。その結果、await値とスワップ値は安定し、レイテンシは低下し、ページキャッシュはホットセットを確実にメモリ内に保持するようになりました。.

運用上の側面：オーバーヘッド、デバイス一覧、およびフィルタ

を持っている。 オーバーヘッド 比較対象を適切に選定することで、誤差を小さくします。Sysstatは主に /proc そしてバイナリ形式で書き込みを行います。1分間隔の場合、負荷はほとんど感じられません。デバイスが非常に多いホストや、短命なブロックデバイス（スナップショットなど）では、出力を適切にフィルタリングし、関連するパスだけを評価します。 dm-crypt、MD-RAID、またはマルチパスデバイスについては、ボトルネックを正確に特定するために、論理デバイスだけでなく、可能な場合はその基盤となるデバイスも確認します。その際、デバイス名を記録しておき、後で比較を行う際に、パス名が変更されたために比較が失敗することがないようにしています。.

方法論：ベースラインと比較日

ホストごとに1つの ベースライン 時間帯ごと（例：01～05時：バッチ、09～18時：オフィス、18～22時：ピーク）。各時間帯について、典型的な中央値と許容可能なパーセンタイルを把握しておく（例：CPU-%idle、, 待つ, avgqu-sz, （再送信など）。異常が見られた場合は、まず新しいジョブ、デプロイメント、あるいはトラフィックパターンを確認し、その後に初めてキャパシティの拡張を検討します。この厳格な手順を踏むことで、性急な判断を防ぐことができます。多くの場合、わずかな計画の変更やリミットの調整だけで、高額なハードウェアの増設よりも大きな効果が得られるからです。sarは、数週間から数ヶ月にわたる信頼性の高い事実データをそのための根拠として提供してくれます。.

制限と有用な追加事項

私はsarを～の代わりとは考えていません 注意喚起, 、というのも、デフォルトではしきい値の監視や通知の送信を行わないからです。リアルタイムのアラートは、ルールやエスカレーション、チームのワークフローを反映した専用のシステムに任せるべきものです。また、アプリケーション、データベース、JVMに関する詳細なメトリクスについても、エクスポーターやトレーシングを活用してカバーしています。 sarは、システムリソースの履歴を比較したり、運用上のボトルネックを特定したりしたい場合に真価を発揮します。総じて、インフラに関する疑問に対して迅速かつ再現性のある回答が求められる場面で、的を絞って活用しています。.

簡単にまとめると

私はこうしている。サルそしてsysstatを活用し、測定値からサーバー負荷の経緯を明確に把握します。定期的なデータ収集と的を絞った振り返りを組み合わせることで、症状を推測するのではなく、根本原因を特定できます。わずかなコマンドで、CPU、メモリ、I/O、ネットワークの問題を特定し、その発生時刻を特定します。そこから現実的なキャパシティの判断を導き出し、タイミングの悪いバックアップなど、非効率なルーチンを見極めます。Linuxサーバーの管理責任者にとって、この手法は信頼できる指針となり、分析、計画、運用にかかる時間を節約できます。.