Posted inMonitoring

Prometheus Process Exporter 徹底ガイド：Linux の各プロセスの「健康状態」を詳細に監視する

Monitoring tutorial - IT technology blog
Monitoring tutorial - IT technology blog

課題：ダッシュボードで CPU 100% と表示されるが、どのアプリが原因かわからない

SRE の皆さんにとって、これは決して珍しい光景ではないでしょう。Grafana が赤く染まり、サーバーの CPU が 100% に急上昇し、RAM がスワップ領域に溢れ出す。急いで SSH でログインし、top や htop を叩いて原因を突き止める。すると、Python のワーカーが無限ループに陥っていたり、Java アプリケーションがフリーズしていたりすることが分かります。

もし、トラブルが午前 2 時に発生し、確認する前に自然に解消してしまったら、どのプロセスがエラーを引き起こしたのかをどうやって特定すればよいでしょうか？サーバー全体の CPU 使用率を表示するだけの概要ダッシュボードでは、その答えを出すには不十分です。

なぜ Node Exporter だけでは不十分なのか？

私が運用しているモニタリングシステムでは、Prometheus と Grafana を使用して 20 台以上のサーバーを監視しています。当初は Node Exporter だけを使用していました。このツールは、システム全体の CPU、RAM、ネットワークなどの一般的な指標を取得するのに非常に優れています。

しかし、Node Exporter には大きな欠点があります。それは、プロセスレベルの可視化が全くできないことです。サーバーが 16GB の RAM を消費していることは分かっても、Node.js アプリケーションがメモリリークを起こして 12GB を占有していることまでは示せません。マイクロサービス環境において、このようなデータが欠けていると、トラブルシューティングに多大な時間を費やすことになります。

現在の監視手法の比較

この課題を解決するために、エンジニアは通常、以下の 3 つの direction 性を検討します：

  • 自作スクリプト： /proc からデータを取得して Pushgateway に送信する Bash スクリプトを作成する。この方法はかなり手動的で、メンテナンスが難しく、システムに余計な負荷をかける可能性があります。
  • Netdata： リアルタイムで非常に詳細な監視が可能。しかし、すでに Prometheus スタックを構築している場合、プロセスの指標を取得するためだけに Netdata を追加でインストールするのはリソースの無駄になるかもしれません。
  • Zabbix： プロセス監視が非常に強力。しかし、クラウドネイティブな方向性を目指している場合、既存の Prometheus システムに Zabbix を導入するのはアーキテクチャ的に一歩後退と言えるかもしれません。

最適な解決策：Prometheus Process Exporter

さまざまなツールを試した結果、私は Process Exporter を選択しました。軽量で設定が柔軟であり、名前、パス、またはコマンドラインごとにプロセスをグループ化することができます。

ステップ 1：Linux サーバーへのインストール

GitHub から最新のバイナリをダウンロードします。例として、Linux 64bit 環境の場合：

wget https://github.com/ncabatoff/process-exporter/releases/download/v0.7.10/process-exporter-0.7.10.linux-amd64.tar.gz
tar -xvf process-exporter-0.7.10.linux-amd64.tar.gz
sudo mv process-exporter-0.7.10.linux-amd64/process-exporter /usr/local/bin/

ステップ 2：プロセスグループ化の設定

Process Exporter は、システム内の数千のプロセスを無差別に取得することはありません。データを軽量に保つために、本当に関心のあるアプリケーショングループを定義する必要があります。

/etc/process-exporter/config.yaml に設定ファイルを作成します：

process_names:
  - name: "{{.Comm}}"
    cmdline:
    - 'nginx'

  - name: "{{.Comm}}"
    cmdline:
    - 'mysqld'

  - name: "Java_Backend"
    cmdline:
    - 'java'

変数 {{.Comm}} を使用すると、実行ファイル名を自動的に取得できます。また、「Java_Backend」のように分かりやすい名前を付けて、ダッシュボードでフィルタリングしやすくすることもできます。

ステップ 3：Systemd サービスとしての実行

Exporter がサーバー起動時に自動的に開始するように、サービスファイルを作成します：

sudo nano /etc/systemd/system/process-exporter.service

ファイルの内容：

[Unit]
Description=Process Exporter
After=network.target

[Service]
User=root
ExecStart=/usr/local/bin/process-exporter -config.path /etc/process-exporter/config.yaml
Restart=always

[Install]
WantedBy=multi-user.target

次のコマンドでサービスを有効化します：

sudo systemctl daemon-reload
sudo systemctl start process-exporter
sudo systemctl enable process-exporter

http://<IP_SERVER>:9256/metrics で確認してください。namedprocess_namegroup_cpu_seconds_total という行が表示されていれば成功です。

ステップ 4：Prometheus の Scrape 設定

prometheus.yml ファイルに以下のセクションを追加します：

scrape_configs:
  - job_name: 'process-stats'
    static_configs:
      - targets: ['192.168.1.10:9256']

Grafana でのデータの可視化

ダッシュボードをゼロから作成する必要はありません。高品質なコミュニティダッシュボードを利用しましょう。おすすめは ID 249（基本）または 8378（詳細なパラメータ）です。

注目すべき重要な指標：

  • CPU usage per process: どのアプリケーションがコアを消費しているか一目で分かります。
  • Resident Set Size (RSS): プロセスが実際に占有している RAM 量（メモリリークの特定に非常に重要）。
  • Disk I/O: どのサービスが 50MB/s の読み書きを行ってシステムを圧迫しているかを確認します。
  • File Descriptors: アプリケーションがクラッシュする前に、「Too many open files」エラーを早期に警告します。

運用における実践的なヒント

実際のシステムに導入した後、役立つ 3 つの注意点を紹介します：

  1. 過剰な監視を避ける： コアサービスのみを監視対象にすべきです。何百もの細かなプロセスを監視すると、Prometheus の TSDB がノードあたり毎日 50-100MB ほど肥大化します。
  2. 正規表現の活用： 異なるパラメータで複数のアプリケーションインスタンスを実行している場合は、cmdline で正規表現を使用して 1 つのグループにまとめると整理されます。
  3. スマートなアラート設定： サーバー全体がダウンするのを待つのではなく、特定のプロセスの RAM 使用率が 80% を超えたときに Alertmanager が通知するように設定しましょう。

プロセスごとの状態を詳細に把握することで、システムのスケールアップも自信を持って行えるようになります。このガイドが、サーバー CPU の急上昇に悩むエンジニアの助けになれば幸いです。

Share:
Tags: