コンテンツにスキップ
|
Kong Gateway
3.4.x LTS
report-issue問題を報告する
旧バージョンのドキュメントを参照しています。 最新のドキュメントはこちらをご参照ください。

PrometheusのVitals

このドキュメントでは、Kong Vitals を新規または既存の Prometheus 時系列サーバーまたはクラスタと統合する方法について説明します。Vitals データ用の時系列データベースを活用することで、Kong クラスタを支えるデータベースに追加の書き込み負荷をかけることなく、非常に高いトラフィック Kong Gateway クラスタ（数万または数十万のデータを処理する環境など）でのリクエストおよび Vitals のパフォーマンスを向上させることができます。

バックエンドとしてのデータベースで Vitals を使用する場合は、Kong Vitals を参照してください。

ライフサイクルの概要

Kong Vitalsは、中間データエクスポーターであるPrometheus StatsDエクスポーターを使用してPrometheusと統合します。 この統合によりKongは、Kongプロキシ自体の中でパフォーマンスを低下させることなく、 データポイントを集計してPrometheusが利用できるようにする外部プロセスに、Vitalsのメトリクスを効率的に 送信できるようになります。この設計では、KongはVitalsメトリクスを StatsDメトリクスとしてStatsDエクスポーターに書き込みます。Prometheus は、他のエンドポイントと同じように、このエクスポーターをスクレイピングします。次に、KongはPrometheusにクエリし、APIとKong Managerを介してVitalsデータを取得して表示します。Prometheusは、時系列データのためにをKongノードを直接スクレイピングすることはありません。単純化されたワークフローは、次のようになります。

単一ノードのデータフローの例

Kongの機能をノードのクラスタ間で分離することは珍しいことではありません。たとえば、1つ以上のノードがプロキシトラフィックのみを処理し、別のノードがKong Admin APIとKong Managerの処理を担当する場合です。この場合、プロキシトラフィックを担当するノードはStatsDエクスポーターにデータを書き込み、Admin APIを担当するノードはPrometheusから読み取ります。

複数ノードのデータフローの例

どちらの場合でも、StatsDエクスポータープロセスは、スタンドアロンのプロセス/コンテナ 、あるいはVM内のサイドカー/隣接プロセスとして実行できます。トラフィック量の多い環境では、StatsDエクスポータープロセス内のデータ集計によって CPU使用率が大幅に増加する可能性があります。そのような場合には、 CPU使用率が飽和するのを避けるため、KongプロセスとStatsDプロセスを別々のハードウェア/VM/コンテナ環境で実行します。

Vitals の Prometheus 環境を設定する

Prometheusのダウンロード

Prometheusの最新リリースは、Prometheusダウンロードページにあります。

Prometheus は、Kongを実行しているノードとは別のノードで実行する必要があります。すでにインフラでPrometheusを使用しているユーザーは、既存のPrometheusノードをVitalsストレージバックエンドとして使用できます。

このガイドでは、Prometheusがホスト名prometheus-nodeで実行されていると仮定します。ポート9090でリッスンするデフォルト設定を使用します。

StatsDエクスポーターのダウンロードと構成

StatsDエクスポーターはDockerイメージとして配布されています。次のコマンドで 最新バージョンをプルします。

docker pull kong/statsd-exporter-advanced:0.3.1

バイナリには、パブリックプロジェクトではサポートされていない最小/最大ゲージやUnixドメインソケットのサポートなどの機能が含まれています。

このDockerイメージは、PrometheusコミュニティプロジェクトのKongフォークであり、下記でリンクされているマッピングルールは公開イメージでは動作しません。適切なものを使用していることを確認してください。

PrometheusコミュニティのHelmチャートを使ってエクスポーターをデプロイする場合は、以下のようにvaluesファイルのイメージとタグをオーバーライドします。

image:
 repository: kong/statsd-exporter-advanced
 tag: 0.3.1

StatsDエクスポーターは、StatsD UDP イベントをPrometheus メトリックに 変換するためのマッピングルールのセットを設定する必要があります。マッピングルールの デフォルトセットは statsd.rules.yamlからダウンロード可能です。 次に、StatsD エクスポーターを次のように開始します。

./statsd_exporter --statsd.mapping-config=statsd.rules.yaml \
                    --statsd.listen-unixgram=''

StatsDマッピングルールファイルは、Kongから送信されたメトリックと一致するように構成する必要があります。StatsDイベント名をカスタマイズする方法については、KongのPrometheusストラテジでVitalsを有効にするセクションを参照してください。

StatsDエクスポーターは、Kongとは別のノードで実行する（Kongとのリソースの競合を避けるため）ことも、Kongと同じホストで実行する（不要なネットワークオーバーヘッドを削減するため）こともできます。

このガイドでは、StatsDエクスポーターがホスト名statsd-nodeで実行され、 ポート9125のUDPトラフィックをリッスンするデフォルト設定を使用し、 Prometheus公開形式のメトリクスがポート9102で公開されていると仮定しています。

StatsD エクスポーターをスクレイピングするための Prometheus 構成

StatsDエクスポーターをスクレイピングするようにPrometheusを構成するには、scrape_configsにprometheus.yaml形式で次のセクションを追加します。

scrape_configs:
  - job_name: 'vitals_statsd_exporter'
    scrape_interval: "5s"
    static_configs:
      - targets: ['statsd-node:9102']

StatsD エクスポーターを実行する実際のホスト名でstatsd-nodeを更新してください。

サービスディスカバリを使用している場合、Prometheusに複数のStatsDエクスポーターを構成した方が便利です。 詳細は、Prometheusドキュメントの scape_configs セクションをお読みください。

デフォルトでは、Kong ManagerのVitalsグラフは凡例で設定されたターゲットアドレスを使用します。 これは、Prometheus メトリックラベルではinstanceと名付けられています。instance が IP:PORT のサービスディスカバリ設定については、 ユーザーは instance のラベルを付け直し、 よりわかりやすいホスト名を凡例に表示できるものもあります。 そのためには、ユーザーは scape_configs セクションを参照し、instance ラベルを対応するメタラベルに書き直します。

たとえば、Kubernetes環境では次の再ラベル付けルールを使用します。

scrape_configs:
  - job_name: 'vitals_statsd_exporter'
    kubernetes_sd_configs:
      # your SD config to filter statsd exporter pods
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_name]
        action: replace
        target_label: 'instance'

KongでPrometheusストラテジを使用してVitalsを有効にする

構成でこれを変更して、PrometheusでVitalsを有効にすることができます。

# via your Kong configuration file
vitals = on
vitals_strategy = prometheus
vitals_statsd_address = statsd-node:9125
vitals_tsdb_address = prometheus-node:9090

# or via environment variables
export KONG_VITALS=on
export KONG_VITALS_STRATEGY=prometheus
export KONG_VITALS_STATSD_ADDRESS=statsd-node:9125
export KONG_VITALS_TSDB_ADDRESS=prometheus-node:9090

注 ：ハイブリッドモードでは、コントロールプレーンとすべてのデータプレーンの両方でvitals_strategyとvitals_tsdb_addressを構成します。

StatsDエクスポーターとPrometheusを実行する実際のホスト名でstatsd-nodeとprometheus-nodeを更新してください。

他のKong構成と同様に、変更は kong reload または kong restart。

Prometheusで scrape_interval をデフォルト値の 5 秒以外に設定した場合、以下も更新する必要があります。

# via your Kong configuration file
vitals_prometheus_scrape_interval = new_value_in_seconds

# or via environment variables
export KONG_VITALS_PROMETHEUS_SCRAPE_INTERVAL=new_value_in_seconds

上記のオプションは、Prometheusをクエリするときにintervalパラメータを構成します。値new_value_in_secondsは、Prometheusのscrape_interval構成と等しいかそれより大きくなければなりません。

また、Kongを構成してkongのデフォルト値から異なる接頭辞を使用してStatsDイベントを送信することもできます。statsd.rulesの接頭辞がKongの構成と同じであることを確実にしてください。

# via your Kong configuration file
vitals_statsd_prefix = kong-vitals

# or via environment variables
export KONG_VITALS_STATSD_PREFIX=kong-vitals

# in statsd.rules
mappings:
# by API
- match: kong-vitals.api.*.request.count
  name: "kong_requests_proxy"
  labels:
    job: "kong_metrics"
# follows other metrics
# ...

Grafanaダッシュボードのインストール

Grafanaを使用している場合は、Kong Vitals Prometheusのダッシュボードをインポートしてデータを視覚化できます。

Grafanaインストールで、サイドバーの + ボタンをクリックし、 インポート を選択します。

[インポート] 画面で [Grafana.com ダッシュボード] フィールドを見つけて、「11870」と入力します。次に [ロード] をクリックします。オプションで、 https://grafana.com/grafana/dashboards/11870からJSONモデルをダウンロードして手動でインポートすることもできます。

次の画面で、 statsd-exporterをスクレイピングするように設定された Prometheus データソースを選択し、 インポート をクリックします。

チューニングと最適化

StatsD エクスポーターの UDP バッファ

同時リクエストの量が増加すると、処理されていないUDPイベントを格納するキューの長さも増加します。パケットのドロップを避けるためには、UDP読み取りバッファサイズを増やす必要があります。

StatsDエクスポータープロセスのUDP読み取りバッファを増やすには、 次の例を使用してバイナリを実行し、読み取りバッファを約3MBに設定します。

./statsd_exporter --statsd.mapping-config=statsd.rules.yaml \
                    --statsd.listen-unixgram='' \
                    --statsd.read-buffer=30000000

実行中のホストの UDP 読み取りバッファを増やすには、次の例で示す行を /etc/sysctl.conf に追加します.

net.core.rmem_max = 60000000

そして、以下のようにルート権限で設定を適用してください。

# sysctl -p

Unixドメインソケットを使用したStatsDエクスポーター

StatsD エクスポーターを Kong と同じノードにデプロイし、エクスポーターをローカル Unix ドメインソケットでリッスンさせることで、ネットワークのオーバーヘッドをさらに削減できます。

./statsd_exporter --statsd.mapping-config=statsd.rules.yaml \
                    --statsd.read-buffer=30000000 \
                    --statsd.listen-unixgram='/tmp/statsd.sock'

デフォルトではソケットは権限0755で作成されるため、 StatsDエクスポーターはKongと同じユーザーを実行して、KongがソケットにUDPパケットを書き込めるように しなければなりません。エクスポーターとKongが異なるユーザーとして実行できるように するため、ソケットは0777権限と次のもので作成できます。

./statsd_exporter --statsd.mapping-config=statsd.rules.yaml \
                    --statsd.read-buffer=30000000 \
                    --statsd.listen-unixgram='/tmp/statsd.sock' \
                    --statsd.unixsocket-umask="777"

エクスポートされたメトリクス

上記の構成により、Prometheus StatsDエクスポーターは、標準Vitals構成によって提供されたすべてのメトリクスを利用可能にします。

さらに、エクスポータープロセスは、Golang Prometheus クライアントライブラリによって公開されるデフォルトのメトリクスへのアクセスを提供します。これらのメトリクス名は、 go_およびprocess_接頭辞を含めます。これらのデータポイントは Kong ではなく、StatsD エクスポータープロセス自体に特に関連しています。インフラチームにとってこのデータは有益かもしれませんが、 Kongの行動を監視するという点では価値が限られています。

Prometheus から Vitals メトリクスにアクセスする

Prometheus で Kong Vitals のメトリクスにアクセスし、Grafana に表示 またはアラートルールを設定することができます。StatsD のマッピングルールの例では、すべてのメトリクスに exported_job=kong_vitals のラベル付けがされます。上記の Prometheus スクレイピング設定で 、すべてのメトリクスに job=vitals_statsd_exporter というラベルも付けられます。