NginxとのネイティブPrometheus統合

NGINXとのネイティブPrometheus統合

本日、私たちはNGINX用のPrometheus統計エクスポートモジュールを正式にオープンソース化しました！

はじめに

NGINXは、長らくリバースプロキシサーバーとしての事実上の標準となっています。Categoricaでも、従来のウェブコンテンツ提供に加え、この目的でNGINXを使用しています。同様に、アクティブなデプロイメントの統計情報を収集・集計・表示するためにPrometheusとGrafanaに依存しています。

メトリクス収集

現状では、NGINXでの統計・メトリクス収集には、高機能なPrometheusエクスポーターであるNGINX Prometheus Exporterという実質的に唯一の選択肢があります。しかし、独自のメトリクス収集を設定する際に、何か少し違和感を感じていました。

なぜメトリクスエンドポイント自体が独自のウェブサーバーを実行する必要があるのでしょうか？

実際には、これは大きな問題ではありません。systemdサービス（したがって通常のバイナリ）としてデプロイすることも可能ですが、Dockerのサイドカーコンテナ経由でNGINX Prometheus Exporterをデプロイするのが一般的です。これは、必要に思えない追加の複雑さです。しかし、これはメトリクス収集自体が「誰が監視者を監視するのか」という形でメトリクス収集を回避することを意味します。

要するに、このイデオロギー的な不満は、夜間や週末の空き時間には耐えられず、結果として生まれたNGINXプラグインがすぐに統計収集の好みのメカニズムになりました。本日、これを共有することにしました。

使用方法

コマンドラインに慣れている必要があり、GNUの「configure, make, make install」の基本的な理解があれば役立ちますが、必須ではありません。NGINXをソースからビルドすることが推奨されます。これにより、必要な機能がコンパイルされていることを確認できます（パッケージマネージャーのNGINXの考え方は私たちのものと異なる場合があります）。ただし、これも必須ではありません。

前提条件

1. NGINXをソースからビルドしない場合でも、モジュールをコンパイルするにはNGINXソースが必要です。提供されているMakefileがこのステップを代行できます。
2. NGINXをソースからビルドしない場合、NGINXは--with-compatおよび--with-http_stub_status_moduleでコンパイルされている必要があります。
3. C99コンパイラ（例: Clang）。
4. PCRE、OpenSSL、およびzlibライブラリとヘッダー。

さらに、これらの手順はUnixライクな環境内からビルドすることを前提としています。

NGINXのビルド

適切なバージョンのNGINXが既にインストールされている場合は、この手順をスキップしてください。ターミナルから

cd path-to-nginx-source;

# プラグインビルド中にNGINXソースへのパスを使用します。
export NGINX_SRC=`pwd`;

./configure --with-compat --with-http_stub_status_module;

make -j;

sudo make install;

これにより、通常/usr/localプレフィックスでNGINXがビルドおよびインストールされます。NGINXのビルドに関する詳細については、公式ドキュメントを参照してください。

プラグインのビルド

適切なバージョンのNGINXが既にインストールされている場合、提供されているMakefileは、NGINXのバージョンを（nginx -vを呼び出すことで）特定し、プラグインをビルドするために必要な適切なNGINXソースをダウンロードします。

この動作が望ましくない場合は、環境変数NGINX_SRCを使用してNGINXソースへのパスを設定できます。これにより、バージョンチェックとソースダウンロードがスキップされます。

その後、プラグインのビルドは以下のように行います。

make module

sudo make install

これによりプラグインがビルドされ、適切なプラグインの場所にインストールされます。

詳細については、GitHubリポジトリのREADME.mdを参照してください。

プラグインを使用したNGINXの実行

プラグインがビルドされたら、統計情報を利用可能にするルートを記述するためにいくつかの設定が必要です。

load_module modules/ngx_http_stats_prom_module.so;

http {
  # オプション: 共有メモリサイズを設定（デフォルト 1m）
  # prometheus_metrics_shm_size 2m;

  server {
    # 標準のNGINXサーバーディレクティブがここに適用されます

    listen 9100;
    location /metrics {
      prometheus_metrics;
    }
  }
}

この設定は、http://hostname:9100/metricsでPrometheus取り込みに適した統計情報をエクスポートします。NGINXインスタンスがローカルで実行されていると仮定すると、curlを使用してメトリクスエンドポイントをクエリできるはずです。

curl http://localhost:9100/metrics

サンプル応答：

# HELP nginx_up Nginxプロセスが起動しているかどうか
# TYPE nginx_up gauge
nginx_up 1

# HELP nginx_process_pid ワーカープロセスのPID（メトリクス提供中）
# TYPE nginx_process_pid gauge
nginx_process_pid 2985885

# HELP nginx_http_requests_total HTTPリクエストの総数
# TYPE nginx_http_requests_total counter
nginx_http_requests_total 434488

# HELP nginx_http_responses_total ステータスクラス別のHTTPレスポンス数
# TYPE nginx_http_responses_total counter
nginx_http_responses_total{status="1xx"} 0
nginx_http_responses_total{status="2xx"} 42598
nginx_http_responses_total{status="3xx"} 771
nginx_http_responses_total{status="4xx"} 77
nginx_http_responses_total{status="5xx"} 1

# etc.

エクスポートされる統計情報

実行されると、設定で指定されたルートでNGINXのメトリクスを表示できるようになります。

起動後、利用可能なメトリクスは以下の通りです。

これらのメトリクスはプロセス起動直後から利用可能で、プロセス開始からの経過時間が計測されます。

さらに、nginx.confファイルで定義された各serverまたはupstreamディレクティブの基本的なメトリクスもあります。これらは、そのプレフィックスで最初のリクエストが受信された後に表示されます。

なお、最大512のserverまたはupstreamディレクティブがサポートされています。プレフィックス長が255文字を超える場合は無視されます。最後に、統計情報には最大1メガバイトのメモリが割り当てられます。これが枯渇した場合、統計情報収集はサイレントにスキップされます。これは、NGINX設定でprometheus_metrics_shm_sizeで設定できます。

制限事項

nginx-stats-prometheusはnginx-prometheus-exporterのドロップイン代替ではありません。主な違いは以下の通りです。

1. 収集される統計情報が大幅に少ない。
2. プラグインはビルドされたNGINXのバージョンに依存します。NGINXを更新すると、通常プラグインの再ビルドが必要になります。
3. 実戦でのテストが大幅に少ない。明らかに、私たちの統計収集ははるかに成熟しておらず、使用されていません。

ライセンスと貢献

nginx-stats-prometheusはMITライセンスでリリースすることにしました。プルリクエストは歓迎しますので、お気軽にご提出ください。提出前に、少なくとも人間がパッチセットを確認してくれることを願っています。

現在、nginx-stats-prometheusのサポートは提供しておらず、使用から生じる可能性のある問題に対するヘルプを保証することはできません。

結論

コンテナ化せずにNGINXを実行したい、デプロイメントの設定を簡素化したい、あるいは単にプラグインから統計収集を実行するという考え方を好む場合は、nginx-stats-prometheusを試してみてください！