nginx

nginx の統合により、接続の指標とアクセスログが収集されます。接続の指標は、接続の現在の状態（アクティブ、読み取り、待機）を取得します。アクセスログは接続の詳細情報を得るために解析されます。この詳細情報には、リクエスト、クライアント、サーバー、メッセージにマッピングされたフィールドが含まれます。

nginx の詳細については、nginx のドキュメントをご覧ください。

前提条件

uginx テレメトリーを収集するには、Ops エージェントをインストールする必要があります。

• 指標の場合は、バージョン 2.1.0 以降をインストールします。
• ログの場合は、バージョン 2.1.0 以降をインストールします。

この統合は、nginx バージョン 1.18 および 1.20 をサポートしています。

nginx インスタンスを構成する

nginx 構成ファイルの stub_status モジュールを有効にして、ローカルにアクセス可能な URL（ステータス ページの http://www.example.com/nginx_status など）を設定する必要があります。stub_status モジュールを有効にするには次の手順を行います。

1. status.conf ファイルを編集します。このファイルが存在しない場合は作成します。このファイルは、nginx 構成ディレクトリ（通常は /etc/nginx/conf.d にあります）で確認できます。

2. server セクションに次の行を追加します。

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

   構成ファイルは、次の例のようになります。

   server {
      listen 80;
      server_name 127.0.0.1;
      location /nginx_status {
          stub_status on;
          access_log off;
          allow 127.0.0.1;
          deny all;
      }
      location / {
          root /dev/null;
      }
   }
   

3. nginx 構成を再度読み込みます。

   sudo service nginx reload
   

前の手順は、次のコマンドを実行して自動化できます。このコマンドは、status.conf ファイルが存在しない場合には新規に作成し、存在する場合は既存のファイルを上書きします。このコマンドによって、stub_status がオンになり、nginx が再読み込みされ、必要な情報がエンドポイントを介して公開されることが確認されます。

sudo tee /etc/nginx/conf.d/status.conf > /dev/null << EOF
server {
    listen 80;
    server_name 127.0.0.1;
    location /nginx_status {
        stub_status on;
        access_log off;
        allow 127.0.0.1;
        deny all;
    }
    location / {
       root /dev/null;
    }
}
EOF
sudo service nginx reload
curl http://127.0.0.1:80/nginx_status

出力例を次に示します。

Active connections: 1
server accepts handled requests
 23 23 74
Reading: 0 Writing: 1 Waiting: 0

注: 127.0.0.1 は、実際のサーバー名（例: server_name mynginx.domain.com）に置き換えることができます。確認する curl コマンドは、curl http://mynginx.domain.com:80/nginx_status です。

あるいは、別の status.conf ファイルを使用するのではなく、メインの nginx.conf ファイルに行を直接埋め込むこともできます。このファイルは通常、/etc/nginx、/usr/local/nginx/conf、/usr/local/etc/nginx のいずれかのディレクトリにあります。

nginx 用の Ops エージェントを構成する

Ops エージェントの構成のガイドに沿って、nginx インスタンスからテレメトリーを収集するために必要な要素を追加し、エージェントを再起動します。

構成の例

次のコマンドは、nginx のテレメトリーを収集して取り込み、Ops エージェントを再起動するための構成を作成します。

# Configures Ops Agent to collect telemetry from the app and restart Ops Agent.

set -e

# Create a back up of the existing file so existing configurations are not lost.
sudo cp /etc/google-cloud-ops-agent/config.yaml /etc/google-cloud-ops-agent/config.yaml.bak

# Configure the Ops Agent.
sudo tee /etc/google-cloud-ops-agent/config.yaml > /dev/null << EOF
metrics:
  receivers:
    nginx:
      type: nginx
      stub_status_url: http://127.0.0.1:80/nginx_status
  service:
    pipelines:
      nginx:
        receivers:
          - nginx
logging:
  receivers:
    nginx_access:
      type: nginx_access
    nginx_error:
      type: nginx_error
  service:
    pipelines:
      nginx:
        receivers:
          - nginx_access
          - nginx_error
EOF

sudo service google-cloud-ops-agent restart
sleep 60

ログの収集を構成する

nginx からログを取り込むには、nginx が生成するログのレシーバーを作成してから、新しいレシーバー用のパイプラインを作成する必要があります。

nginx_access ログのレシーバを構成するには、次のフィールドを指定します。

フィールド	デフォルト	説明
exclude_paths		include_paths の照合で除外するファイルシステム パスのパターンのリスト。
include_paths	[/var/log/nginx/access.log]	各ファイルのテーリングで読み込むファイルシステムのパスのリスト。パスにはワイルドカード（*）を使用できます。
record_log_file_path	false	true に設定すると、ログレコードの取得先のファイルのパスが agent.googleapis.com/log_file_path ラベルの値として出力ログエントリに表示されます。ワイルドカードを使用する場合、レコードを取得したファイルのパスのみが記録されます。
type		値は nginx_access にする必要があります。
wildcard_refresh_interval	60s	include_paths のワイルドカード ファイルのパスの更新間隔。期間を指定します（例: 30s、2m）。このプロパティは、ログファイルのローテーションがデフォルトの間隔よりも速く、ロギングのスループットが高い場合に有用です。

nginx_error ログのレシーバを構成するには、次の項目を指定します。

フィールド	デフォルト	説明
exclude_paths		include_paths の照合で除外するファイルシステム パスのパターンのリスト。
include_paths	[/var/log/nginx/error.log]	各ファイルのテーリングで読み込むファイルシステムのパスのリスト。パスにはワイルドカード（*）を使用できます。
record_log_file_path	false	true に設定すると、ログレコードの取得先のファイルのパスが agent.googleapis.com/log_file_path ラベルの値として出力ログエントリに表示されます。ワイルドカードを使用する場合、レコードを取得したファイルのパスのみが記録されます。
type		値は nginx_error にする必要があります。
wildcard_refresh_interval	60s	include_paths のワイルドカード ファイルのパスの更新間隔。期間を指定します（例: 30s、2m）。このプロパティは、ログファイルのローテーションがデフォルトの間隔よりも速く、ロギングのスループットが高い場合に有用です。

ログの内容

logName は、構成で指定されたレシーバ ID から取得されます。LogEntry 内の詳細なフィールドは、次のとおりです。

nginx_access ログの LogEntry には次のフィールドが含まれます。

フィールド	タイプ	説明
httpRequest	オブジェクト	HttpRequest を参照
jsonPayload.host	文字列	ホストヘッダーの内容（通常、nginx から報告されません）
jsonPayload.level	文字列	ログエントリ レベル
jsonPayload.user	文字列	リクエストの認証済みユーザー名
severity	文字列（LogSeverity）	ログエントリ レベル（変換済み）。

nginx_error ログの LogEntry には次のフィールドが含まれます。

フィールド	タイプ	説明
jsonPayload.client	文字列	クライアント IP アドレス（省略可）
jsonPayload.connection	数値	接続 ID
jsonPayload.host	文字列	Host ヘッダー（省略可）
jsonPayload.level	文字列	ログエントリ レベル
jsonPayload.message	文字列	ログメッセージ
jsonPayload.pid	数値	ログを発行するプロセス ID
jsonPayload.referer	文字列	リファラー ヘッダー（省略可）
jsonPayload.request	文字列	元の HTTP リクエスト（省略可）
jsonPayload.server	文字列	Nginx サーバー名（省略可）
jsonPayload.subrequest	文字列	Nginx サブリクエスト（省略可）
jsonPayload.tid	数値	ログの生成元のスレッド ID
jsonPayload.upstream	文字列	アップストリーム リクエスト URI（省略可）
severity	文字列（LogSeverity）	ログエントリ レベル（変換済み）。

指標の収集を構成する

nginx から指標を取り込むには、nginx が生成する指標のレシーバを作成してから、新しいレシーバ用のパイプラインを作成する必要があります。

このレシーバでは、複数のエンドポイントのモニタリングなど、構成で複数のインスタンスを使用することはできません。このようなインスタンスはすべて同じ時系列に書き込まれるため、Cloud Monitoring ではインスタンスを区別できません。

nginx 指標のレシーバーを構成するには、次のフィールドを指定します。

フィールド	デフォルト	説明
collection_interval	60s	期間の値（例: 30s、5m）。
server_status_url	http://localhost/status	nginx スタブ ステータス モジュールによって公開される URL。
type		値は nginx にする必要があります。

モニタリング対象

次の表に、Ops エージェントが nginx インスタンスから収集する指標の一覧を示します。

指標タイプ
種類、タイプ モニタリング対象リソース	ラベル
workload.googleapis.com/nginx.connections_accepted
CUMULATIVE、INT64 gce_instance
workload.googleapis.com/nginx.connections_current
GAUGE、INT64 gce_instance	state
workload.googleapis.com/nginx.connections_handled
CUMULATIVE、INT64 gce_instance
workload.googleapis.com/nginx.requests
CUMULATIVE、INT64 gce_instance

構成を確認する

このセクションでは、nginx レシーバが正しく構成されていることを確認する方法について説明します。Ops エージェントがテレメトリーの収集を開始するまでに 1～2 分かかる場合があります。

nginx ログが Cloud Logging に送信されていることを確認するには、次のようにします。

1. Google Cloud コンソールで、[ログ エクスプローラ] ページに移動します。

   [ログ エクスプローラ] に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Logging] である結果を選択します。

2. エディタに次のクエリを入力し、[クエリを実行] をクリックします。
   

   resource.type="gce_instance"
   (log_id("nginx_access") OR log_id("nginx_error"))
   

nginx 指標が Cloud Monitoring に送信されていることを確認するには、次のようにします。

1. Google Cloud コンソールで、[Metrics Explorer] ページに移動します。

   Metrics Explorer に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] である結果を選択します。

2. クエリビルダー ペインのツールバーで、[MQL] または [PromQL] という名前のボタンを選択します。
3. [MQL] 切り替えで [MQL] が選択されていることを確認します。言語切り替えボタンは、クエリの書式設定を行うのと同じツールバーにあります。
4. エディタに次のクエリを入力し、[クエリを実行] をクリックします。
   

   fetch gce_instance
   | metric 'workload.googleapis.com/nginx.requests'
   | every 1m
   

ダッシュボードを表示

nginx 指標を表示するには、グラフまたはダッシュボードが構成されている必要があります。 nginx インテグレーションには、1 つ以上のダッシュボードが含まれています。インテグレーションを構成して Ops エージェントが指標データの収集を開始すると、ダッシュボードは自動的にインストールされます。

インテグレーションをインストールすることなく、ダッシュボードの静的プレビューを表示することもできます。

インストールされているダッシュボードを表示する手順は次のとおりです。

1. Google Cloud コンソールで [ダッシュボード] ページに移動します。

   [ダッシュボード] に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] である結果を選択します。

2. [ダッシュボード リスト] タブを選択し、[統合] カテゴリを選択します。
3. 表示するダッシュボードの名前をクリックします。

インテグレーションを構成してもダッシュボードがインストールされていない場合は、Ops エージェントが実行されていることを確認します。ダッシュボードにグラフの指標データがない場合、ダッシュボードのインストールは失敗します。Ops エージェントが指標の収集を開始した後に、ダッシュボードがインストールされます。

ダッシュボードの静的プレビューを表示する手順は次のとおりです。

1. Google Cloud コンソールで [統合] ページに移動します。

   [インテグレーション] に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] である結果を選択します。

2. [デプロイメント プラットフォーム] フィルタの [Compute Engine] をクリックします。
3. nginx のエントリを見つけて、[詳細を表示] をクリックします。
4. [ダッシュボード] タブを選択すると、静的プレビューが表示されます。ダッシュボードがインストールされている場合は、[ダッシュボードを表示] をクリックして移動できます。

Cloud Monitoring のダッシュボードについて詳しくは、ダッシュボードとグラフをご覧ください。

[インテグレーション] ページの使用方法については、インテグレーションを管理するをご覧ください。

アラート ポリシーをインストールする

アラート ポリシーは、指定した条件が成立した際に通知するように Cloud Monitoring に指示します。 nginx インテグレーションには、使用する 1 つ以上のアラート ポリシーが含まれています。これらのアラート ポリシーは、Monitoring の [インテグレーション] ページで表示してインストールできます。

使用可能なアラート ポリシーの説明を表示してインストールする手順は次のとおりです。

1. Google Cloud コンソールで [統合] ページに移動します。

   [インテグレーション] に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] である結果を選択します。

2. nginx のエントリを見つけて、[詳細を表示] をクリックします。
3. [アラート] タブを選択します。このタブには、利用可能なアラート ポリシーの説明と、それらをインストールするためのインターフェースが表示されます。
4. アラート ポリシーをインストールします。アラート ポリシーでは、アラートがトリガーされた通知の送信先を特定する必要があるため、インストール環境の情報が必要になります。アラート ポリシーをインストールする手順は次のとおりです。
   1. 利用可能なアラート ポリシーのリストから、インストールするアラート ポリシーを選択します。

   2. [通知の構成] セクションで、1 つ以上の通知チャンネルを選択します。通知チャンネルの使用を無効にすることもできますが、無効にすると、アラート ポリシーは通知なく起動します。Monitoring でステータスを確認できますが、通知は受信しません。

      通知チャンネルの詳細については、通知チャンネルを管理するをご覧ください。

   3. [ポリシーの作成] をクリックします。

Cloud Monitoring のアラート ポリシーの詳細については、アラートの概要をご覧ください。

[インテグレーション] ページの使用の詳細については、統合を管理するをご覧ください。

トラブルシューティング

ほとんどのディストリビューションの Nginx は、ngx_http_stub_status_module が有効にされています。モジュールが有効になっているかどうかは、次のコマンドを実行して確認できます。

sudo nginx -V 2>&1 | grep -o with-http_stub_status_module

想定される出力は with-http_stub_status_module です。これはモジュールが有効になっていることを意味します。まれに、コマンドが出力を返さない場合は、nginx の公開ドキュメントに沿って、-with-http_stub_status_module を使用してソースから nginx をコンパイルする必要があります。

次のステップ

Ansible を使用して Ops エージェントをインストールし、サードパーティ アプリケーションを構成してサンプル ダッシュボードをインストールする方法については、Ops エージェントをインストールして、サードパーティ アプリケーションのトラブルシューティングを行うの動画をご覧ください。