Grafana を使った Linux PSI モニタリングの可視化：リソース負荷を正しく理解し、監視する

私がどのようにしているか linux psi Prometheusでデータを収集し、Grafanaで可視化することで、CPU、メモリ、I/Oへのリソース負荷を実際の待ち時間として測定します。これにより、次のようなことがわかります ボトルネック 早期に、それらをcgroupsまたはコンテナに割り当て、必要に応じて自動化された対策を講じる。.

中心点

• PSI指標: CPU、メモリ、I/O、および移動平均については「some/full」
• cgroupの焦点: 単にグローバルな視点だけでなく、コンテナやサービスに特有の視点
• アラートトリガー: poll/epoll を使用したしきい値に基づくイベントの処理
• グラファナ: トレンド、ピーク、および上位N位の原因要因に関するパネル
• ベストプラクティス: しきい値、時間枠、システムメトリクスとの相関関係

PSIの簡単な解説：圧力を「実際の待ち時間」と捉える

PSIは、「いくら」という疑問に答えています 実時間 タスクがCPU、RAM、またはI/Oを無駄に待機している。以下のパスにあるファイルは /proc/pressure/{cpu,memory,io,irq} 2つの視点を提供する： いくつか 一部のタスクが待機しているフェーズを示し、, フル は、アイドル状態ではないすべてのタスクがブロックされている瞬間を示しています。私はこの2つの値を別々に評価しています。なぜなら、 いくつか より早く現れ、 フル 実際の停止状態を可視化します。さらに、私は avg10, avg60 そして avg300, 、短期的な変動と長期的な傾向を区別するために。増加傾向にある 合計-その瞬間、ボートに乗ってからどれほどプレッシャーが積み重なってきたか、そしてどこに ホットスポット 嘘だ。

システム全体 vs. cgroup-PSI：適切なレベルを選択する

私は、グローバルな圧力値と、各ビューごとの表示を意図的に区別しています。 cgroup. 以下の場所にあるファイル /proc/pressure/ はシステム全体を示していますが、cgroup v2 ではさらに cpu.pressure, memory.pressure そして io.pressure 各グループごとに提供します。コンテナ環境では、これを使ってPodやサービスなどを整理して配置します。 コンテナ 。この割り当てにより、手探りでの運用を防ぐことができます。当て推量で対応する必要がなく、グループ内で原因を直接特定できるからです。マルチテナントホスト上では、この方法で共有負荷と専用負荷を分離し、制御しています。 限界 をターゲットにした。.

前提条件の確認：カーネル、PSI、cgroup v2 を有効にする

メトリクスを収集する前に、そのプラットフォームが適切であることを確認します：

• カーネルバージョン: PSI は Linux 4.20 以降で利用可能です。私は次のように確認しています uname -r そして、以下を通じて確認する zcat /proc/config.gz | grep CONFIG_PSI, サポートが組み込まれているかどうか。.
• PSI実行時間フラグ: 一部のディストリビューションでは、オプションのブートフラグの使用が許可されています psi=1, PSIを完全に有効にするためです。必要に応じてこれを実行し、 /proc/pressure/* コンテンツを提供しています。.
• cgroup v2: サービス／コンテナごとのビューでは、私は 統一階層. 私は以下を使って確認します mount | grep cgroup2 そして、次のようなものを期待している cgroup2-マウント（しばしば /sys/fs/cgroup). もしそれがなければ、カーネルパラメータを使って有効にします systemd.unified_cgroup_hierarchy=1 （再起動が必要です）。.
• 認可: ホスト上のエクスポートツールには、以下のファイルに対する読み取り権限が必要です /proc/pressure/* および必要に応じて /sys/fs/cgroup/*/*.pressure. コンテナ内では、これらのパスを読み取り専用でマウントしています。.

PSIトリガーの活用：ただ観察するだけでなく、自動的に反応する

時系列データに加え、以下のイベントについても掲載しています 投票 或いは epoll PSIファイルに閾値と時間枠を記述することで実現しています。リソースへの負荷が時間枠内の閾値を超えると、イベントが発生し、私は対策を講じます。その対策としては、追加のポッドの起動、キャッシュのフラッシュ、あるいは一時的な バッチジョブ である。Systemdユニットでは、この反応をサービスに直接紐付け、遅延を最小限に抑えている。こうして、モニタリングは単なる監視にとどまらず、制御手段となる。 表示.

実際の運用では、対応する *圧力-ファイルを開くには、 write() トリガー（いくつか 或いは フル （しきい値およびウィンドウ（µs単位）を含む）を記録し、その後、 epoll イベントをブロックして待機します。これにより、ポーリングサイクルを節約し、決定論的に反応できます。過渡現象を除去するために、ウィンドウを意図的にやや長く（例：10～30秒）設定し、リソースごとに区別しています： メモリー より敏感に反応する io, CPU 解雇するには、もっと明確でなければならない。.

PSIからPrometheusへのエクスポート：エージェント、メトリクス、ラベル

時系列データについては、専用のエクスポートツールを使用してPSIを収集するか、または既存のエージェント（例えば ノード・エクスポーター. Grafanaでのクエリが正確にフィルタリングされるためには、ホスト、cgroup、コンテナに対して一貫性のあるラベルを付けることが重要です。Kubernetesでは、さらにcAdvisorおよびKubeletのメトリクスを使用して *_圧力_*_待機秒数_合計, 、ノード、ポッド、コンテナの各レベルが一致した状態を維持するためです。従来のホストについては、次のように読み取ります /proc/pressure/* 直接とフォルダ いくつか そして フル 個別のメトリクス名。エージェント統合の手順については、例えば以下のURLを参照してください。 Node Exporter の設定.

エクスポーターのバリエーションの詳細：Node、cgroup、Kubernetes

状況に応じて、さまざまな方法を用いています：

• ノード・エクスポーター (ホストレベル)：私は 圧力-Collector（デフォルトで有効になっていない場合）、例えば次のように指定して --collector.pressure. 以下のような指標を提供します。 node_pressure_cpu_some_avg10, node_pressure_memory_full_avg60 そして node_pressure_io_waiting_seconds_total{state="some|full"}. 後者は、次のような場合に適しています。 rate()-分析およびトップN。.
• 独自の cgroup エクスポーター （サービス／コンテナレベル）：より詳細な情報を得るために、以下を読み取ります /sys/fs/cgroup//{cpu,memory,io}.pressure そして、次のようなメトリクスを生成し、 cgroup_pressure_memory_waiting_seconds_total{state="full",cgroup="..."} そして avg10/60/300‑ゲージ。cgroupのパスをラベルとして正規化します（cgroup) またはフォルダに 奉仕/容器 ラベル。.
• Kubernetes: ノードレベルでPrometheusがデータを収集する node‑exporter. コンテナビューには、以下の設定を持つDaemonSetエクスポーターを使用しています。 hostPID:true および読み取り専用マウントの /sys/fs/cgroup そして /proc, 、ホストのcgroupファイルを表示するためです。さらに、PSIの合計値が出力される場合は、Kubelet/cAdvisorのメトリクスも参照します。ラベル 名前空間, ポッド そして 容器 その点については一貫性を保っています。.

私には、明確なものが役に立つ レーベル戦略: インスタンス (ホストまたはノード名)、, cgroup (パス)、, 名前空間/ポッド/容器 （K8sの場合）および state (いくつか/フルそして リソース (CPU/メモリー/io/irq). これにより、大まかに集計しつつ、同時に詳細まで拡大表示することができます。.

Prometheusのジョブ、記録ルール、およびクエリ例

正確な分析を行うために、私は2つのテンプレートを使用しています：パーセントゲージ（avg10/60/300) およびそこから導かれた rate()‑の値は *_waiting_seconds_total*‑メーター。.

• スクレイプ: 15秒は良いスタートだ。短くすると負荷が増え、 avg10 しかし、付加価値となることはめったにない。.
• 録音のルール: ダッシュボードやアラートの管理を簡素化するために、派生時系列を算出しています：
  • record: psi:node_memory_full:avg60 = avg_over_time(node_pressure_memory_full_avg10[60s])
  • record: psi:node_io_full:rate5m = rate(node_pressure_io_waiting_seconds_total{state="full"}[5m])
  • record: psi:cgroup_memory_full:rate5m = (cgroup)ごとの合計 (rate(cgroup_pressure_memory_waiting_seconds_total{state="full"}[5m]))

PromQLを使って、典型的なビューを作成しています：

• ホストのトレンド: node_pressure_memory_full_avg60 時間ごとに、ノードごとに分類して。.
• 排出量上位N社: topk(5, psi:cgroup_memory_full:rate5m) 最もノイズの大きいcgroupsを表示します。.
• レイテンシへの影響: (increase(http_request_duration_seconds_sum[5m]) / increase(http_request_duration_seconds_count[5m])) にとって node_pressure_io_full_avg60 相関関係を把握するために設定する。.
• プラトーを見分ける: clamp_min(psi:node_io_full:rate5m, 0.0) ノードごとのヒートマップとして。.

Grafanaダッシュボード：トレンドを可視化し、注目すべき箇所を見つける

Grafanaでは、CPU、メモリ、I/Oの負荷をそれぞれ個別に表示しており、それぞれについて いくつか そして フル 個別のグラフとして表示されます。バーゲージは現在のステータスを示し、時系列パネルはピークやプラトーを明らかにしてくれます。原因分析には、cgroup、コンテナ、またはポッドごとの「トップN」ビューを活用し、そこから詳細パネルへ移動します。重要なのは、 avg10, avg60 そして avg300, 、短いスパイクによるオーバーロードを防ぐためです。ダッシュボードの設計を先を見据えて行いたい方には、以下のテーマに関する役立つアイデアが見つかります。 GrafanaとPrometheus スタック。.

実務におけるアラート対応：ルール、ウィンドウ、エスカレーション

私は2段階のモデルに従っています： 警告 初期の兆候については、, クリティカル 恒久的なボトルネックとなる。例として、次のように挙げる：

• メモリー
  • 警告： node_pressure_memory_full_avg60 > 0.01 10～30秒間
  • 重要： node_pressure_memory_full_avg60 > 0.05 60秒以上
• 入出力
  • 警告： rate(node_pressure_io_waiting_seconds_total{state="some"}[5m]) > 0.02
  • 重要： node_pressure_io_full_avg60 > 0.02 120秒以上
• CPU
  • 警告： node_pressure_cpu_some_avg60 > 0.05
  • 重要： node_pressure_cpu_full_avg60 > 0.01 （なぜなら フル （ここが特に痛い）

「Annotations」では、コンテキスト（トップcgroups、スループット、レイテンシ）を関連付け、プレイブック（スケールアップ、制限の調整、キャッシュ操作、バッチのスロットリング）を実行します。イベントが繰り返し発生する場合は、キャパシティに関する決定を優先します。.

警報閾値と通報：適切な時間枠の選択

リソースごとに明確な閾値を定義し、完全なダウンと一時的な負荷のピークを区別します。例えば、私は メモリがいっぱいです 5 %以上で60秒を超える場合は「重大」とみなされますが、1～2 %で10秒を超える場合は「警告」のみが発生します。CPUについては、より厳しい制限を設定しています。 フル, 、その場所では広範囲にわたる待ち時間が顕著に処理を遅らせるためです。スループットやレイテンシの指標と組み合わせることで付加価値が生まれます。負荷が高まり、リクエストの処理が遅くなると、緊急度が高まります。私は、誤検知を防ぐために、アラートを常に時間枠に基づいて設定し、単一の値に基づいて設定することは避けています。 バースト を避けなければならない。

Kubernetes：スクレイプの設定、権限、および相関関係

クラスター内では、レベルが一致するようにPSIを収集しています：

• デーモンセットとしてのNode-Exporter: ノードごとの標準スクレイプにより、グローバルなPSI値が得られます。.
• cgroupエクスポーターをサイドカー／デーモンセットとして: ホストの cgroup v2 ファイルを読み込み、ラベル付けを行う 名前空間/ポッド/コンテナ. 必要最小限の権限とROマウントのみを使用しています。.
• Kubelet/cAdvisor: 関連するコンテナメトリクスの出力機能を有効にし、Kubeletエンドポイントをスクレイピングします。ラベル結合キー（例：. 容器 対 container_name) 一貫性を保つことで、PromQLの結合がスムーズに機能するようになります。.
• ワークロードメトリクスを用いたJOIN: Pod-PSIとアプリの遅延（例：HTTPメトリクス）、CPUリミット到達回数、メモリエラーを相関分析しています。これにより、原因がリミット、スケジューリング、あるいはストレージのボトルネックのいずれであるかを特定しています。.

PSIファイル、主要指標、および解釈：簡潔な概要

以下の表は、主要なファイル、指標、および用途をまとめたもので、これにより解釈を迅速に行い、適切なGrafanaパネルを構築できるようになります。私は分析の際にこの表を活用し、次の課題（チューニング、スケーリング、またはトラブルシューティング）を計画しています。特に重要なのは、以下の間の違いです。 いくつか そして フル および3つの平均ウィンドウ。これにより、症状を時系列で整理し、圧迫が局所的なものか広範囲にわたるものかを確認します。「使用」列は、迅速な 分類.

リソース	ファイル	主な数字	意味	用途
CPU	/proc/pressure/cpu	一部、完全；平均10/60/300；合計	空き計算時間の待ち時間	過負荷のホスト、CPUリソースが不足している限界
メモリー	/proc/pressure/memory	一部、完全；平均10/60/300；合計	Reclaim、Swap、OOMに近い状態による待機時間	RAMの不足、キャッシュの負荷、不具合のある リクエスト
入出力	/proc/pressure/io	一部、完全；平均10/60/300；合計	ストレージデバイス／ファイルシステムへの待機時間	低速なストレージ、同期の集中、, フラッシュ-段階
割り込み要求	/proc/pressure/irq	一部、完全；平均10/60/300；合計	割り込み処理による負荷	ネットワーク負荷、ドライバのチューニング、, 親和性
cgroup	*/{cpu,memory,io}.pressure	一部、完全；平均10/60/300；合計	サービス／コンテナあたりの印刷数	根本原因の特定、的を絞った 限界

実践：ホスティングとWordPressスタックを効率的に保護する

利用率の高いWordPressホストでは、PHP-FPM、データベース、キャッシュレイヤーがRAMやI/Oを巡って頻繁に競合しますが、これについては メモリー そして io すぐに見える。上昇する フル メモリに関しては、OpCacheを最適化したり、プールサイズを適度に増やしたり、リソースを消費するプラグインを削減したりします。 I/O負荷が高い場合は、クエリープラン、ジャーナリング設定、非同期書き込みを確認します。cgroupごとのPSIを確認することで、ボトルネックの原因がWebサーバー、ワーカー、データベースのどれであるかがわかります。さらに深く掘り下げたい方は、以下の Linux-PSI ガイド, 、その概要と評価をまとめたものです。.

キャパシティ計画とチューニング：数字から具体的な行動へ

PSIをCPU使用率、ページフォールト、I/Oスループット、レイテンシと関連付けて、真の原因を特定します。問題が継続する場合は、 メモリがいっぱいです RAMのスケーリングを行ったり、Reclaimパラメータを最適化したり、ワークロードを分散させたりします。表示されます io full 長期にわたるプラトーが発生した場合は、キューの深さを増やしたり、ライトバック戦略を有効にしたり、より高速なストレージを導入したりします。CPU負荷については、ランキューの長さを並行して測定し、スケジューリングクラスを調整し、高負荷のスレッドを分散させます。決定を下すのは、トレンドが avg60 そして avg300 一貫性を保ち、単なる スパイク が利用できる。

トラブルシューティングと検証：ホストからコンテナまで

PSIの値がない場合は、カーネルのバージョンを確認し、, CONFIG_PSI また、オプションで以下のブートパラメータを指定することもできます psi=1. その後、以下のパスにあるファイルの出力を確認します。 /proc/pressure/* 手動で設定し、エクスポーターのメトリクスと照合します。cgroup v2 では、さらに以下の項目も管理しています。 *.pressureグループディレクトリ内の-ファイル。負荷発生ツールを使用してアラートをテストし、以下の方法で応答ロジックを監視しています。 epoll, 、設定ミスを早期に発見するためです。最後に、Grafanaのパネルとログ、トレース、プロファイリング結果を照合し、診断と対策が確実に行われるようにします。 フィット.

私が想定している典型的な障害は以下の通りです：

• スワップの相互作用: 軽い memory some- 値は、アグレッシブなリクレイム時には正常です。問題となるのは、 フル 上昇する一方で、レイテンシも増加する。.
• CPUの分離とアフィニティ: ピン留め／絶縁されたコアは、局所的に CPU使用率100% 生成してしまうが、ホストにはまだ余裕がある。確認中だ。 irq-ネットワークやストレージの割り込み負荷が高い場合は、PSIを追加してください。.
• 仮想環境: 仮想マシン（VM）では、PSI値にはハイパーバイザーの影響も反映されます。オーバーコミットメントの原因を明確に特定するため、ホスト層とゲスト層を別々に測定しています。.
• スクレイプのオーバーヘッド: PSI自体は負荷が軽いですが、スクレイピング間隔が短すぎるとPrometheusの負荷が高まります。15秒が多くの場合、最適な間隔です。.
• ラベルのカーディナリティ: cgroup のパスが爆発的に増える可能性があります。私は次のように調整しています。 labeldrop/keep そして、分析対象のレイヤーのみをマッピングします（例：一時的なタスクcgroupのすべてではなく、サービスのみ）。.

簡単にまとめると

PSIは実際の値を測定します 待ち時間 CPU、RAM、I/Oに負荷がかかり、リソースの逼迫を明確に示しています。PrometheusエクスポートとGrafanaダッシュボードを活用して、原因を特定し、ボトルネックを迅速に特定できる監視環境を構築しています。以下の分離により、 いくつか そして フル それに窓も avg10/60/300 意思決定を堅牢なものにします。アラートを特定の期間に設定し、レイテンシと連動させ、トリガーを通じて自動応答を制御します。これにより、根拠に基づいたキャパシティの決定を行い、ボトルネックを適時に解消し、日常業務においてサービスを安定して維持します。 レスポンシブ.