クイズです。コンテナ環境で一番使われているテクノロジーは何でしょうか？ 答えは。。
一番使われているコンテナはnginx
Datadog調べによると、Dockerのコンテナで一番よく使われているテクノロジーはnginxだそうです。
8 Surprising facts about real Docker adoption
特にKubernetes環境では、全企業の内70%でnginxのイメージが使われているそうです。
8 Facts about real-world container use
世界のWebサーバーのシェアNo.1となったnginxですが、その高速さやシンプルさで人気があり、クラウド、オンプレ、サーバー、コンテナ問わず広く使われています。ですので、nginxの稼働状況をいろいろな観点で観測する機会は多いと思います。今日はDatadogでnginxを観測し尽くすことを目指してまとめていきます。
メトリクス
まずはメトリクスから。メトリクスとは主に数値情報で、アクセス数やエラーの数など計測可能な数値情報を一定時間ごとに収集するものです。例えばアクセス数は、nginx.net.request_per_sというメトリクスに収められます。
これらの数値はnginxのstub statusモジュールから収集します。stub statusモジュールを適当なパスにマップすると以下のように現在の接続状況が取得できます。
$ curl localhost/nginx_status
Active connections: 1
server accepts handled requests
93370 93370 74159
Reading: 0 Writing: 1 Waiting: 0
下から2行目の3つの数字は、受け付けたコネクション数(accepts)、処理したコネクション数(handled)、リクエスト数(requests)です。Datadogのエージェントはnginxインテグレーションにより、デフォルトで15秒に一度このURLにアクセスしてデータを取得して、Datadogに送り、上のようなグラフに視覚化します。
なお、有償版のNGINX Plusでは、パフォーマンスデータがAPI経由で提供されているため、はるかに多彩なメトリクスが得られます。DatadogでもNGINX PlusのAPIに対応しており、フリー版nginxでは7つのメトリクスが得られるところ、NGINX Plusでは130以上のメトリクスが取得できます。
ログ
次はログです。nginxのログ形式は自由に設定できますが、多くの場合はドキュメントに書かれているcombinedを使われていることが多いのではないでしょうか。実はnginxはそれ以外にも処理時間を保持する変数$request_timeを持っているので、Datadogではそれをログに含めることを推奨しています。具体的な設定としてはドキュメントにあるとおり、$request_timeを下記の位置$body_bytes_sentの後に追加してください。
http {
#推奨ログフォーマット
log_format nginx '\$remote_addr - \$remote_user [\$time_local] '
'"\$request" \$status \$body_bytes_sent \$request_time '
'"\$http_referer" "\$http_user_agent"';
access_log /var/log/nginx/access.log;
}
nginxのログはデフォルトではプレインテキスト形式なので、Datadog側では転送された後に構造化するためのルールが必要で、それもnginxインテグレーションに含まれています。このルールは上記のログ形式に対応しているので、$request_timeを追加しても自動的に検知して構造化します。
下のスクリーンショットはログの一例で、上側のテキストログの赤枠に$request_timeの値として0.132が入っていて、それが構造化処理後にはduration: 1320000という値になっています。
この情報があるとパフォーマンスの統計が取れますし、遅いログだけ抜き出すことも簡単にできます。以下の例では10秒以上処理にかかっているログだけを抜き出します。
あと、後述のトレースとログを関連づけるために、ログにtrace_idを付加したい場面が出てくると思いますが、その場合も同様にnginx側の設定でカスタムログ形式を設定し、OpenTracingの例のlog_formatの部分を参考に、Trace IDをログに含めてください。この場合Datadog側では構造化処理のルールをカスタマイズする必要があります。
トレース
nginxは元々は静的なコンテンツを提供するWebサーバーとして使われることが多かったかと思いますが、近年では動的なコンテンツを提供するサーバーの前段に配置して、リバースプロキシとして使用するケースが増えてきていると思います。アプリサーバーのリバースプロキシとして、また複数台のアプリサーバーへのロードバランサーとして広く活用されています。
APM(Application Performance Monitoring)では、アプリのトレースを生成して、リクエスト数、レイテンシー、エラーなどの情報を収集し、アプリのパフォーマンスや健全性を可視化します。またマイクロサービスなどの分散環境では、分散トレーシングとして、サービス間の呼び出し関係を含めて可視化できるため、サービス全体が遅くなっている時に、どの部分で遅くなっているのかが一目瞭然になります。
一般的に、APMではWebアプリケーションなどにトレースライブラリを組み込んで、トレースを収集しますが、実はnginxでもOpenTracingのモジュールを組み込むことで、分散トレーシングの一部として観測することができます。
スクリーンショット内の長方形の帯１つ１つがスパンと呼ばれるアプリの処理単位です。横軸が時間、縦軸が呼び出し関係です。上のスパンが親となり下のスパンを呼び出しています。ここで一番上のグリーンのスパン、つまりユーザーから見て一番手前に位置するサービスがnginxであることにお気づきかと思います。このようにnginxも分散トレーシングの一部として可視化できます。
この例では、nginxをリバースプロキシとして、その後ろにnode.jsのアプリ、さらにmysqlのデータベースが動いています。nginxにはopentracingを組み込んで、トレースを生成してDatadog Agentに送り、Datadogへ転送されています。
これらをまとめたサンプルを以下のレポジトリに置いています。docker環境があればdocker-composeで簡単にすぐ試せますので、設定や動きをぜひ見てみてください。
ここで使っているOpenTracing関連の情報リンクです。
- Open tracing module
- Datadog Open tracing plug-in
また、ログの項の最後で説明したようにtrace_idをログに含めて出力してDatadogに送っていますので、APMとも関連づけられ、Logsタブで確認できます。
以上nginxをDatadogで観測し尽くそうの巻でした。
Happy Datadogging!