Nginx 可観測性のベストプラクティス¶

背景説明¶

Nginx は、オープンソースで無料の高性能 HTTP およびリバースプロキシサーバーであり、IMAP/POP3 プロキシサーバーとしても使用できます。Nginx は非同期ノンブロッキングのワーカーモデルを採用しているため、高同時接続性と低リソース消費を実現し、高度にモジュール化された設計により拡張性にも優れています。静的ファイルの処理やリバースプロキシリクエストなどにおいて、Nginx は大きな優位性を発揮し、さらにデプロイとメンテナンスが簡単であるため、ほとんどの企業が Nginx を内部で利用しています。現在、Nginx で最もよく使われるシナリオは以下のとおりです。

• WEB サーバー（静的リソースサーバー）

• ロードバランサー（トラフィック分散）

• リバースプロキシ
• その他

Nginx はシンプルですが、その適用範囲の広さから企業内では比較的重要な位置づけにあります。では、Nginx の健全性と安定性をどのように確保するのでしょうか。これは企業の運用担当者にとって非常に関心の高いテーマです。Nginx 自体に搭載されているパフォーマンス指標モジュール with-http_stub_status_module を使用すると、Nginx 関連のデータ（リクエスト接続数や処理接続数など）を直接取得できます。同時に、Nginx のログ（access.log、error.log）を使用すれば、リクエストレベルでの具体的な分析（PV 数、UV 数、リクエストエラー統計など）が可能になり、これら 2 つのデータソースを組み合わせることで Nginx の状態を迅速に把握できます。

• Nginx（with-http_stub_status_module）

• Nginx ログ：

例は以下のとおりです。

Nginx 自体は自身の状態を把握するための十分なデータソースを提供していますが、テキスト形式やログ形式のデータは見づらく、また Nginx のリクエスト数やサーバーのリクエスト状態の変化傾向をリアルタイムで把握することもできません。このようなデータや指標を素早く可視化するための優れたツールはないでしょうか。現在、企業ではログ処理ツール（ELK、Splunk）を使用して Nginx ログを処理・可視化し、Nginx のパフォーマンスデータについては可視化ツールを使用してデータを表示するケースが多く見られます。しかし、これらの方法ではデータが分断されたり、ソリューションのコストが高くなったりする問題があります。この問題を解決するために、DataKit は根本から対処することにしました。例えば、データ収集では同じ設定項目で Nginx のパフォーマンス状態とログを同時に収集し、データの可視化も同一プラットフォーム・同一画面で行うことで、ユーザーの作業効率を向上させます。

DataKit の設定画面と最終的な監視結果の表示：

Nginx 監視を Guance に接続するための前提条件¶

アカウント登録¶

Guance にアクセスしてアカウントを登録し、登録したアカウント/パスワードでログインします。

DataKit のインストール¶

コマンドの取得¶

[統合] モジュールをクリックし、右上の [DataKit インストールコマンドを取得] から、ご利用のオペレーティングシステムとシステムタイプに適したインストールコマンドを選択します。

インストールの実行¶

DataKit のインストールコマンドをコピーし、監視対象のサーバー上で直接実行します。

• インストールディレクトリ /usr/local/datakit/

• ログディレクトリ /var/log/datakit/

• メイン設定ファイル /usr/local/datakit/conf.d/datakit.conf
• プラグイン設定ディレクトリ /usr/local/datakit/conf.d/

DataKit のインストールが完了すると、Linux ホストの標準プラグインがデフォルトで有効になります。インフラストラクチャの組み込みビューで確認できます。

[インフラストラクチャ] モジュールをクリックすると、DataKit がインストールされているすべてのホストのリストと基本情報（ホスト名、CPU、メモリなど）を確認できます。

監視シナリオの新規作成¶

DataFlux にログインし、対象のワークスペースに入ります。シナリオ新規作成 → 新規空白シナリオ → ビューテンプレート（DF のシステムビューにある Nginx ビューテンプレートを直接選択することを推奨）をクリックします。

監視ビューは以下のとおりです：

Nginx 収集関連の設定を有効にする手順¶

datakit.inputs の nginx.conf を有効にするための前提条件¶

Nginx の with-http_stub_status_module モジュールが有効になっているか確認します。インストールされていない場合は、インストールする必要があります。

Linux 環境：¶

yum でインストールした Nginx の場合は、コンソールで nginx -V と入力して with-http_stub_status_module モジュールが有効か確認します。すでに存在する場合は、DataKit で Nginx.inputs を有効にする の手順に直接進んでください。

$ nginx -V

カスタムインストールした Nginx の場合は、コンソールで /usr/local/nginx/sbin/nginx -V と入力して確認します。すでに存在する場合は、DataKit で Nginx.inputs を有効にする の手順に直接進んでください。

$ /usr/local/nginx/sbin/nginx -V

Windows 環境：¶

PowerShell で .\nginx.exe -V を実行して確認します。すでに存在する場合は、DataKit で Nginx.inputs を有効にする の手順に直接進んでください。

$  .\nginx.exe -V

with-http_stub_status_module モジュールのインストール（Linux）：¶

モジュールがすでにインストールされている場合は、この手順をスキップしてください。

このモジュールを有効にするには、Nginx を再コンパイルする必要があります。具体的なコマンドは以下のとおりです。

./configure --with-http_stub_status_module

configure ファイルの場所を確認するには：find /| grep configure |grep nginx

$ find /| grep configure |grep nginx
$ cd /usr/local/src/nginx-1.20.0/
$ ./configure --with-http_stub_status_module

nginx.conf に nginx_status の location 転送を追加する（例）¶

$ cd /etc/nginx   
   //nginxパスは実際の状況に応じて変更
$ vim nginx.conf

$  server{
     listen 80;   
     server_name localhost;
     //ポートはカスタマイズ可能

      location /nginx_status {
          stub_status  on;
          allow 127.0.0.1;
          deny all;
                             }

          }

次に、nginx -s reload を実行して Nginx を再読み込みします

モジュールが正常に有効になっているか確認します。

Linux 環境：curl http://127.0.0.1/nginx_status

Windows 環境：ブラウザで http://127.0.0.1/nginx_status にアクセス

以下のようなデータが表示されます。

DataKit で nginx.inputs を有効にする¶

Linux 環境：¶

$ cd /usr/local/datakit/conf.d/nginx/
$ cp nginx.conf.sample nginx.conf
$ vim  nginx.conf

以下の内容を修正します。

[[inputs.nginx]]
    url = http://localhost/nginx_status
[inputs.nginx.log]
    files = ["/var/log/nginx/access.log","/var/log/nginx/error.log"]

pipeline = "nginx.p"
# pipeline ファイルは nginx ログのパース処理を担当し、完全なテキストファイルを key-value 形式のキーと値のペアに分割します。これにより、DF プラットフォーム上での可視化が容易になります。
# pipeline 設定の nginx.p は、デフォルトで /usr/local/datakit/pipeline/ ディレクトリに配置されます。access および error 形式に関連するパース処理が組み込まれています。

nginx.conf ファイルを保存した後、datakit を再起動します

# pipeline をカスタマイズする場合は、[テキスト処理（Pipeline）] を参照してください。

Windows 環境：¶

$ C:\Program Files\datakit\conf.d\nginx に移動

$ nginx.conf.sample をコピーし、nginx.conf にリネーム

$ nginx.conf ファイルを編集

以下の内容を修正します。

[[inputs.nginx]]
    url = http://localhost/nginx_status
[inputs.nginx.log]
    files = ["/logs/access.log","/ logs/error.log"]

Nginx と関連指標の紹介¶

Nginx とは？¶

Nginx（発音は「エンジンエックス」）は、一般的な HTTP サーバーおよびリバースプロキシサーバーです。HTTP サーバーとして、Nginx は少ないメモリ消費で静的コンテンツを非常に効率的かつ確実に提供できます。リバースプロキシとして、複数のバックエンドサーバーやキャッシュ、ロードバランサーなどの他のアプリケーションへの単一の管理されたアクセスポイントとして機能します。Nginx はオープンソース版をダウンロードして使用することも、より完全な機能を備えた商用ディストリビューション版の Nginx Plus を使用することもできます。Nginx はメールプロキシや汎用 TCP プロキシとしても使用できますが、本稿ではこれらのシナリオの監視については直接扱いません。

Nginx の主要指標¶

Nginx を監視することで、次の 2 種類の問題を発見できます。1. Nginx 自体のリソース問題、2. Web インフラストラクチャの他の部分における開発上の問題です。ほとんどの Nginx ユーザーが監視から恩恵を受ける指標には、requests per second（1 秒あたりのリクエスト数。エンドユーザーアクティビティの組み合わせの概要を示します）、server error rate（サーバーエラー率。サーバーがリクエスト処理に失敗した割合）、request processing time（リクエスト処理時間。サーバーがクライアントリクエストの処理に要した時間。環境内のリクエスト速度低下やその他の問題を示す可能性があります）などがあります。
一般的に、少なくとも 3 つの主要な指標カテゴリに注意する必要があります。

• 基本アクティビティ指標

• エラー指標

• パフォーマンス指標

以下では、各カテゴリの最も重要な Nginx 指標と、特に注目に値する一般的なユースケースである Nginx Plus を使用したリバースプロキシの指標について詳しく説明します。また、選択したグラフツールや監視ツールを使用してこれらの指標を監視する方法についても紹介します。

基本アクティビティ指標¶

どの Nginx のユースケースであっても、サーバーが受信しているクライアントリクエストの数と、それらの処理方法を監視したいと考えるでしょう。

Nginx Plus は、オープンソース Nginx と同様に基本アクティビティ指標を報告できますが、わずかに異なる指標を報告する補助モジュールも提供します。まずオープンソース Nginx について説明し、次に Nginx Plus が提供する追加のレポート機能について説明します。

Nginx¶

下図は、クライアント接続のライフサイクルと、Nginx のオープンソース版が接続中にどのように指標を収集するかを示しています。

Accepts（受け入れ）、Handled（処理）、Requests（リクエスト）はカウンターとして増加し続けます。Active（アクティブ）、Waiting（待機）、Reading（読み取り）、Writing（書き込み）はリクエスト量に応じて変化します。

Nginx が OS から接続リクエストを取得すると、カウンターが増加します。ワーカーがそのリクエストの接続を取得できない場合（新しい接続の確立または開いている接続の再利用により）、その接続は切断されます。通常、リソース制限（Nginx の worker_connections 制限など）に達したために接続が切断されます。

• waiting（待機）：現在アクティブなリクエストがない場合、アクティブ接続は「待機」状態になることもあります。新しい接続はこの状態をスキップして直接 Reading に移行できます。最も一般的なケースは、「Accept Filter」または「遅延受け入れ」を使用している場合で、Nginx は応答を開始するのに十分なデータが揃うまで処理を続行しません。接続が keep-alive に設定されている場合、応答送信後も接続は「待機」状態になります。

• reading（読み取り）：リクエストを受信すると、接続は待機状態を終了し、リクエスト自体は読み取り中と見なされます。この状態では、Nginx はクライアントリクエストヘッダーを読み取っています。リクエストヘッダーは通常軽量であるため、これは通常高速な操作です。

• writing（書き込み）：リクエストを読み取った後、そのリクエストは書き込み中と見なされ、応答がクライアントに返されるまでその状態を維持します。つまり、Nginx が上流システム（Nginx の背後にあるシステム）の結果を待機している間や、Nginx が応答を処理している間、リクエストは書き込み中です。リクエストは通常、ほとんどの時間を書き込み状態で過ごします。

通常、1 つの接続は一度に 1 つのリクエストのみをサポートします。この場合、アクティブ接続数 == 待機接続 + 読み取りリクエスト + 書き込みリクエストとなります。ただし、HTTP/2 では複数の同時リクエスト/応答を接続経由で多重化できるため、Active は Waiting、Reading、Writing の合計よりも小さくなる場合があります。

Nginx Plus¶

前述のとおり、Nginx Plus ではオープンソース Nginx のすべての指標が利用可能ですが、Nginx Plus ではさらに他の指標も表示できます。このセクションでは、Nginx Plus でのみ利用可能な指標について説明します。

Accepted（受け入れ済み）、Dropped（切断）、Total（合計）のカウンターは増加し続けます。Active（アクティブ）、Idle（アイドル）、Current（現在）は、各状態の現在の接続数またはリクエストの合計数を追跡するため、リクエスト量の増減に応じて増減します。

Nginx Plus ワーカーが OS から接続リクエストを Accepted（受け入れ）すると、カウンターが増加します。ワーカーがそのリクエストの接続を取得できない場合（新しい接続の確立または開いている接続の再利用により）、その接続は Dropped（切断）され、Dropped が増加します。通常、リソース制限（Nginx Plus の worker_connections 制限など）に達したために接続が切断されます。

Active（アクティブ）と Idle（アイドル）は、前述のとおり、オープンソース Nginx の「active」および「waiting」状態と同じですが、1 つの重要な違いがあります。オープンソース Nginx では「waiting」は「active」の範囲に含まれますが、Nginx Plus では「idle」接続は「active」カウントから除外されます。Current（現在）は、オープンソース Nginx の「Reading+Writing」を合わせた状態と同じです。

Total（合計）は、クライアントリクエストの累積カウントです。1 つのクライアント接続に複数のリクエストが含まれる可能性があるため、この数値は接続の累積数よりもはるかに大きくなる可能性があることに注意してください。実際には、(total / accepted) は 1 接続あたりの平均リクエスト数を示します。

アラート指標：接続切断¶

Dropped（切断）された接続数は、accept（受け入れ）と handled（処理）の差に等しく、または Nginx Plus が提供する指標を直接使用できます。通常の状態では、切断された接続はゼロになるはずです。単位時間あたりの切断レートが上昇し始めた場合は、リソース飽和状態の原因となる可能性のある要因を調査してください。

アラート指標：1 秒あたりのリクエスト数¶

一定の間隔でリクエストデータ（Nginx オープンソース版の Requests、または Nginx Plus の Total）をサンプリングすると、単位時間（通常は分または秒）あたりに受信したリクエスト数を把握できます。この指標を監視することで、正当なものであれ悪意のあるものであれ、流入するネットワークトラフィックのピークや、急激な低下（通常は問題を示します）を警告できます。1 秒あたりのリクエスト数の急激な変化は、環境のどこかで問題が発生していることを示す可能性がありますが、問題の正確な場所を特定できるわけではありません。すべてのリクエストがカウントされることに注意してください（URL に関係なく）。

アクティビティ指標の収集¶

オープンソース Nginx は、シンプルなステータスページでこれらの基本的なサーバー指標を公開します。ステータス情報は標準化された形式で表示されるため、ほとんどすべてのグラフツールや監視ツールを設定して、分析、可視化、アラート発報のためにデータを解析できます。Nginx Plus は、よりリッチなデータを含む JSON フィードを提供します。指標収集を有効にする手順については、Nginx 指標収集に関する関連記事を参照してください。

エラー指標¶

Nginx のエラー指標は、サーバーが有効なリクエストを処理する代わりにエラーを返したことを示します。クライアントエラーは 4xx ステータスコードで、サーバーエラーは 5xx ステータスコードで示されます。

アラート指標：サーバーエラー率¶

サーバーエラー率は、単位時間（通常 1 ～ 5 分）あたりの 5xx エラー数（例：「502 Bad Gateway」）を、リクエスト総数（1xx、2xx、3xx、4xx、5xx を含む）で割った値に等しくなります。エラー率が時間の経過とともに上昇し始めた場合は、調査が必要になる可能性があります。急激に増加した場合は、クライアントがエンドユーザーにエラーを報告する可能性があるため、緊急措置が必要になる場合があります。

クライアントエラーに関する注釈：4xx は主にクライアント側のエラーを示し、4xx から得られる情報は限定的です。これは主にクライアントの異常を示し、特定の URL についての詳細な情報を提供するものではありません。つまり、4xx の変動はノイズである可能性があります。例えば、Web スキャナーが脆弱性を盲目的に探している場合などです。

エラー指標の収集¶

オープンソース Nginx は可観測性に使用できるエラー率を直接提供しませんが、この情報を取得する方法は少なくとも 2 つあります。

1. 商用サポート付きの Nginx Plus に付属する拡張ステータスモジュールを使用する

2. Nginx のログモジュールを設定し、アクセスログに応答コードを書き込む

これらの方法の詳細については、Nginx 指標収集に関する関連記事を参照してください。

パフォーマンス指標¶

アラート指標：リクエスト処理時間¶

Nginx が記録するリクエスト時間指標は、最初のクライアントバイトの読み取りからリクエスト完了までの各リクエストの処理時間を記録します。応答時間が長い場合は、上流（サーバー側）の応答に問題がある可能性があります。

処理時間指標の収集¶

Nginx および Nginx Plus ユーザーは、$request_time 変数をアクセスログ形式に追加することで、処理時間のデータを取得できます。監視用のログ設定の詳細については、Nginx ログに関する関連記事を参照してください。

リバースプロキシ指標¶

Nginx の最も一般的な用途はリバースプロキシです。商用版の Nginx Plus は、リバースプロキシ設定に関連するバックエンド（または「アップストリーム」）サーバーに関する多数の指標を公開しています。このセクションでは、Nginx Plus ユーザーが注目すべき主要なアップストリーム指標に焦点を当てます。

Nginx Plus は、まずグループごとにアップストリームの指標を細分化し、次に個々のサーバーごとに細分化します。例えば、リバースプロキシがリクエストを 5 つのアップストリーム Web サーバーに分散している場合、個々のサーバーが過負荷で稼働していないか、アップストリームサーバーグループに良好な応答時間を確保するのに十分な健全なサーバーがあるかを一目で確認できます。

アクティビティ指標¶

アップストリームサーバーごとのアクティブ接続数は、リバースプロキシがサーバーグループ内で適切にワークを分散しているかどうかを検証するのに役立ちます。Nginx をロードバランサーとして使用している場合、いずれかのサーバーが処理する接続数に大きな偏りがある場合、そのサーバーがリクエストをタイムリーに処理するのに苦労しているか、設定したロードバランシング方法（ラウンドロビンや IP ハッシュなど）がトラフィックパターンに対して最適化の余地があることを示している可能性があります。

エラー指標¶

前述のエラー指標セクションを振り返ると、「502 Bad Gateway」や「503 Service Temporarily Unavailable」などの 5xx（サーバーエラー）コードは、特に総応答コードに占める割合において、監視すべき重要な指標です。Nginx Plus を使用すると、各アップストリームサーバーの 5xx ステータスコードの数と応答総数を簡単に取得して、特定のサーバーのエラー率を把握できます。

可用性指標¶

Web サーバーの健全性を別の角度から見るために、Nginx は各グループ内で現在利用可能なサーバー数を監視することで、アップストリームグループの健全性を簡単に監視できます。大規模なリバースプロキシ環境では、利用可能なサーバープールが負荷を処理できる限り、個々のサーバーの状態をあまり気にしないかもしれません。ただし、各アップストリームグループ内の稼働中のサーバー総数を監視することで、Web サーバーの全体的な健全性を包括的に把握できます。

アップストリーム指標の収集¶

Nginx Plus のアップストリーム指標は、Nginx Plus 監視ダッシュボードで公開されるほか、JSON インターフェースを介してほぼすべての外部監視プラットフォームに指標を提供できます。

結論¶

本稿では、Nginx サーバーで監視できる最も価値のある指標のいくつかに触れました。Nginx を初めて使用する場合は、以下のリストの大部分またはすべての指標を監視することで、Web インフラストラクチャの健全性とアクティビティレベルを良好に可視化できます。

• 接続切断

• 1 秒あたりのリクエスト数

• サーバーエラー率
• リクエスト処理時間

最終的には、ご自身のインフラストラクチャとユースケースに特に関連する、より専門的な他の指標を認識するようになるでしょう。もちろん、監視する内容は、お持ちのツールと利用可能な指標によって異なります。

詳細情報¶

DataKit を使用した Nginx 指標の収集方法