Nginx status入門：基本の設定から見方までを解説

By /

Nginx status入門：基本の設定から見方までを徹底解説

Webサーバーとして広く利用されているNginxは、高いパフォーマンスと安定性が特徴です。しかし、その性能を最大限に引き出し、安定稼働を維持するためには、サーバーの状態を継続的に監視することが不可欠です。Nginx自身が提供するステータス情報（接続数、処理されたリクエスト数など）は、サーバーの状態を把握し、パフォーマンスの問題を特定する上で非常に有用な手がかりとなります。

この記事では、Nginxに標準で組み込まれているngx_http_stub_status_moduleというモジュールを利用した、基本的なステータス監視の方法について、設定から取得した情報の見方、そしてその応用までを徹底的に解説します。

なぜNginxのステータス監視が必要なのか？

Nginxサーバーを運用する上で、なぜステータス監視が重要なのでしょうか？その理由はいくつかあります。

  1. パフォーマンスボトルネックの特定:
    • サーバーへのリクエストが増加した際に、どの状態（新しい接続を受け付けているか、リクエストを読み込んでいるか、レスポンスを返しているか、待機中か）でボトルネックが発生しているのかを把握できます。
    • 特定の時間帯にパフォーマンスが低下する場合、その時間帯のNginxのステータス情報を見ることで、原因究明の手がかりを得られます。
  2. リソース利用状況の把握:
    • 現在の接続数や処理速度を知ることで、サーバーがどれだけ負荷を受けているかを定量的に把握できます。
    • サーバーのリソース（CPU、メモリ、ネットワーク帯域など）が限界に近づいている兆候を早期に検知し、スケールアップやスケールアウトの検討に役立てることができます。
  3. 問題発生時の切り分け:
    • サイトが遅い、あるいはアクセスできないといった問題が発生した場合、Nginxのステータス情報を見ることで、Nginx自身に問題があるのか、それともバックエンドのアプリケーションサーバーやデータベース、ネットワークなどに問題があるのかを切り分ける初期調査に利用できます。
  4. Keep-Alive接続の効率性の確認:
    • Keep-Alive接続が適切に機能しているか（Waiting接続が多いか）を確認することで、接続効率を評価できます。
  5. キャパシティプランニング:
    • 過去のステータス情報の推移を分析することで、将来的なトラフィック増加に備えたキャパシティプランニングの参考になります。

このように、Nginxのステータス情報は、サーバーの健全性やパフォーマンスに関する多くの重要な情報を含んでいます。これを継続的に監視することで、安定したサービス提供に繋げることができます。

この記事では、Nginxに標準搭載されているngx_http_stub_status_moduleを用いた最も基本的な監視方法に焦点を当てます。より高度な監視や詳細なメトリクスが必要な場合は、後述する他の方法も検討する必要がありますが、まずはここから始めるのがNginx監視の第一歩となります。

Nginxのステータス監視とは：ngx_http_stub_status_moduleの概要

Nginxには、サーバーの基本的なアクティビティに関する情報を提供する組み込みモジュールであるngx_http_stub_status_moduleがあります。このモジュールを有効にし、設定ファイルで特定のロケーションに割り当てることで、HTTP経由で現在のNginxサーバーのステータス情報を取得できるようになります。

ngx_http_stub_status_moduleが提供する情報

このモジュールが提供するステータス情報は非常にシンプルですが、サーバーの基本的な状態を把握するのに十分役立ちます。デフォルトでは、以下の5つの数値が出力されます。

  • Active connections: 現在アクティブなクライアント接続数。これには、Reading、Writing、Waitingの状態にあるすべての接続が含まれます。
  • server accepts handled requests: これは3つの値が並んで表示されます。
    • accepts: Nginxが正常に受け入れた接続の総数。
    • handled: Nginxが処理した接続の総数。通常はacceptsと同じか近い値になりますが、何らかのエラーにより接続を処理できなかった場合はacceptsよりも小さくなることがあります（例: worker_connections の制限に達した場合）。
    • requests: クライアントから送られてきたリクエストの総数。Keep-Alive接続では、1つの接続で複数のリクエストが処理されるため、通常handledよりもrequestsの値は大きくなります。
  • Reading: Nginxがクライアントからのリクエストヘッダーを現在読み込んでいる接続数。
  • Writing: Nginxがクライアントにレスポンスを現在返送している接続数。
  • Waiting: Keep-Alive接続で、Nginxがクライアントからの次のリクエストを待機している接続数。これはActive connectionsに含まれます。この値が大きい場合、Keep-Alive接続が効率的に利用されていることを示唆しますが、同時に多くのワーカープロセスが待機状態の接続に占有されていることも意味します。

これらの数値は、特定のURLにアクセスすることで、テキスト形式で取得できます。このシンプルな形式は、人間が直接確認するだけでなく、スクリプトや監視ツールによる自動収集にも適しています。

他の監視方法との比較

ngx_http_stub_status_moduleは基本的なステータス監視に適していますが、Nginxの監視には他にも様々な方法があります。

  • アクセスログ/エラーログ解析: どのページにどれだけアクセスがあるか、レスポンスタイムはどうか、どのようなエラーが発生しているかなど、より詳細なリクエスト単位の情報が得られます。ただし、ログファイルの量が多くなると解析に手間がかかります。
  • OSレベルの監視: CPU使用率、メモリ使用率、ディスクI/O、ネットワークトラフィックなど、サーバー全体のリソース利用状況を把握できます。Nginxだけでなく、サーバー全体の健全性を確認する上で重要です。
  • Nginx Plus API: Nginxの商用版であるNginx Plusでは、より多くの詳細なメトリクス（キャッシュの状態、アップストリームサーバーの状態、SSL情報など）をJSON形式で取得できるAPIが提供されています。より高度な監視が必要な場合に有力な選択肢となります。
  • サードパーティ製監視ツール: Zabbix, Prometheus, Nagiosなどの監視ツールは、Nginxのステータス情報を定期的に収集し、グラフ化、アラート通知などの機能を提供します。ngx_http_stub_status_moduleで取得した情報をこれらのツールに取り込むのが一般的な監視方法です。
  • Nginxエクスポーター: Prometheus向けに開発されたnginx-exporterのようなツールは、ngx_http_stub_status_moduleだけでなく、アクセスログなどをパースしてより詳細なメトリクス（リクエストの総数、ステータスコード別のリクエスト数、帯域幅など）を提供します。

ngx_http_stub_status_moduleは、これらの方法の中で最も手軽に導入できる基本的なステータス監視機能と言えます。まずはこれを活用し、必要に応じて他の監視方法と組み合わせるのが現実的です。

ngx_http_stub_status_moduleの有効化

ngx_http_stub_status_moduleは、Nginxの標準モジュールの一つですが、Nginxをどのようにインストールしたかによって、モジュールがデフォルトで有効になっているかどうかが異なります。

モジュールの組み込み確認

現在インストールされているNginxにngx_http_stub_status_moduleが組み込まれているかどうかは、nginx -Vコマンドで確認できます。

bash
nginx -V

このコマンドを実行すると、Nginxのバージョン情報や、コンパイル時に指定されたオプションの一覧が表示されます。表示されたオプションの中に、--with-http_stub_status_moduleという文字列が含まれていれば、モジュールは有効になっています。

実行例:

nginx version: nginx/1.20.1
built by gcc 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)
built with OpenSSL 1.1.1f 31 Mar 2020
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-q7922W/nginx-1.20.1=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-compat --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_flv_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_mp4_module --with-http_perl_module=dynamic --with-http_random_index_module --with-http_secure_link_module --with-http_sub_module --with-http_xslt_module=dynamic --with-mail=dynamic --with-mail_ssl_module --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module --with-google_perftools_module --with-cpp_test_module --with-file-aio --with-ipv6 --with-http_dav_module

上記例では、--with-http_stub_status_moduleが含まれているため、モジュールは有効です。

多くのLinuxディストリビューションで提供されている標準パッケージからインストールした場合、このモジュールはデフォルトで有効になっていることが多いです。特に、UbuntuやDebianのnginx-fullパッケージや、CentOS/RHELの公式リポジトリからインストールしたNginxでは、通常有効になっています。

ソースコンパイルからの有効化

もしnginx -Vの出力に--with-http_stub_status_moduleが含まれていない場合、Nginxはソースコードからコンパイルされているか、モジュールが明示的に無効にされている可能性があります。このモジュールを有効にするには、Nginxを再コンパイルする必要があります。

ソースコンパイルの手順は以下のようになります。

  1. Nginxのソースコードを公式サイトからダウンロードします。
  2. ソースコードを展開したディレクトリに移動します。

  3. configureスクリプトを実行する際に、既存のオプションに加えて--with-http_stub_status_moduleオプションを追加します。

    bash
    ./configure --with-http_stub_status_module [既存のオプション...]
    注意: 既存のオプションをすべて含めることが重要です。nginx -Vで表示されたconfigure argumentsをコピー＆ペーストし、それに--with-http_stub_status_moduleを追加するのが最も確実な方法です。
    4. makeコマンドでコンパイルします。
    bash
    make
    5. 既存のNginxを停止し、新しいバイナリと設定ファイルを入れ替えます。make installを実行するとデフォルトの場所にインストールされますが、既存のNginx環境を上書きするため、慎重に行う必要があります。より安全な方法は、コンパイルしたバイナリを既存のNginxバイナリと手動で置き換えることです。
    “`bash

    既存のNginxバイナリの場所を確認 (例: /usr/sbin/nginx)

    which nginx

    既存のNginxを停止

    sudo systemctl stop nginx # または service nginx stop

    新しいバイナリで置き換え (バックアップ推奨)

    sudo cp /path/to/nginx_source/objs/nginx /usr/sbin/nginx

    設定ファイルなどを元の場所に戻す必要があれば行う

    Nginxを起動

    sudo systemctl start nginx # または service nginx start
    ``
    **警告**: バイナリの置き換えはリスクを伴います。必ず事前にバックアップを取り、テスト環境で十分に検証してから本番環境に適用してください。ディストリビューションのパッケージを使用している場合は、再コンパイルよりも、モジュールが含まれるパッケージ（例:    nginx-full`）をインストールし直す方が安全な場合があります。

再コンパイルが完了したら、再度nginx -Vコマンドを実行し、--with-http_stub_status_moduleが含まれていることを確認してください。

Nginx設定ファイルでのステータス表示設定

ngx_http_stub_status_moduleが有効になったら、次はNginxの設定ファイルにステータス情報を表示するための設定を追加します。これは、特定のURL（例: /nginx_status）へのアクセスに対して、ステータス情報を出力するように設定することで実現します。

基本設定の解説

ステータス表示の設定は、Nginxの設定ファイル（通常nginx.confまたはconf.dディレクトリ内の.confファイル）の中で行います。最も一般的な方法は、serverブロック内の特定のlocationブロックを使用することです。

“`nginx
server {
listen 80; # または listen 443 ssl;
server_name your_domain.com; # または localhost;

# 他のlocationブロック...

location /nginx_status {
    stub_status on; # このディレクティブがステータス表示を有効にする

    # セキュリティのため、アクセス元を制限することが非常に重要です
    # 例: ローカルホストからのみアクセスを許可
    allow 127.0.0.1;
    deny all; # それ以外のすべてのアクセスを拒否
}

# 他のlocationブロック...

}
“`

  • location /nginx_status: これは、/nginx_statusというパスへのリクエストをこのブロックで処理することを意味します。パス名は何でも構いませんが、一般的に/nginx_statusや/statusなどが使われます。他のアプリケーションが使用しない、かつ推測されにくいパス名を選ぶとセキュリティが高まります。
  • stub_status on;: このディレクティブが、そのロケーションでngx_http_stub_status_moduleによるステータス情報の出力を有効にします。

  • allow IP_ADDRESS; / deny all;: この設定は極めて重要です。 ステータス情報にはサーバー内部の状態に関する情報が含まれており、悪意のある第三者に知られるとセキュリティリスクとなる可能性があります。そのため、ステータス情報ページへのアクセスは、信頼できるIPアドレス（通常はサーバー自身を示す127.0.0.1や、監視サーバーのIPアドレスなど）からのみ許可し、それ以外のすべてのアクセスを拒否するべきです。

    • allow IP_ADDRESS;: 指定したIPアドレスまたはネットワークからのアクセスを許可します。複数指定可能です。
    • deny all;: それ以外のすべてのアクセスを拒否します。
    • allow 127.0.0.1; allow ::1; deny all;: IPv4のローカルホスト(127.0.0.1)とIPv6のローカルホスト(::1)からのアクセスのみを許可し、その他を拒否する設定例です。
    • allow 192.168.1.0/24; deny all;: 特定のサブネット全体からのアクセスを許可する例です。
    • allow 10.0.0.100; allow 192.168.1.200; deny all;: 複数の特定のIPアドレスからのアクセスを許可する例です。

警告: allowとdenyの設定を誤ると、ステータスページがインターネット全体に公開されてしまい、セキュリティ上の問題を引き起こす可能性があります。設定後は必ず意図した通りにアクセス制限がかかっているかを確認してください。

設定ファイルの場所

Nginxの設定ファイルは、オペレーティングシステムやインストール方法によって配置場所が異なります。一般的な場所は以下の通りです。

  • /etc/nginx/nginx.conf (メイン設定ファイル)
  • /etc/nginx/conf.d/*.conf (メイン設定ファイルからインクルードされることが多い)
  • /etc/nginx/sites-available/ と /etc/nginx/sites-enabled/ (Debian/Ubuntu系でバーチャルホストを管理する際に使われる)

通常は、/etc/nginx/conf.d/status.confのような新しいファイルを作成し、その中にステータス表示用のserverブロック（あるいは既存のserverブロック内にlocationブロック）を記述するのが管理しやすく推奨されます。

設定例（ローカルホストからのアクセスのみ許可）

最も安全な設定は、サーバー自身（ローカルホスト）からのみアクセスを許可する設定です。

“`nginx

/etc/nginx/conf.d/status.conf (または任意のconfファイル)

server {
listen 80;
# listen 443 ssl; # SSLでアクセスしたい場合はこちらも追加
server_name localhost; # ローカルホストからのアクセスを想定

location /nginx_status {
    stub_status on;
    access_log off; # ステータスページへのアクセスログは不要な場合が多いので無効化
    allow 127.0.0.1; # IPv4 ローカルホスト
    allow ::1;       # IPv6 ローカルホスト
    deny all;
}

}
“`

この設定では、ポート80番でlocalhostにアクセスした場合のみ、/nginx_statusパスでステータス情報が表示されます。外部からのアクセスはすべて拒否されます。監視ツールが別のサーバーで動作している場合は、allowディレクティブに監視サーバーのIPアドレスを追加する必要があります。

設定反映方法

設定ファイルを編集したら、Nginxに設定を再読み込みさせて反映させる必要があります。設定ミスがないかを確認してから再読み込みするのが安全です。

  1. 設定ファイルの文法チェック:
    bash
    sudo nginx -t
    このコマンドは設定ファイルの文法エラーをチェックします。syntax is ok と test is successful が表示されれば問題ありません。もしエラーが表示された場合は、メッセージに従って設定ファイルを修正してください。

  2. Nginxの設定再読み込み:
    bash
    sudo nginx -s reload
    または systemd を使用している場合:
    bash
    sudo systemctl reload nginx
    このコマンドは、Nginxのマスタープロセスに設定ファイルを再読み込みするシグナルを送ります。Nginxプロセス自体は停止しないため、サービスを中断することなく設定を反映できます。

設定が正常に反映されれば、指定したURL（例: http://localhost/nginx_status または http://your_server_ip/nginx_status）にアクセスすることで、ステータス情報が表示されるようになります。

ステータス情報の取得と見方

設定が完了しNginxを再起動またはリロードしたら、実際にステータス情報にアクセスしてみましょう。

ステータス情報の取得

Webブラウザ、curlコマンド、または他のHTTPクライアントを使用して、設定で指定したURLにアクセスします。

Webブラウザからのアクセス:

設定例でローカルホストからのアクセスのみを許可した場合、Nginxサーバー自身にログインし、そのサーバー上で動作するWebブラウザ（あるいはSSHポートフォワーディングなど）からhttp://localhost/nginx_statusにアクセスします。リモートからのアクセスを許可している場合は、許可したIPアドレスを持つマシンから通常のブラウザでアクセスできます。

curlコマンドを使った取得:

サーバーのコンソールから、またはリモートアクセスを許可している場合は別のマシンから、curlコマンドを使ってステータス情報を取得するのが一般的です。

bash
curl http://localhost/nginx_status

リモートサーバーの特定のIPアドレスに対してアクセスする場合は、そのIPアドレスとポートを指定します。

bash
curl http://your_server_ip/nginx_status

もしSSL/TLSで保護されたサイトのステータスをHTTPSで取得したい場合は、httpsスキームと対応するポート（通常443）を指定します。

bash
curl https://localhost/nginx_status --insecure # 自己署名証明書などの場合は --insecure が必要になる場合があります

出力形式の解説

curlコマンドで取得した場合の出力は、以下のようなシンプルなテキスト形式になります。

Active connections: 291
server accepts handled requests
46107 46107 54692
Reading: 6 Writing: 11 Waiting: 274

これがngx_http_stub_status_moduleが出力するステータス情報です。各行と数値の意味を詳しく見ていきましょう。

  1. Active connections: 291

    • 意味: 現在アクティブなクライアント接続の総数です。これには、Nginxが現在処理しているすべての接続（リクエストヘッダーの読み込み中、レスポンスの返送中、Keep-Alive待機中）が含まれます。
    • 見方: この数値はリアルタイムのサーバーの負荷を示します。通常、アクセスが多い時間帯に高くなり、少ない時間帯に低くなります。サーバーのリソース（特にワーカープロセスの数やネットワーク帯域）に対して、この数値が持続的に高い場合、サーバーがボトルネックになっている可能性があります。worker_connectionsディレクティブで設定された最大接続数に近づいている場合は、接続を受け付けられなくなる可能性があります。

  2. server accepts handled requests の行

    • これは3つの累積値（Nginxが起動または最後の再読み込み以降の合計）が表示されます。
    • 46107 (accepts)
      • 意味: Nginxが正常に受け入れた接続の総数です。TCPハンドシェイクが正常に完了し、Nginxが接続を受け付けた回数を示します。
      • 見方: この数値はサーバーへの総接続数を把握するのに役立ちます。
    • 46107 (handled)
      • 意味: Nginxが処理した接続の総数です。これは、Nginxがクライアントにレスポンスを返すなど、何らかの処理を完了した接続の数です。
      • 見方: 通常、この値はacceptsと同じか非常に近い値になります。もしacceptsよりもhandledが著しく小さい場合、Nginxが接続を受け付けたにも関わらず、内部的なリソース制限（例: worker_connectionsの上限到達）やエラーなどにより、その接続を正常に処理できなかった可能性を示唆します。
    • 54692 (requests)
      • 意味: クライアントから送られてきたHTTPリクエストの総数です。
      • 見方: Keep-Alive接続が有効な場合、1つのTCP接続内で複数のHTTPリクエストが処理されます。そのため、requestsの値はhandledの値よりも大きくなります。requests / handled の比率は、Keep-Alive接続の効率を示す指標の一つとなります。この比率が高いほど、Keep-Aliveが有効に機能していると言えます。

  3. Reading: 6 Writing: 11 Waiting: 274 の行

    • これらは、現在アクティブな接続の内訳をさらに詳細に示したものです。これらの値の合計は、理論的にはActive connectionsの値と一致するはずですが、微妙にずれる場合もあります。
    • Reading: 6
      • 意味: 現在、Nginxがクライアントからのリクエストヘッダーを読み込んでいる状態の接続数です。
      • 見方: この数値が高い場合、クライアントからのリクエスト送信が遅い（ネットワーク帯域が狭い、クライアント側の問題など）か、あるいはNginxのワーカープロセスがリクエストボディの読み込みに時間がかかっている（例: 大量のファイルをアップロードしている）可能性を示唆します。
    • Writing: 11
      • 意味: 現在、Nginxがクライアントにレスポンスボディを返送している状態の接続数です。
      • 見方: この数値が高い場合、サーバーからのレスポンス生成に時間がかかっているか（バックエンドの遅延など）、あるいはクライアントへのデータ転送に時間がかかっている（クライアント側の受信帯域が狭いなど）可能性を示唆します。大きなファイルを配信している場合などに高くなる傾向があります。
    • Waiting: 274
      • 意味: Keep-Alive接続で、前のリクエストの処理が完了し、次のリクエストが来るのを待機している状態の接続数です。
      • 見方: この数値が高い場合、Keep-Alive接続が有効に機能しており、TCP接続の再確立オーバーヘッドを削減できていることを意味します。しかし、ワーカープロセスは待機中の接続にも割り当てられるため、あまりに多くの待機接続があると、新しい接続を受け付けるためのワーカープロセスが不足する可能性があります。keepalive_timeoutやkeepalive_requestsの設定が適切か検討する際の参考になります。

監視における重要性

これらの数値を単独で見るだけでなく、継続的に監視し、その推移や相互の関係性を見ることが重要です。

  • Active connectionsの急増: サーバーへのアクセスが急増しているか、あるいは何らかの原因でリクエスト処理が遅延している可能性。CPUやメモリなどのリソース使用率と合わせて確認する。
  • acceptsとhandledの差: この差が大きい場合、worker_connectionsの制限到達やOSレベルでの接続確立失敗など、Nginxが接続を正常にさばけていない可能性がある。
  • requests / handled の比率が低い: Keep-Alive接続があまり活用されていない可能性。クライアント側の設定やNginxのKeep-Alive関連設定を見直す。
  • Readingが高い: クライアント側のネットワークやリクエストボディ送信に問題がある可能性、あるいはアップロード処理が多いか。
  • Writingが高い: サーバー側のレスポンス生成遅延（バックエンド問題）や、クライアント側のダウンロード遅延（大容量コンテンツ配信など）の可能性。
  • Waitingが高い: Keep-Aliveは有効だが、待機接続が多すぎて新しい接続を圧迫していないか注意。keepalive_timeoutを短くすることも検討できる。

これらの指標を、サーバーのCPU、メモリ、ネットワークトラフィック、ディスクI/OといったOSレベルのメトリクスや、アプリケーションのログ、レスポンスタイムなどと合わせて総合的に判断することで、サーバーの状態をより正確に把握し、問題の原因を特定しやすくなります。

ステータス情報の応用

ngx_http_stub_status_moduleから取得できる情報はシンプルですが、これ単体で利用するだけでなく、様々な監視ツールやスクリプトと組み合わせることで、より効果的な監視システムを構築できます。

監視ツールとの連携

Zabbix、Prometheus、Nagios、Datadogなどの多くの監視ツールは、Nginxのステータス情報を収集するための機能やプラグインを提供しています。これらのツールは、定期的にNginxのステータスページにアクセスし、取得した数値をデータベースに保存し、グラフ化したり、閾値に基づいてアラートを通知したりすることができます。

連携の基本的な流れは以下のようになります。

  1. 監視ツールのエージェントまたはポーリング機能の設定: 監視ツールがNginxサーバー上のステータスページ（例: http://localhost/nginx_status）にHTTPリクエストを送信するように設定します。
  2. 取得したデータのパース: 監視ツール側で、取得したテキストデータから各数値（Active connections, accepts, handled, requests, Reading, Writing, Waiting）を抽出（パース）します。
  3. データベースへの保存: 抽出した数値を時系列データとしてデータベースに保存します。
  4. グラフ化: 保存されたデータをグラフとして可視化し、時間による変化やトレンドを把握できるようにします。
  5. アラート設定: 特定のメトリクス（例: Active connections）が設定した閾値（例: 500接続）を超えた場合や、特定の時間内にrequestsの値が増加しない（Nginxが停止している）場合などに、管理者にアラートを通知するように設定します。

多くの監視ツールには、curlコマンドの結果をパースするための柔軟な設定オプションや、専用のNginx監視テンプレートが用意されています。

スクリプトによるデータ収集とグラフ化

専用の監視ツールを導入するのが難しい場合でも、シンプルなスクリプトと汎用的なデータ処理ツールを組み合わせて、ステータス情報を収集・可視化することは可能です。

例えば、Bashスクリプトとawk、そして時系列データベース（InfluxDBなど）やグラフ描画ツール（Grafanaなど）を組み合わせる方法があります。

データ収集スクリプトの例 (Bash + awk):

“`bash

!/bin/bash

STATUS_URL=”http://localhost/nginx_status”
OUTPUT_FILE=”/var/log/nginx/status_metrics.log” # 出力先ファイル

curlでステータス情報を取得し、grepで必要な行を抽出

STATUS_DATA=$(curl -s $STATUS_URL | grep -E ‘Active connections:|Reading:|server accepts handled requests’)

抽出したデータから数値をawkでパース

Active connections

ACTIVE=$(echo “$STATUS_DATA” | awk ‘/Active connections:/ {print $3}’)

accepts handled requests

ACCEPT_HAND_REQ=$(echo “$STATUS_DATA” | awk ‘/server accepts handled requests/ {print $1, $2, $3}’)
read ACCEPTS HANDLED REQUESTS <<< “$ACCEPT_HAND_REQ”

Reading Writing Waiting

READ_WRITE_WAIT=$(echo “$STATUS_DATA” | awk ‘/Reading:/ {print $2, $4, $6}’)
read READING WRITING WAITING <<< “$READ_WRITE_WAIT”

タイムスタンプとともにファイルに出力 (例: CSV形式)

echo “$(date +’%Y-%m-%d %H:%M:%S’),$ACTIVE,$ACCEPTS,$HANDLED,$REQUESTS,$READING,$WRITING,$WAITING” >> $OUTPUT_FILE

cronなどで定期的に実行 (例: 1分ごと)

*/1 * * * * /path/to/your_script.sh

“`

このスクリプトは、curlでステータスを取得し、awkやreadを使って各数値を抽出し、タイムスタンプとともにCSV形式でファイルに追記していきます。

収集したCSVファイルは、後からExcelやスプレッドシートで開いてグラフ化したり、専用のデータ処理ツールに取り込んだりすることができます。より高度な方法としては、スクリプトから直接時系列データベース（InfluxDBなど）に書き込むことも可能です。

Prometheus Exporterの紹介:

PrometheusでNginxを監視する場合、nginx-exporterというサードパーティ製の公式ではないエクスポーターがよく利用されます。これはngx_http_stub_status_moduleから情報を取得するだけでなく、さらに詳細な情報（ステータスコード別のリクエスト数、バイト数など）をPrometheusが解釈できる形式で提供してくれます。もしngx_http_stub_status_moduleで得られる情報だけでは不十分な場合、このようなエクスポーターの導入も検討する価値があります。ただし、nginx-exporterは別途インストール・実行が必要になります。

アラート設定の考え方

収集したメトリクスに基づいてアラートを設定することで、問題発生時に即座に気づくことができます。基本的なアラート設定の考え方をいくつか示します。

  • Active connectionsが閾値を超えた: サーバーの処理能力が限界に近づいている可能性。ハードウェアリソースの枯渇や、アプリケーションサーバーの応答遅延などが考えられます。サーバーのリソース監視と合わせて確認が必要です。閾値はサーバーのスペックや通常の負荷状況に応じて設定します。
  • acceptsとhandledの差が増加傾向にある: Nginxが接続を正常に処理できていない可能性。worker_connectionsの上限やOSレベルのファイルディスクリプタ上限などを確認します。
  • 特定の時間内にrequestsが増加しない: Nginxプロセスが停止している可能性。サービス稼働監視としても利用できます。
  • ReadingやWritingが異常に高い状態が続く: クライアントやバックエンドとの通信に問題がある可能性。特定の遅延している接続を特定するための詳細なログ分析などが必要になる場合があります。
  • Waitingが急激に低下: Keep-Alive接続が何らかの原因で切断されやすくなっている可能性。

アラートの閾値は、実際の運用の中で通常の負荷状況を把握し、ベースラインを設定することから始めます。急激な変化や、通常ではありえない高い/低い値を検知するように設定することで、ノイズの少ない効果的なアラートを実現できます。

よくある問題とトラブルシューティング

Nginxステータスページの設定やアクセスで遭遇する可能性のある問題と、そのトラブルシューティング方法について解説します。

ステータスページにアクセスできない

設定したURLにアクセスしてもステータス情報が表示されない場合、いくつかの原因が考えられます。

  1. Nginx設定の誤り:

    • stub_status on; ディレクティブが正しく設定されていないか、意図しないlocationブロックに設定されている。
    • locationブロックのパスが間違っている。
    • serverブロックが設定されているポート番号やserver_nameと、アクセスしているURLが一致していない。
    • 対処法: sudo nginx -tで設定ファイルの文法エラーを確認します。エラーがなければ、設定ファイルを再度確認し、stub_status on;が意図したlocationブロック内にあり、かつそのlocationブロックにアクセスするためのserver_nameやlistenポートが正しいか確認します。設定変更後はsudo nginx -s reloadを忘れずに実行します。

  2. アクセス制限の設定誤り:

    • allowやdenyディレクティブの設定により、アクセス元のIPアドレスが拒否されている。最もよくある原因の一つです。
    • 対処法: 設定ファイルでallowディレクティブにアクセス元IPアドレスが含まれているか、deny all;より前にallowが来ているか（Nginxのアクセス制御ディレクティブは記述順に評価されます）を確認します。監視サーバーなどからのアクセスを許可する場合は、そのサーバーの正しいIPアドレスをallowに追加します。ローカルホストからのアクセスを試している場合は、allow 127.0.0.1; (IPv4) や allow ::1; (IPv6) が設定されているか確認します。一時的に# deny all;のようにコメントアウトしてアクセスできるか試すことも有効ですが、テスト後は必ず元に戻すか適切な制限を設定してください。

  3. ファイアウォールの設定:

    • サーバーのファイアウォール（iptables, firewalld, ufwなど）が、ステータスページを公開しているポート（通常80または443）へのアクセスを、監視元IPアドレスから拒否している。
    • 対処法: サーバー上で動作しているファイアウォールの設定を確認し、監視元IPアドレスからの指定ポートへのアクセスを許可するルールを追加します。例えば、ufwを使用している場合: sudo ufw allow from your_monitoring_server_ip to any port 80 proto tcp。telnet your_server_ip 80のようなコマンドで、監視元からサーバーのポートに接続できるか確認することも有効です。

  4. Nginxプロセスが実行されていない:

    • Nginx自体が停止している場合、当然ステータスページにもアクセスできません。
    • 対処法: sudo systemctl status nginx (systemdの場合) や sudo service nginx status (SysVinitの場合) コマンドでNginxの稼働状態を確認します。停止している場合は、起動を試みます。

値が異常に高い/低い

ステータス情報が表示されても、その数値が予想外に高いまたは低い場合があります。

  • Active connectionsが常に高い:
    • 原因: サーバーへのアクセスが多い、またはリクエスト処理が遅延している可能性があります。
    • 調査: サーバーのCPU、メモリ、ネットワークなどのリソース使用率を確認します。Nginxのワーカープロセスが大量に起動していないか（ps aux | grep nginx）、エラーログに大量のエラーが出ていないか確認します。バックエンドのアプリケーションサーバーやデータベースがボトルネックになっている可能性も考えられます。
  • acceptsとhandledの差が大きい:
    • 原因: worker_connectionsの上限に達しているか、OSレベルでの接続確立制限に引っかかっている可能性があります。
    • 調査: worker_connectionsの設定値を確認します。OSレベルのファイルディスクリプタの上限（ulimit -nや/etc/security/limits.conf）を確認・調整します。Nginxのエラーログに接続関連のエラーが出ていないか確認します。
  • requests / handled の比率が非常に低い:
    • 原因: Keep-Alive接続が有効になっていないか、クライアント側がKeep-Aliveをサポートしていない/無効にしている可能性があります。
    • 調査: Nginx設定でkeepalive_timeoutやkeepalive_requestsが適切に設定されているか確認します。クライアント（WebブラウザやAPIクライアント）がKeep-Aliveを有効にしているか確認します。
  • Readingが常に高い:
    • 原因: クライアントからのリクエスト送信が遅いか、アップロード処理が多い。
    • 調査: サーバー側のネットワーク帯域に問題がないか、クライアント側のネットワーク環境はどうか確認します。大きなファイルのアップロードを受け付けている場合は正常な挙動の可能性があります。
  • Writingが常に高い:
    • 原因: サーバーからのレスポンス生成が遅い（バックエンドの遅延）か、クライアントへのデータ転送が遅い（大容量コンテンツ配信など）。
    • 調査: バックエンドのアプリケーションサーバーやデータベースのパフォーマンスを確認します。Nginxが静的ファイルを配信している場合は、ディスクI/Oやネットワーク帯域を確認します。大きなファイルを配信している場合は正常な挙動の可能性があります。
  • Waitingが常に低い:
    • 原因: Keep-Alive接続が有効になっていないか、有効でもすぐに切断されている。
    • 調査: keepalive_timeoutが短すぎる、またはクライアント側でKeep-Aliveが無効になっている可能性があります。

ワーカープロセスとの関係

Nginxは通常、マスタープロセスと複数のワーカープロセスで動作します。ステータス情報は、これらのワーカープロセス全体の状態を集計したものです。

  • Active connectionsは、すべてのワーカープロセスが現在処理している接続の合計です。
  • Reading, Writing, Waitingも同様に、すべてのワーカープロセスの状態を合算したものです。
  • accepts, handled, requestsは、Nginxの起動またはリロード以降の累積値であり、これもすべてのワーカープロセスによる処理の合計です。

worker_processesディレクティブで設定されたワーカープロセスの数は、Nginxが同時に処理できる接続数に影響を与えます。Active connectionsがworker_processes * worker_connectionsの値に近づく場合、Nginxは新しい接続を受け付けられなくなる可能性があります。ステータス情報を確認する際は、これらの設定値も考慮に入れることが重要です。

より高度な監視方法の紹介

ngx_http_stub_status_moduleは基本的な監視に役立ちますが、より詳細な情報や高機能な監視が必要な場合は、以下の方法も検討できます。

Nginx Plus API (商用版)

Nginx Plusは、Nginxの商用版であり、無料版にはない様々な機能を提供しています。その一つが、JSON形式で詳細なメトリクスを提供するRESTful APIです。このAPIを利用すると、以下のようによりリッチな情報が得られます。

  • 個々のサーバーブロック、アップストリームグループ、キャッシュに関する詳細な統計情報
  • アクティブ、アイドル、ドレインなどの状態ごとの接続数の内訳
  • リクエスト処理に関する詳細なメトリクス（ヘッダー読み込み時間、ボディ読み込み時間、応答時間など）
  • SSL/TLS接続に関する情報
  • レート制限や帯域制限に関する情報

Nginx Plus APIは構造化されたデータを提供するため、監視ツールとの連携が容易であり、より詳細な分析や複雑なアラート設定が可能になります。大規模な環境やミッションクリティカルなサービスでNginxを使用している場合は、Nginx PlusとそのAPIを検討する価値があります。

サードパーティ製モジュール

Nginxの機能を拡張するために、様々なサードパーティ製モジュールが存在します。中には、ngx_http_stub_status_moduleよりも詳細なステータス情報を提供するモジュールもあります。例えば、リクエストごとの詳細な処理時間や、特定のパスへのアクセス統計などを取得できるモジュールがあります。これらのモジュールを利用するには、Nginxをソースコードからコンパイルし、モジュールを組み込む必要があります。導入の際は、モジュールの信頼性やメンテナンス状況を十分に確認することが重要です。

ログ解析

Nginxのアクセスログやエラーログを解析することも、重要な監視手法の一つです。

  • アクセスログ: 各リクエストの詳細（クライアントIP、リクエストメソッド、URL、ステータスコード、レスポンスサイズ、処理時間、リファラ、ユーザーエージェントなど）が記録されています。これを解析することで、どのページへのアクセスが多いか、レスポンスが遅いリクエストは何か、どのようなクライアントからアクセスがあるかなどを把握できます。Elasticsearch, Logstash, Kibana (ELKスタック) や Splunk のようなログ分析ツールと連携することで、高度なログ解析と可視化が可能です。
  • エラーログ: Nginxの起動エラー、設定エラー、ファイルアクセスエラー、バックエンドとの通信エラーなど、サーバー内部で発生した問題に関する情報が記録されます。エラーログを監視することで、問題発生を早期に検知し、原因究明に役立てることができます。

ログ解析はリクエスト単位の詳細な情報が得られるという点で、ngx_http_stub_status_moduleとは異なるタイプの監視です。両者を組み合わせることで、サーバー全体の状態と個々のリクエストの挙動の両面から監視を行うことができます。

まとめ

この記事では、Nginxの基本的なステータス監視機能であるngx_http_stub_status_moduleについて、その有効化、設定、そしてステータス情報の見方を詳細に解説しました。

  • ngx_http_stub_status_moduleは、現在のアクティブな接続数、受け付け/処理された接続数、リクエスト数、そしてReading/Writing/Waitingの状態にある接続数といった、Nginxサーバーの基本的な状態を示す情報を提供します。
  • このモジュールは、Nginxをソースコードからコンパイルする際に--with-http_stub_status_moduleオプションを付けてビルドするか、多くのパッケージインストール済みNginxでデフォルトで有効になっています。nginx -Vコマンドで確認できます。
  • ステータス情報を表示するためには、Nginx設定ファイル（nginx.confなど）の中で、特定のlocationブロックにstub_status on;ディレクティブを設定する必要があります。
  • セキュリティ上の理由から、ステータスページへのアクセスは、必ず信頼できるIPアドレス（ローカルホストや監視サーバーなど）からのみに制限することが極めて重要です。 allowおよびdenyディレクティブを適切に使用します。
  • 設定を反映させるには、nginx -tで文法チェックを行い、nginx -s reloadまたはsystemctl reload nginxを実行します。
  • ステータス情報は、Webブラウザやcurlコマンドで設定したURLにアクセスすることで取得できます。
  • 出力される各数値（Active connections, accepts, handled, requests, Reading, Writing, Waiting）は、それぞれサーバーの異なる側面（現在の負荷、接続処理能力、Keep-Alive効率、データ転送状況など）を示しており、これらの数値を継続的に監視し、OSレベルのメトリクスやログ情報と組み合わせることで、サーバーの健全性を把握し、パフォーマンスの問題を特定する重要な手がかりとなります。
  • ngx_http_stub_status_moduleで得られる情報は、ZabbixやPrometheusといった監視ツールに取り込むことで、グラフ化やアラート通知といった自動監視システムを構築するための基盤となります。

ngx_http_stub_status_moduleは非常にシンプルでありながら、Nginxサーバーの基本的な状態を把握するための強力なツールです。Nginxを運用されている方であれば、まずこの機能から活用を始めることを強く推奨します。

継続的な監視は、安定したサービス提供には欠かせません。今回ご紹介した基本的な監視方法を実践し、必要に応じてより高度なツールや手法と組み合わせて、ご利用のNginxサーバーを常に最良の状態に保ちましょう。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール