NGINXのパフォーマンス監視:stub_statusモジュールの詳細解説

NGINXのstub_statusモジュールは、サーバーの接続状態とリクエスト処理状況をリアルタイムで監視するための強力なツールです。以下に各指標の詳細な解説を記載します。

1. ステータス出力例

Active connections: 1964 
server accepts handled requests
 289342958 289342958 1246833717 
Reading: 0 Writing: 21 Waiting: 1943

2. 各指標の詳細解説

(1)アクティブ接続数(Active connections)

  • 意味:現在処理中およびアイドル状態で保持されているすべての接続の総数。
  • サンプル値1964
  • 内訳
  • Reading:クライアントからのリクエストヘッダを読み取り中の接続数(HTTPリクエストヘッダの受信など)。
  • Writing:クライアントへのレスポンス送信またはバックエンドデータ処理中の接続数(レスポンスボディの返却、バックエンドからのレスポンス読み取りなど)。
  • Waiting:開いたままのアイドル接続数(HTTP Keepalive接続、新規リクエストを待機中)。

(2)サーバー統計情報

  • 三つの列データaccepts(受信接続数) | handled(処理済み接続数) | requests(総リクエスト数)
  • サンプル値289342958 289342958 1246833717
  • 重要なポイント
  • accepts == handled:すべての受信接続が正常に処理されていることを示します(接続のドロップなし)。accepts > handledの場合、バックエンド障害またはリソース制限により接続が拒否された可能性があります。
  • requests >> accepts:単一の接続で複数のリクエストが処理されていることを示します(HTTP Keepaliveによる接続の再利用)。

(3)Reading/Writing/Waiting

  • Reading0
  • 現在、リクエストヘッダを読み取り中の接続はありません。この値が継続的に高い場合、クライアントのアップロード速度が遅いか、リクエストヘッダが大きすぎる可能性があります。
  • Writing21
  • 21個の接続がレスポンス送信またはバックエンドデータ処理中です。高値はバックエンドサービスのレスポンス遅延またはクライアントのダウンロード速度低下を示唆します。
  • Waiting1943
  • 1943個の接続がアイドル状態で保持されています(Keepalive)。値が高すぎる場合は、keepalive_timeoutを調整してアイドル接続を減らす必要があります。

3. 主要な計算式と分析

  1. アクティブ接続の構成
Active connections = Reading + Writing + Waiting
1964 = 0 + 21 + 1943
  1. 接続効率
  • 平均接続あたりのリクエスト数:``` requests / accepts = 1246833717 / 289342958 ≈ 4.31(リクエスト/接続)
- HTTP Keepaliveによる接続の再利用効果が良好であることを示しています(単一接続で約4つのリクエストを処理)。
3. **アイドル接続の割合**:

Waiting / Active connections = 1943 / 1964 ≈ 99%

- アクティブ接続の大部分がアイドル状態であるため、`keepalive_timeout`を短縮する(例:`30s`に設定)などの最適化が必要です。

### **4. 異常ケースの分析**

- **Readingが継続的に高い場合**:
- クライアントのアップロード速度遅延(大容量ファイルのアップロードなど)。
- 悄悪意のあるリクエスト(例:過大なリクエストヘッダ攻撃)。
**対策**:クライアントの動作を確認するか、リクエストヘッダサイズを制限(`client_header_buffer_size`の調整)。

- **Writingが継続的に高い場合**:
- バックエンドサービスのレスポンス遅延(データベースクエリの遅延など)。
- クライアントのダウンロード速度低下(ネットワーク混雑など)。
**対策**:バックエンドサービスの最適化または`proxy_timeout`の調整。

- **Waitingが過剰に発生する場合**:
- アイドル接続が多すぎてサーバーリソースを消費。
**対策**:`keepalive_timeout`を短縮(例:`10s`)または`keepalive_requests`を減少させる。

### **5. stub_statusの設定**

NGINXでステータス監視を有効にする設定例:

server { location /server_status { stub_status; allow 192.168.1.0/24; # 特定のネットワークからのアクセスのみ許可 deny all; } }


アクセス方法:`curl http://your-server-ip/server_status`

### **6. 監視ツールとの連携**

- **Prometheus + Grafana**:
`nginx-prometheus-exporter`を使用して`stub_status`データを収集し、可視化。
- **Datadog**:
NGINXの統合モジュールを使用して`stub_status`データをDogStatsDに送信。
- **Telegraf + InfluxDB**:
カスタムスクリプトでステータスデータを定期的に収集し、時系列データベースに保存。

### **パフォーマンス分析のポイント**

- **アクティブ接続**:1964(内訳:処理中21、アイドル1943)
- **接続効率**:HTTP Keepaliveの再利用効果良好(1接続あたり4.31リクエスト)
- **最適化の余地**:
- `Reading/Writing`に異常が見られる場合、クライアント/バックエンドのパフォーマンスをチェック。
- `Waiting`が多すぎる場合、Keepalive関連パラメータの調整を検討。

これらの指標を監視することで、接続ボトルネックや攻撃(例:CC攻撃による`Writing`の急増)を迅速に特定できます。

タグ: nginx パフォーマンス監視 stub_status モニタリング サーバー最適化

5月19日 17:00 投稿