PHP-FPM 監視
設定不要で、PHP-FPMのプロセスポール、処理が遅いリクエスト、メモリ使用量、およびワーカーの状態をリアルタイムで監視できます。
なぜ監視するのか PHP-FPM?
PHP-FPM（FastCGI Process Manager）は、数百万ものWebアプリケーションにおけるPHPリクエストの処理を担っています。PHP-FPMを監視することは、処理の遅いスクリプトを特定し、プロセスポールのサイズを管理し、メモリ不足を防ぎ、アプリケーションの応答性を維持するために不可欠です。
PHP-FPM 監視を、 解説
PHP-FPM 監視は、プール枯渇、スロークエリ、ワーカーリークを、サーバー上のすべての PHP リクエストを遅くする前に検出します。WordPress、Laravel、Magento、その他あらゆる Nginx + PHP-FPM スタックにおいて、プールごとの可視性は、ユーザーが報告する遅延と根本原因をつなぐ最も有用なシグナルです。Xitoring はホスト上のすべてのプールを自動検出し、ネイティブの /fpm/status エンドポイントを 1 分間隔でポーリングし、既存のオンコールローテーションにアラートをルーティングします。
私たちが 監視するもの
アクティブプロセス
現在PHPリクエストを処理中。
アイドルプロセス
リクエスト待機中のワーカー。
遅いリクエスト
slow_log閾値を超えるリクエスト。
リスンキュー
空きワーカー待機中のリクエスト。
max_children到達回数
プロセス上限に達した回数。
プロセスあたりのメモリ
PHP-FPMワーカーあたりの平均メモリ。
リクエスト時間
リクエストの平均処理時間。
総プロセス数
起動されたPHP-FPMワーカーの総数。
Accepted Conn
起動以降にプールが受け付けた接続の合計数。`start since`（稼働時間）と組み合わせることで、プールごとのリクエスト/秒のレートをきれいに算出できます。
Memory per Process
ワーカーごとの平均常駐メモリ。リサイクル間で着実に増加する場合はリークの兆候です — `pm.max_requests` をチューニングしてより積極的にリサイクルしてください。
Request Duration
`?full` ステータス出力からの、プールごとの平均リクエスト処理時間。平均では見えないテールレイテンシを捉えるために p95 を追跡してください。
設定可能 アラートのトリガー
ダッシュボードでカスタムトリガーを設定し、PHP-FPMのメトリクスが定義した閾値を超えた瞬間に通知を受け取れるようにします。
遅いリクエスト
警告遅いリクエスト数が閾値を超えたときに発動。
リスンキュー
重要なリクエストがキューに蓄積したときに発動。ワーカー不足を示します。
最大子プロセス数
重要なプロセス上限に繰り返し達したときにアラート。
メモリ使用量
警告プロセスあたりのメモリ使用量が高いときに発動。
アクティブプロセス
警告すべてのワーカーがビジー状態のときに発動。
の重要性： PHP-FPM監視
PHPはウェブサイトの77%を支えます。監視がないと、遅いスクリプト、メモリリーク、ワーカー枯渇がアプリケーションを停止させます。
- ユーザーに影響する前に遅いPHPスクリプトを検出
- 実データに基づいてプロセスプールを適正サイジング
- リークするスクリプトによるメモリ枯渇を防止
- リクエスト損失を防ぐためにリスンキューを監視
なぜ選ぶべきか： Xitoring
ゼロコンフィグセットアップとマルチプールサポートでシームレスなPHP-FPM監視。
- ワンコマンドインストール
- マルチプール監視サポート
- 統合ダッシュボード
- マルチチャネルアラート
- 履歴データ保持
PHP-FPM 監視の一般的な シナリオ
PHP-FPMが今日一般的に実行されている場所 — そして誰も監視していない場合に何が問題になる可能性があるか。
WordPress、Laravel、その他のPHPサイト
ほとんどのPHPサイトは同じ理由で遅くなります。それは、 incoming visitors を十分に速く処理できる空きワーカーが不足しているためです。私たちはボトルネックが発生した瞬間にそれを検知し、検索ランキングやコンバージョンが影響を受ける前にチームが修正できるようにします。
コンテナ内で実行されるPHPアプリ
同じアプリが多くのコンテナで実行される場合、一部のコンテナは他のコンテナよりもはるかに多くのトラフィックを静かに処理することがあります。私たちはこの不均一な負荷を表面化させ、一部の訪問者が他の訪問者よりも遅い体験をする前に、チームが再バランスを取れるようにします。
共有ホスティング上の多数のウェブサイト
共有ホスティングでは、ある「うるさい」顧客サイトが、他のすべてのサイトが必要とするリソースを静かに消費することがあります。私たちはどのサイトが問題を引き起こしているかを示し、チームが闇雲に再起動するのではなく、原因に対処できるようにします。
PHP-FPM の 前提条件
これらが揃っていることを確認してください — 揃っていれば、ほとんどの導入は 60 秒で完了します。
- プール設定で
pm.status_path = /fpm/statusおよびping.path = /fpm/pingが設定された PHP-FPM - ステータス URL が localhost からアクセス可能であること（Nginx/Apache の fastcgi_pass 経由）
- PHP-FPM のログおよびプール設定への読み取りアクセス
はじめに 議事録
Web サーバーに Xitogent をインストール
PHP-FPM が稼働しているホストに軽量な Xitogent 監視エージェントをインストールしてください。
curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEYPHP-FPM ステータスページを有効化
プール設定（通常 `/etc/php/X.Y/fpm/pool.d/www.conf`）に `pm.status_path = /fpm/status` と `ping.path = /fpm/ping` を設定します。Nginx（または Apache の同等構成）に fastcgi_pass の location ブロックを追加してパスを localhost に公開し、PHP-FPM を再読み込みして URL が応答することを確認してください。
# In your PHP-FPM pool config (e.g. /etc/php/8.x/fpm/pool.d/www.conf)
pm.status_path = /fpm/status
ping.path = /fpm/ping
# Then in Nginx, expose them to localhost:
location ~ ^/fpm/(status|ping)$ {
allow 127.0.0.1;
deny all;
fastcgi_pass unix:/var/run/php-fpm/www.sock;
include fastcgi_params;
}PHP-FPM 連携を有効化
Xitoring ダッシュボードまたは CLI から PHP-FPM 連携を有効化してください。Xitogent がホスト上のすべての FPM プールを自動検出し、それぞれを独立して追跡します。
sudo xitogent integrateアラートしきい値を設定（オプション）
Slow Requests、Listen Queue、Max Children Reached にカスタムしきい値を設定し、ユーザーが感じる前に性能劣化やプール枯渇を検知できるようにします。
動作確認
サーバー上でこのコマンドを実行して、Xitogent が連携を認識していることを確認してください。約 30 秒以内に新しいメトリクスがダッシュボードに流れ始めます。
sudo xitogent status代替ツールを 検討中ですか？
PHP-FPM 監視の代替ツールと比べて Xitoring がどう優れているかをご覧ください — 定額料金、より深い統合、そしてスタック全体をカバーする 1 つのエージェント。
