Kongとは

Kongはマルチクラウド、ハイブリッド環境でも利用できる、オープンソースのAPIゲートウェイです。

例えばマイクロサービスアーキテクチャを採用の場合、サービスディスカバリや認証など、全てのサービス共通で持っておかないといけない、APIの機能をKongが担います。

それでは、New Relicを使ってKongを採用しているアーキテクチャを観測するために設定をしていきましょう。

本ブログでは、以下の要素を使って設定を進めます。

分散トレーシングの設定

• Kong: Zipkin プラグイン
• New Relic: Trace API

メトリクスの設定

• Kong: Prometheus プラグイン
• New Relic: Infrastructure Flex

観測するデモアプリケーション

観測するデモアプリケーションは、Dockerとして提供されているKongを利用しており、２つのアプリケーションで通信が発生する構成となっています。

分散トレーシングの設定

分散トレーシングの設定では、すでに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キーを登録してください。

登録したキーはステップ３で利用します。

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=${ステップ１で取得したAPIキー}&Data-Format=zipkin&Data-Format-Version=2", "sample_ratio": 1, "traceid_byte_count": 16, "header_type": "w3c" }}'

New Relic上で確認する

設定ができたら、New Relic上でトレース情報がどうなっているかを確認できます。

Entity数はKongを含む３となっており、分散トレーシングも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をご利用いただければ、

トレース全体が観測できることをご理解いただけたと思います。

アプリケーションのコードや既存の設定に手を入れることなく、少ない手順でえご利用いただけますので、ぜひご活用ください。