Kongとは
Kongはマルチクラウド、ハイブリッド環境でも利用できる、オープンソースのAPIゲートウェイです。
例えばマイクロサービスアーキテクチャを採用の場合、サービスディスカバリや認証など、全てのサービス共通で持っておかないといけない、APIの機能をKongが担います。
それでは、New Relicを使ってKongを採用しているアーキテクチャを観測するために設定をしていきましょう。
本ブログでは、以下の要素を使って設定を進めます。
分散トレーシングの設定
- Kong: Zipkin プラグイン
- New Relic: Trace API
メトリクスの設定
- Kong: Prometheus プラグイン
- New Relic: Infrastructure Flex
観測するデモアプリケーション
観測するデモアプリケーションは、Dockerとして提供されているKongを利用しており、2つのアプリケーションで通信が発生する構成となっています。
分散トレーシングの設定
分散トレーシングの設定では、すでにKongの設定が終わり、各アプリケーションにはNew Relic APMが導入されていることを前提に進めていきます。
フォーマットの仕様確認
分散トレーシングに必要なトレースコンテキストのフォーマットはNew Relicも参加し標準化が進んでいます。
以前New Relicは独自のフォーマットを利用していたのですが、先日W3C Trace Contextのサポートを開始しました。
https://blog.newrelic.co.jp/product-news/distributed-tracing-interoperability-new-relic-apm-w3c-trace-context/
一方、設定対象のKongはZipkinをPluginで利用できます。これまではB3フォーマットが採用されていたのですが、
先日W3C headerが対応され、仕様としてはNew Relicで分散トレーシングを観測できる状態となりました。
Kong Changelog 2.0 - Zipkin W3C header 対応
New Relic、Kong双方が分散トレーシングの標準化を進めたことで、New Relic上で非常に簡単にKongを採用している場合でも
簡単に分散トレーシングができるようになりました。
設定手順
3ステップで設定を行います。
1, New RelicのInsert API Keyの登録
Zipkinトレーシング情報をNew Relicに送信するために、New RelicのAPIキーが必要です。
こちらのドキュメントを参考に、APIキーを登録してください。
登録したキーはステップ3で利用します。
2, SSL通信の証明書の有効化(行っていない場合)
Kongから外部にAPI接続を行うので、SSL通信ができるようにしましょう。
kong.confファイルの"lua_ssl_trusted_certificate"の設定を変更してください。
lua_ssl_trusted_certificate = /etc/ssl/certs/ca-certificates.crt
3, KongのZipkinプラグインの設定
Kong上のサービスなどはすでに設定されている前提で、Kong Zipkinプラグインを設定していきます。
Zipkinプラグインのドキュメントを確認し、デモ環境では以下のようにリクエストを投げています。
グローバル設定としてZipkinが有効となるように設定を追加しており、sample_ratio=1としているので、全てのトレースをNew Relicに送るようにしています。
設定は適宜変更の上ご利用ください。
endpointのURLはこちらのドキュメントをご参考いただけます。
curl -X POST http://localhost:8001/plugins/ -H 'Content-Type: application/json' --data '{"name": "zipkin", "config": {"http_endpoint": "https://trace-api.newrelic.com/trace/v1?Api-Key=${ステップ1で取得したAPIキー}&Data-Format=zipkin&Data-Format-Version=2", "sample_ratio": 1, "traceid_byte_count": 16, "header_type": "w3c" }}'
New Relic上で確認する
設定ができたら、New Relic上でトレース情報がどうなっているかを確認できます。
Entity数はKongを含む3となっており、分散トレーシングもUI上でKongを挟んだ内容を確認できるようになります。
また、サービスマップ上ではproxyの役目を果たしたKongは写っておらず、ビジネスロジックを確認するためのNew RelicAPMが導入されているサービスが表示されます。
何か問題のあった場合見るべきところはKongよりもビジネスロジッk側であることが多いと思われますので、それをシンプルに確認できるような
動きとなっています。
以上で分散トレーシングの設定は終わりです。
非常に簡単に分散トレーシングを導入できるので、マイクロサービス全体をトレースするためにぜひご活用ください。
メトリクスの設定
次にメトリクスを収集し、Kongからみたサービスの状況がどうなっているのかを確認しましょう。
メトリクスの設定では、すでにKongの設定が終わり、ホストにNew Relic Infrastructureが導入されていることを前提に進めていきます。
設定手順
3ステップで設定を行います。
1, KongのPrometheusプラグインの設定
Kong Prometheusプラグインのドキュメントを参考に、
Prometheus プラグインを設定してください。
2, New Relic Infrastructure Flexの設定
New Relicは多くのサービスやフレームワークとのインテグレーションを提供しているのですが、独自に設定を行ういことができます。
ここではNew Relic Infrastructure Flexを利用してメトリクスを収集してみます。
New Relic Infrastructureが導入されている場合、設定ファイルを追加するだけでPrometheus exporterから情報収集を始められます。
設定ファイル:/etc/newrelic-infra/integrations.d/kong-prometheus.yml
integrations: - name: nri-flex # interval: 30s config: name: kongPrometheusMetrics apis: - name: kongMetrics url: http://localhost:8001/metrics prometheus: enable: true
また、Prometheus exporterだけでなく、Kongに標準的に用意されているエンドポイントからも情報を収集できます。
設定ファイル:/etc/newrelic-infra/integrations.d/kong.yml
integrations: - name: nri-flex # interval: 30s config: name: kongFlex global: base_url: http://localhost:8001/ headers: accept: application/json apis: - event_type: kongStatusSample url: status snake_to_camel: true - event_type: kongUpstreamSample url: upstreams snake_to_camel: true remove_keys: - healthchecks.active.unhealthy.http_statuseSamples ### these 4 are just an array of status codes, that are deemed to fall into each category, so no need to be added - healthchecks.passive.healthy.http_statuseSamples - healthchecks.passive.unhealthy.http_statuseSamples - healthchecks.active.healthy.http_statusesPrometheusSamples
他にも多くの設定サンプルが用意されていますので、併せてご確認ください。
ダッシュボード作成
Prometheus プラグイン経由で収集したデータを利用してダッシュボードを作成しました。
こちらの記事通りの設定をした場合にコピペで利用できるNRQLですので、ご活用ください。
応答速度(秒)
FROM kongMetricsSample SELECT derivative(kong_latency.histogram.sum, 1 minute)/derivative(kong_latency.histogram.count, 1 minute)/1000 WHERE type IN('upstream', 'kong') TIMESERIES FACET service, type
スループット(分間)
FROM kongMetricsSample SELECT derivative(kong_http_status.counter, 1 minute) TIMESERIES
利用帯域(GB)
FROM kongMetricsSample SELECT derivative(kong_bandwidth.counter, 1 minute)/1024/1024 TIMESERIES FACET service
レスポンスコード別比較
FROM kongMetricsSample SELECT derivative(kong_http_status.counter, 1 minute) TIMESERIES FACET code
リクエストドロップ数
FROM kongMetricsSample SELECT filter(latest(kong_nginx_http_current_connections.gauge), where state = 'accepted') - filter(latest(kong_nginx_http_current_connections.gauge), where state = 'handled') as 'accepted - handled' TIMESERIES
upstream処理欠損
FROM kongMetricsSample SELECT filter(derivative(kong_latency.histogram.count, 1 minute), where type = 'request') - filter(derivative(kong_latency.histogram.count, 1 minute), where type = 'upstream') as 'request - upstream' TIMESERIES
まとめ
KongのNew Relicでの観測として、分散トレーシング、メトリクスの設定を解説しました。
マイクロサービスアーキテクチャで効果を発揮するKongのAPIゲートウェイですが、New Relicをご利用いただければ、
トレース全体が観測できることをご理解いただけたと思います。
アプリケーションのコードや既存の設定に手を入れることなく、少ない手順でえご利用いただけますので、ぜひご活用ください。
The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.