NGINX スタブステータス：Webサーバーの稼働状況をリアルタイムで監視する

NGINXのスタブステータスが示すもの

NGINX スタブステータス 設定されたHTTPエンドポイントを通じて、基本的なWebサーバーのメトリクスをテキスト形式で提供します。 この応答には、クエリの対象となったNGINXプロセス群のアクティビティ、特にクライアント接続数や総リクエスト数が記載されています。完全なモニタリングシステムを導入していなくても、ローカルでこの情報を取得し、繰り返し比較することができます。

その際、2種類の値を区別する必要があります。1つは スナップショット たとえば、取得時にアクティブなクライアント接続の数を表示します。合計カウンターとしては、 requests 一方、これらは合計でいくつの問い合わせがあったかを示しているに過ぎない。既知の時間間隔で測定された複数の計測値を比較して初めて、問い合わせ率について判断することができる。

これらの数値は、CPUやメモリの使用率を直接測定したものではなく、Webサーバーの空き容量に対する割合を示すものでもありません。開いている接続数が多い場合、その原因やコストは様々です。そのため、実際の負荷を評価するには、リソースメトリクスに加え、応答時間やエラーに関する情報も必要となります。

Stub Statusは、数値を仮想サイトやリクエストされたURLごとに分類していません。1つのインストール環境で複数のサイトを運用している場合、エンドポイントの情報だけでは、どのサイトがトラフィックの増加の原因であるかを特定することはできません。複数のNGINXインスタンスがある場合は、それぞれの値を個別に記録し、明確に割り当てる必要があります。

ステータスページの閲覧自体もHTTPリクエストであり、監視対象のカウンター値にわずかな影響を与えます。リクエスト数が少ない場合や、非常に頻繁にクエリを実行する場合は、この点を考慮する必要があります。いずれにせよ、1回の閲覧だけでは一部の情報しか得られず、アクティビティに変化があるかどうかは、その推移を見て初めて判断できます。

「接続」と「問い合わせ」の違い

その価値 アクティブな接続 アクティブなクライアント接続（待機中の接続を含む）を網羅しています。つまり、現在応答が送信されている接続のみをカウントするわけではありません。「Reading」、「Writing」、「Waiting」というステータスは、この総数を把握するのに役立ちますが、CPU使用率や稼働中のアプリケーションの数を示すものではありません。

着信リクエストの場合、NGINXがリクエストヘッダーを読み取っている間は、接続は「Reading」状態になります。 その後、NGINXが応答を処理または書き出しを行う際に、接続状態が「Writing」に変わる場合があります。これは、その間ずっと実際にクライアントへデータが送信されていることを意味するわけではありません。アップストリームからの応答を待機している場合も、この状態に含まれることがあります。

回答後も、さらなる問い合わせのための接続が開いたままになっている場合、それは 待機中 として表示されます。この状態には、次のリクエストを待機している非アクティブなクライアント接続が含まれます。したがって、Waitingの値が高いことだけでは過負荷を証明するものではなく、再利用可能な接続が多い運用状況でもこの値が高くなることがあります。

接続とリクエストは異なる概念です。1つのキープアライブ接続を介して、複数のリクエストが連続して送信されることがあります。 HTTP/2では、1つの接続を介して複数のリクエストを送信できます。そのため、開いている接続数からリクエストの数を確定的に推測することはできず、requestsカウンターは接続カウンターと同じ比率で増加するとは限りません。

実用的な評価を行うには、複数のアクセス結果を踏まえて比較することが有効です。応答時間やエラーに異常が見られないにもかかわらず「Waiting」が増加している場合、それはあくまで観察結果であり、アラームの根拠とはなりません。再利用とその制限をどのように設定できるかについては、以下の記事で解説しています。 NGINXのキープアライブリクエスト.

モジュールとバージョンを確認する

Stub Status を使用するには、以下のモジュールを搭載した NGINX のインストール環境が必要です。 ngx_http_stub_status_module、その設定へのアクセス、および後日、指定されたネットワーク空間から保護されたエンドポイントを照会する機能。このモジュールは、NGINXのビルド時にはデフォルトでは組み込まれていません。ディストリビューションパッケージに含まれているかどうかは、各パッケージによって異なるため、現地で確認する必要があります。

ターミナルで、サービスが実際に使用している NGINX バイナリファイルのバージョンと `configure` パラメータを確認してください。以下のコマンドでこれらの情報が表示されます。パラメータの中には、 --with-http_stub_status_module 対応するビルドオプションを参照してください。

nginx -V

決定的な要因は 正しいバイナリファイル: 検索パス経由で起動された nginx そのインストールは、サービスが実行しているものとは異なる可能性があります。不明な点がある場合は、サービスの設定と、そこで使用されているプログラムの起動方法を確認してください。その後、必要に応じて、別のインストールの出力から本番サービスについて推測するのではなく、該当するバイナリファイルを明示的に呼び出してください。

バージョンも、このディレクティブの記述方法に影響を与えます。NGINX 1.7.5 以降では、 stub_status 引数なしで使用されます。以前のバージョンでは、任意の引数（例えば on. バージョンの上限は互換性に関する情報であり、お使いのシステムにどのバージョンがインストールされているかについての推測ではありません。

検証対象のインストール環境にビルドオプションがない場合は、設定を変更する前に、その環境においてどのパッケージまたはビルドが想定されているかを確認する必要があります。ステータス・ロケーションだけでは、不足しているモジュールを補うことはできません。パッケージやサービス設定の変更については、所定の運用および承認手順に従う必要があります。

保護されたステータスエンドポイントを設定する

ローカルのステータスを照会するには、別の ループバック・リスナー 設定する。以下の例は、既存の http-コンテキストであり、ターミナルコマンドではありません。これを実行するには、スタブステータスモジュールが利用可能であり、対象のアドレスにおけるサンプルポート8088が他のサービスによって既に使用されていないことが前提となります。

server {
    listen 127.0.0.1:8088;
    server_name localhost;

    location = /stub_status {
        stub_status;
        allow 127.0.0.1;
        deny all;
    }
}

～との結びつき 127.0.0.1 このリスナーをローカルのIPv4ループバックインターフェースに限定します。正確なロケーションは、指定されたパスにのみ割り当てられます。ディレクティブ stub_status そこでステータスデータを提供します。これにより、他のWebサイトが公開されているかどうかに関わらず、このリスナーには他のIPv4インターフェースからはアクセスできなくなります。

仝 アクセスルール バインディングを補完します：NGINXは、最初のヒットが見つかるまで順にチェックします。 ローカルのIPv4アドレスは許可され、それ以外のアドレスはすべて拒否されます。このロケーションには独自のルールが設定されているため、上位コンテキストのアクセスルールは追加で継承されません。したがって、この例を適用する前に、設定全体を必ず確認してください。

コンテナの場合、ネットワーク空間が鍵となります。別のコンテナ内にあるエクスポーターは、独自の localhost 通常、NGINXコンテナのループバックインターフェースは公開されません。リモートからのアクセスには、事前に計画されたプライベートな接続経路と、適切なアクセス制御が必要です。ステータスページは、運用情報が含まれているため、安易に公開しないでください。

設定の確認とステータスの取得

入力後、まずターミナルで設定を確認してください。 以下のコマンドは構文をチェックし、参照されているファイルを開こうとします。その際、サービスに適切なNGINXバイナリファイルと、必要に応じて異なる設定パスを使用してください。検証が成功しても、変更はまだ有効になりません。

nginx -t

A 承認済みのリロード これは独立した実行手順です。承認を得た上で、お使いの環境の運用手順に従って実行してください。 リロード時、NGINXは設定を再読み込みし、新しい設定で新しいワーカーを起動するとともに、古いワーカーを順序立てて終了させます。構文チェックに合格したからといって変更が有効になったと推測するのではなく、その後、変更が正常に反映されたかどうかの確認とログの確認を行ってください。

有効化が承認された後、同じネットワーク空間内にあるエンドポイントに対して、ローカルで curl 照会する。このスイッチは -i レスポンス本文に加え、HTTPステータスやヘッダーも表示します。以下の例では、ファイル設定からリスナーとパスが設定されていることを前提としています。

curl -i http://127.0.0.1:8088/stub_status

ステータスデータを含む正常なHTTPレスポンスが返されることが期待されます。 テキスト、JSON形式ではありません。エラーが発生した場合は、ステータスコードとNGINXのログを参考に原因を特定できます。ただし、ローカルでの取得に成功したとしても、それは単にこのアクセス経路が機能していることを示すだけであり、他の設定によってエンドポイントが外部からアクセス可能になっていないことを証明するものではありません。

ステータス値の読み取りとレートの計算

この出力は、現在の接続状態と累積値を組み合わせて表示しています。解釈にあたっては、個々の値の絶対的な大きさよりも、この区別の方が重要です。例えば、 現在値 これは、取得時の状態を表しており、総カウント数はそれまでにカウントされたイベントの数を示しています。この表では、個々のフィールドと、よくある誤った結論を分類しています。

メーターから requests 平均値は 問い合わせ率 ある区間について計算するには：最初の数値から2番目の数値を差し引き、その差を経過秒数で割る。 計算例（実際の測定値ではありません）：60秒間で値が12,000から12,600に増加した場合、600を60で割ると、1秒あたりの平均リクエスト数は10回となります。

この平均値は、短期的なピーク値を示すものでもなければ、どのURLにアクセスされたかを示すものでもありません。 各アクセスについて、その時刻とアクセスされたインスタンスを記録してください。カウンターの数値が減少した場合や、インスタンスを切り替えた場合は、単純な差分を検証せずにレートとして解釈してはなりません。そのインスタンスについては、新しい比較データ系列を開始してください。

長さの異なる間隔を比較する場合は、計画された取得間隔ではなく、実際に経過した時間を基に計算してください。 例えば、2分以上遅れて行われる照会には、1分後の照会とは異なる除数が必要となります。観察期間を長くすると、短期的な変動がより平滑化されます。一方、間隔を短くすると変化がより明確になりますが、ステータス照会の割合が増加します。

ステータス照会自体もHTTPリクエストであり、監視対象のカウンター値にわずかな影響を与えます。これは、トラフィックが非常に少ない場合や、照会頻度が高い場合に特に顕著になります。定期的かつ文書化された照会間隔を設定しておくことで、こうした監視による影響を評価の際に考慮しやすくなります。

インスタンスが複数ある場合は、まず各インスタンスの連続した値からレートを算出します。 その後に初めて、同等の期間にわたるレートを統合することができます。データが欠落していたり、インスタンスの割り当てが変更されたりした場合は、一見連続しているかのように見せかけるのではなく、生じたギャップが明確にわかるようにすべきです。

誤りや限界を検証する

ステータスエンドポイントがHTTP 403を返した場合は、まずNGINXに実際に届いている送信元アドレスと、そのロケーションのアクセスルールを確認してください。 allow そして deny 最初のヒットが出るまで、順番に評価されます。ロケーションに設定された独自のルールは、必要に応じて継承されたルールに優先し、自動的にそれらを補完するわけではありません。

HTTP 404 が発生した場合は、まず他の箇所を確認してください。ポートとリスナー、リクエストされたパス、および選択されたサーバーブロックは正しいでしょうか？また、リロード後に設定が実際に有効になっているかどうかも確認してください。 別のポートやパスでのローカル呼び出しが成功したとしても、それが目的のロケーションにアクセスできたことを証明するものではありません。

HTTP応答がまったく返ってこない場合は、リスナーへの到達可能性と、エラーステータスを含む応答とを区別してください。 まず、リクエストを送信しているプロセスのアドレス、ポート、ネットワーク空間、およびサービス状態を確認してください。正しいリスナーへの接続が確立されて初めて、HTTPステータスや選択されたロケーションが、さらなる原因の絞り込みに役立ちます。

継続的なエラー分析を行うには、合計カウンタを比較することが有効です 受理および処理. 通常、これらは同じ値になります。その差が大きくなる場合は、リソース制限に達している可能性があります。ただし、カウンタの比較だけでは、具体的な原因や拒否されたHTTPリクエストの数を特定することはできません。そのため、調査にはエラーログや設定情報も併せて検討してください。

既存の差分は、まず両方の合計カウンタの差を示すだけです。観察期間中に状況に変化があったかどうかを判断するには、同じインスタンスを複数回呼び出した際のこの差分を比較してください。該当する期間を記録しておき、それに関連するログエントリや運用イベントを検索できるようにしてください。

指令 worker_connections ワーカーごとの接続数を制限するものであり、クライアント接続に限定されるわけではない。これには、例えばプロキシ経由のサーバーへの接続なども含まれる。さらに、ファイル記述子の制限によって接続数が制限される場合もある。「アクティブな接続数」をワーカー数で割った値に worker_connections したがって、信頼できる稼働率を算出することはできません。その代わりに、実際の制限値や、その状況におけるその他のリソース消費量を検証してください。

接続制限の変更は、ステータス値が高いという理由だけで行うべきではありません。まず、実際に制限に達しているかどうか、また他にどのようなリソースやアップストリーム接続が関与しているかを確認してください。変更案については、エラーや応答時間の監視と併せて検討し、所定の運用手順に従って検証を行ってください。

経緯と上流の問題を整理する

単一のステータス照会は、ある時点の状況しか示しません。一方、一定の間隔で繰り返し照会を行うことで、接続状態が通常のレベルを超えて上昇しているか、あるいはピーク後に再び低下しているかを把握するのに役立ちます。 複数のNGINXインスタンスを個別に監視し、各時系列データがどのインスタンスに由来するかを明確に記録してください。そうしないと、エンドポイント間の切り替えによって傾向が歪んでしまう可能性があります。

高い 待機値 待機中で、現時点で非アクティブなクライアント接続を表します。これ自体は過負荷の証拠とはなりません。接続が再利用されている場合、クライアントはさらなるリクエストを待機している可能性があります。 この数値の増加が意味を持つのは、同じ期間における応答時間、エラー、およびリソースメトリクスと比較した場合です。

残ります ライティング 長期間にわたって増加している場合は、アップストリーム時間とクライアントの挙動の両方を調査してください。 このステータスは、バイトが継続的に送信されていることを意味するものではありません。これには、アップストリーム応答を待機している時間も含まれる場合があります。「Stub Status」は、影響を受けているバックエンドサービスや遅延の原因を特定するものではありません。

割り当てを行う際には、補足データが役立ちます。アクセスログや記録されたアップストリーム時間は、どのリクエストやバックエンドに異常があるかを示し、エラーログは接続失敗の兆候を提供します。CPUやメモリの負荷に関する問題の場合は、対応するシステムメトリクスが必要となります。 バックエンドへの繰り返し接続が調査の対象となる場合は、以下の記事が参考になります。 NGINX のアップストリーム・キープアライブ 再利用可能なアップストリーム接続の設定。

ステータスからモニタリングへ

時折の診断であれば、保護されたローカルステータス照会だけで十分です。これは、照会されたインスタンスが現在どの基本値を報告しているかを示しますが、それ自体の履歴は保存しません。 推移を比較したり、異常が継続している場合に通知を受けたりしたい場合は、定期的なデータ収集と、時系列データおよびアラート機能に対応したシステムが必要となります。

公式の NGINX Prometheus エクスポーター これには専用のコンポーネントが用意されています。このコンポーネントはスタブのステータスを取得し、そのデータをPrometheusメトリクスとして提供します。その後、Prometheusはエクスポーターのエンドポイントを参照します。ステータスエンドポイントとエクスポーターのメトリクス出力、両方の経路について、到達可能性とアクセス制限を計画してください。

設定時には、どのエクスポーターがどのNGINXインスタンスにクエリを送信しているか、またPrometheusがどこからそのエクスポーターにアクセスしているかを記録しておいてください。特にコンテナが分離されている場合、これらは2つの異なるネットワーク経路となります。したがって、エクスポーターのエンドポイントにアクセスできるという事実だけでは、エクスポーター側が正しいステータスページを正常に取得できるかどうかを確認する作業の代わりにはなりません。

この追加の収集機能だけでは、基本データから詳細な応答時間やHTTPステータスクラスのメトリクスは得られません。応答が遅いURL、エラー応答、または個々のアップストリームに関する分析を行うには、適切なアクセスログやその他のテレメトリデータが必要となります。また、より包括的な NGINX Plus API Stub StatusとNGINX Open Sourceは区別する必要があります。両者の利用可能性や設定は互換性がありません。

具体的な質問に応じて追加のデータを選択してください。問い合わせ件数の増加を確認するには、まずはカウンターの経時比較で十分です。一方、応答の遅延や特定のバックエンドサービスに関する問題の場合は、該当する期間のレイテンシおよびアップストリームデータが必要になります。 ステータスページは調査のきっかけにはなりますが、それだけでは原因の特定には至りません。

アラームの閾値は、待機や書き込みに関する一般的な数値ではなく、各インスタンスの通常の動作やサービス目標に基づいて設定すべきです。 異常をレイテンシ、エラー、利用可能なリソースと照らし合わせ、そのアラームが実際に対処を要するものであるかどうかを検証してください。そうすることで、単一のカウンター値が、性急な診断ではなく、的を絞った調査のきっかけとなります。

アラームの計画立案にあたっては、データ収集経路の障害も考慮に入れてください。データの欠落は、リクエスト数ゼロや接続数ゼロとは異なります。 到達可能性を別途確認することで、実際にアクティビティが低い状態と、取得の失敗とを区別するのに役立ちます。また、アラームを処理する担当者を明確にし、診断のためにどのような追加データが必要となるかを定めておいてください。