メトリクスとログ FAQ

Prometheus¹を使用してIstioに関するテレメトリデータを収集できます。そして、PrometheusのHTTP API²を使用してそのデータをクエリできます。

プロキシ内テレメトリ（v2）は、Mixerベースのテレメトリ（v1）アプローチと比較して、リソースコストを削減し、プロキシのパフォーマンスを向上させます。また、Istioでテレメトリを表面化するための推奨メカニズムです。ただし、v1とv2の間で報告されるテレメトリにはいくつかの違いがあり、以下にリストします。

• メッシュ外トラフィックのラベルの欠落 プロキシ内テレメトリは、ピアのワークロード名、名前空間、ラベルなどの情報を収集するために、Envoyプロキシ間のメタデータ交換に依存しています。Mixerベースのテレメトリでは、この機能は、Mixerがリクエスト属性とプラットフォームデータを結合する一部として実行していました。このメタデータ交換は、こちらで説明されているように、HTTPプロトコルの場合は特定のHTTPヘッダーを追加するか、TCPプロトコルの場合はALPNプロトコルを拡張することによって、Envoyプロキシによって実行されます。これは、Envoyプロキシがクライアントとサーバーの両方のワークロードにインジェクトされる必要があることを意味します。つまり、一方のピアがメッシュ内にない場合に報告されるテレメトリには、ワークロード名、名前空間、ラベルなどのピア属性が欠落します。ただし、両方のピアにプロキシがインジェクトされている場合、こちら³で言及されているすべてのラベルが生成されたメトリクスで利用可能です。サーバーのワークロードがメッシュの外にある場合でも、サーバーのワークロードメタデータはクライアントサイドカーに配布されるため、クライアント側のメトリクスにはサーバーのワークロードメタデータラベルが入力されます。

• TCPメタデータ交換にはmTLSが必要 TCPメタデータ交換は、Envoyプロキシがメタデータを正常に交換できるようにするために、相互TLS（mTLS）が有効になっている必要があるIstio ALPNプロトコルに依存しています。これは、クラスターでmTLSが有効になっていない場合、TCPプロトコルのテレメトリには、ワークロード名、名前空間、ラベルなどのピア情報が含まれないことを意味します。

• ヒストグラムメトリクスのカスタムバケットを構成するメカニズムがない Mixerベースのテレメトリは、リクエスト期間やTCPバイトサイズなどのヒストグラムタイプのメトリクスのバケットをカスタマイズすることをサポートしていました。プロキシ内テレメトリには、そのような利用可能なメカニズムがありません。さらに、プロキシ内テレメトリのレイテンシーメトリクスで使用できるバケットは、Mixerベースのテレメトリの秒単位と比較してミリ秒単位です。ただし、プロキシ内テレメトリでは、低レイテンシーレベルで、レイテンシーメトリクスのデフォルトでより多くのバケットが利用可能です。

• 短命なメトリクスのメトリクス有効期限がない Mixerベースのテレメトリは、設定可能な時間の間生成されなかったメトリクスがPrometheusによる収集のために登録解除されるメトリクス有効期限をサポートしていました。これは、1回限りのジョブなど、短命なメトリクスを生成するシナリオで役立ちます。メトリクスの登録解除は、将来変更されないメトリクスのレポートを防止し、それによりPrometheusでのネットワークトラフィックとストレージを削減します。この有効期限メカニズムは、プロキシ内テレメトリでは利用できません。この回避策はこちらにあります。

短命なメトリクスは、多くの場合ラベルカーディナリティの大きな原因であるため、Prometheusのパフォーマンスを妨げる可能性があります。カーディナリティは、ラベルの一意の値の数を測定したものです。短命なメトリクスがPrometheusに与える影響を管理するには、まずカーディナリティの高いメトリクスとラベルを特定する必要があります。Prometheusは、/statusページでカーディナリティ情報を提供します。追加情報は、PromQL経由⁴で取得できます。Istioメトリクスのカーディナリティを削減するには、いくつかの方法があります。

• ホストヘッダーのフォールバックを無効にします。destination_serviceラベルは、カーディナリティが高くなる可能性のある原因の1つです。destination_serviceの値は、Istioプロキシが他のリクエストメタデータから宛先サービスを判別できない場合、デフォルトでホストヘッダーになります。クライアントがさまざまなホストヘッダーを使用している場合、これにより、destination_serviceの多数の値が発生する可能性があります。この場合は、メッシュ全体でホストヘッダーのフォールバックを無効にするには、メトリクスカスタマイズ⁵ガイドに従ってください。特定のワークロードまたは名前空間に対してホストヘッダーフォールバックを無効にするには、統計EnvoyFilter構成をコピーし、ホストヘッダーフォールバックが無効になるように更新し、より具体的なセレクターで適用する必要があります。この問題⁶には、これを実現する方法の詳細が記載されています。
• 収集から不要なラベルを削除します。カーディナリティの高いラベルが必要ない場合は、tags_to_removeを使用してメトリクスカスタマイズ⁵を介してメトリクス収集から削除できます。
• フェデレーションまたは分類を通じて、ラベル値を正規化します。ラベルによって提供される情報が必要な場合は、Prometheusフェデレーションまたはリクエスト分類⁷を使用してラベルを正規化できます。

Mixerは、Istio 1.8リリースで削除されました。Mixerの組み込みアダプターまたはメッシュ拡張用のプロセス外アダプターにまだ依存している場合は、移行が必要です。

組み込みアダプターの場合、いくつかの代替手段が提供されています。

• PrometheusとStackdriverの統合は、プロキシ拡張機能⁸として実装されます。これら2つの拡張機能によって生成されるテレメトリのカスタマイズは、リクエスト分類⁷とPrometheusメトリクスカスタマイズ⁵によって実現できます。
• グローバルおよびローカルレート制限（memquotaおよびredisquotaアダプター）機能は、Envoyベースのレート制限ソリューション⁹を通じて提供されます。
• OPAアダプターは、OPAポリシーエージェントとの統合¹⁰をサポートするEnvoy ext-authzベースのソリューション¹¹に置き換えられます。

カスタムプロセス外アダプターの場合は、Wasmベースの拡張機能への移行を強くお勧めします。Wasmモジュールの開発¹²と拡張機能の配布¹³に関するガイドを参照してください。一時的な解決策として、MixerでEnvoy ext-authzとgRPCアクセスログAPIのサポートを有効¹⁴にすることができます。これにより、プロセス外アダプターを使用して1.7 Mixerを使用しながら、Istioを1.7以降のバージョンにアップグレードできます。これにより、Wasmベースの拡張機能に移行するための時間が増えます。この一時的なソリューションは実戦テストされておらず、2021年2月以降サポート期間が終了したIstio 1.7ブランチでのみ利用可能であるため、パッチ修正は期待できないことに注意してください。

docker-composeを使用してPrometheusをインストールできます。

トレース¹⁵を有効にして、Istioでのリクエストのフローを特定できます。

さらに、次のコマンドを使用して、メッシュの状態について詳しく知ることができます。

• istioctl proxy-config: Kubernetesで実行している場合のプロキシ構成に関する情報を取得します。

  # Retrieve information about bootstrap configuration for the Envoy instance in the specified pod.
  $ istioctl proxy-config bootstrap productpage-v1-bb8d5cbc7-k7qbm
  
  # Retrieve information about cluster configuration for the Envoy instance in the specified pod.
  $ istioctl proxy-config cluster productpage-v1-bb8d5cbc7-k7qbm
  
  # Retrieve information about listener configuration for the Envoy instance in the specified pod.
  $ istioctl proxy-config listener productpage-v1-bb8d5cbc7-k7qbm
  
  # Retrieve information about route configuration for the Envoy instance in the specified pod.
  $ istioctl proxy-config route productpage-v1-bb8d5cbc7-k7qbm
  
  # Retrieve information about endpoint configuration for the Envoy instance in the specified pod.
  $ istioctl proxy-config endpoints productpage-v1-bb8d5cbc7-k7qbm
  
  # Try the following to discover more proxy-config commands
  $ istioctl proxy-config --help
  

• kubectl get: メッシュ内のさまざまなリソースに関する情報を、ルーティング構成とともに取得します。

  # List all virtual services
  $ kubectl get virtualservices
  

はい。Prometheus¹⁶は、オープンソースの監視システムであり、時系列データベースです。IstioでPrometheusを使用して、Istioの健全性とサービスメッシュ内のアプリケーションの健全性を追跡するメトリクスを記録できます。Grafana¹⁷やKiali¹⁸などのツールを使用してメトリクスを視覚化できます。メトリクスの収集を有効にする方法については、Prometheusの構成を参照してください。

いくつかの注意点：

• istiodポッドが必須の証明書を生成してPrometheusに配布する前にPrometheusポッドが開始された場合、相互TLSで保護されたターゲットから収集するためにPrometheusポッドを再起動する必要があります。
• アプリケーションが専用ポートでPrometheusメトリクスを公開する場合は、そのポートをサービスとデプロイ仕様に追加する必要があります。