概要

Datadog は、Istio 環境のあらゆる側面を監視するため、以下を実現できます。

• ログを使用して、Envoy および Istio の Control Plane の健全性を評価。
• リクエスト、帯域幅、リソース消費のメトリクスでサービスメッシュのパフォーマンスを詳しく確認。
• Cloud Network Monitoring で、コンテナ、ポッド、サービス間のネットワークコミュニケーションをメッシュ状にマッピング。
• [APM[2 でメッシュを実行してアプリケーションの分散型トレースの詳細を確認。

Istio 環境での Datadog の使用について、詳細はモニターのブログ記事をご参照ください。

セットアップ

コンテナ環境でのインテグレーション構成に関する一般的な説明は、Kubernetes での Autodiscovery を使用したインテグレーションの構成または Docker での Autodiscovery を使用したインテグレーションの構成を参照してください。

この OpenMetrics ベースのインテグレーションには、_最新_モード (use_openmetrics: true) と_レガシー_モード (use_openmetrics: false) があります。すべての最新機能を利用するために、Datadog は_最新_モードを有効にすることを推奨します。詳しくは、OpenMetrics ベースのインテグレーションにおける最新バージョニングとレガシーバージョニングを参照してください。

Istio メトリクスを収集する Datadog のインスタンスが複数ある場合は、すべてのインスタンスで同じモードを使用していることを確認してください。そうしないと、Datadog サイトでメトリクスデータが変動する可能性があります。

[OpenMetrics V1]、[OpenMetrics V2]、または [OpenMetrics V1 and V2] とマークされたメトリクスは、Istio インテグレーションの対応するモードでのみ利用可能です。Istio v1.5+ とマークされたメトリクスは Istio バージョン 1.5 以降で収集されます。

インストール

Istio は Datadog Agent に含まれています。Istio サーバーまたはクラスターに Datadog Agent をインストールし、Istio で Agent を指定します。

Envoy

Envoy プロキシ を Istioで監視する場合は、Envoy インテグレーションを構成します。

構成

メトリクスの収集

Istio v1.5+ を監視するには、Prometheus 形式のメトリクスに対応した Istio アーキテクチャに基づく 2 つの主要なコンポーネントが必要です。

• データプレーン: istio-proxy サイドカーコンテナ
• コントロールプレーン: プロキシを管理する istiod サービス

これらはどちらも istio Agent チェックとして実行されますが、それぞれ異なる責任を持ち、別々に構成されます。

データプレーン構成

デフォルトの istio.d/auto_conf.yaml ファイルは、istio-proxy サイドカーコンテナごとに監視を自動的にセットアップします。Agent は、自動検出した各サイドカーコンテナに対してこのチェックを初期化します。この構成により、これらの各サイドカーコンテナが公開するデータの istio.mesh.* メトリクスを報告できるようになります。

インテグレーションのデータプレーン部分をカスタマイズするには、カスタム Istio コンフィギュレーションファイル istio.yaml を作成してください。このファイルを作成する方法については、Kubernetes 上でのインテグレーションの構成または Docker でのオートディスカバリーを利用したインテグレーションの構成を参照してください。

このファイルには、以下の内容を記載する必要があります。

ad_identifiers:
  - proxyv2
  - proxyv2-rhel8

init_config:

instances:
  - use_openmetrics: true
    send_histograms_buckets: false
    istio_mesh_endpoint: http://%%host%%:15020/stats/prometheus
    tag_by_endpoint: false

追加の構成が必要な場合は、このファイルをカスタマイズしてください。利用可能なすべての構成オプションについては、サンプルの istio.d/conf.yaml を参照してください。

コントロールプレーン構成

Istio のコントロールプレーンを監視し、mixer、galley、pilot、citadel のメトリクスをレポートするには、istiod デプロイメントを監視するように Agent を構成する必要があります。Istio v1.5 以降では、istio-system ネームスペースにある istiod デプロイメントの以下のポッドアノテーションを適用してください。

ad.datadoghq.com/discovery.checks: |
  {
    "istio": {
      "instances": [
        {
          "istiod_endpoint": "http://%%host%%:15014/metrics",
          "use_openmetrics": "true"
        }
      ]
    }
  }

注: Autodiscovery Annotations v2 の構文は Agent v7.36 以降でサポートされています。

このアノテーションは、このポッド内にある Istio コンテナのデフォルトコンテナ名に一致するコンテナ discovery を指定します。もし異なる場合は、このアノテーション ad.datadoghq.com/<CONTAINER_NAME>.checks を、お使いの Istio コンテナの名前 (.spec.containers[i].name) に置き換えてください。

これらのアノテーションの適用方法は、使用する Istio のデプロイメント戦略 (Istioctl、Helm、Operator) によって異なります。ポッドアノテーションの適用方法については、Istio のドキュメントを参照してください。利用可能なすべての構成オプションについては、サンプルの istio.d/conf.yaml を参照してください。

Datadog Agent ポッドのサイドカーインジェクションを無効化

コンテナに Datadog Agent をインストールする場合は、その前に Istio のサイドカーインジェクションを無効にすることをお勧めします。

Istio バージョン >= 1.10:

sidecar.istio.io/inject: "false" ラベルを datadog-agent DaemonSet に追加します。

# (...)
spec:
  template:
    metadata:
      labels:
        sidecar.istio.io/inject: "false"
    # (...)

これは、kubectl patch コマンドでも実行できます。

kubectl patch daemonset datadog-agent -p '{"spec":{"template":{"metadata":{"labels":{"sidecar.istio.io/inject":"false"}}}}}'

Istio バージョン <= 1.9:

sidecar.istio.io/inject: "false" アノテーションを datadog-agent DaemonSet に追加します。

# (...)
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "false"
    # (...)

kubectl patch コマンドを使用します。

kubectl patch daemonset datadog-agent -p '{"spec":{"template":{"metadata":{"annotations":{"sidecar.istio.io/inject":"false"}}}}}'

ログ収集

Agent バージョン 6.0 以降で利用可能

まず、 Kubernetes でログ収集を実行するために Datadog Agent を有効にします。Kubernetes ログ収集を参照してください。

Istio のログ

コントロールプレーン (istiod) から Istio のログを収集するには、istio-system ネームスペース内のデプロイメント istiod に対して、以下のポッドアノテーションを適用してください。

ad.datadoghq.com/discovery.logs: |
  [
    {
      "source": "istio",
      "service": "<SERVICE_NAME>"
    }
  ]

このアノテーションは、このポッド内にある Istio コンテナのデフォルトコンテナ名に一致するコンテナ discovery を指定します。もし異なる場合は、このアノテーション ad.datadoghq.com/<CONTAINER_NAME>.logs を、お使いの Istio コンテナの名前 (.spec.containers[i].name) に置き換えてください。

<SERVICE_NAME> を、希望する Istio サービス名に置き換えてください。

Envoy のアクセスログ

データプレーン (istio-proxy) から Envoy のアクセスログを収集するには、以下の手順を実行してください。

1. Istio 内での Envoy アクセスロギングを有効にします。
2. istio-proxy コンテナが注入されたポッドに、以下のアノテーションを適用してください。

ad.datadoghq.com/istio-proxy.logs: |
  [
    {
      "source": "envoy",
      "service": "<SERVICE_NAME>"
    }
  ]

このアノテーションは、注入された Istio サイドカーコンテナのデフォルトコンテナ名に一致するコンテナ istio-proxy を指定します。もし異なる場合は、このアノテーション ad.datadoghq.com/<CONTAINER_NAME>.logs を、お使いの Istio サイドカーコンテナの名前 (.spec.containers[i].name) に置き換えてください。

<SERVICE_NAME> を、希望する Istio プロキシサービス名に置き換えてください。

検証

Agent の info サブコマンドを実行し、Checks セクションで istio を探します。

収集データ

メトリクス

イベント

Istio チェックには、イベントは含まれません。

サービスチェック

istio.prometheus.health

Returns CRITICAL if the check cannot access the metrics endpoint. Returns OK otherwise.

Statuses: ok, critical

istio.openmetrics.health

Returns CRITICAL if the Agent is unable to connect to the OpenMetrics endpoint, otherwise returns OK.

Statuses: ok, critical

istio.pilot.prometheus.health

Returns CRITICAL if the check cannot access the metrics endpoint. Returns OK otherwise.

Statuses: ok, critical

istio.galley.prometheus.health

Returns CRITICAL if the check cannot access the metrics endpoint. Returns OK otherwise.

Statuses: ok, critical

istio.citadel.prometheus.health

Returns CRITICAL if the check cannot access the metrics endpoint. Returns OK otherwise.

Statuses: ok, critical

トラブルシューティング

無効なチャンク長のエラー

Istio インテグレーション (Istio インテグレーションバージョン 3.13.0 以前) のレガシーモードで以下のエラーが表示された場合

  Error: ("Connection broken: InvalidChunkLength(got length b'', 0 bytes read)",
  InvalidChunkLength(got length b'', 0 bytes read))

このエラーを解決するには、OpenMetrics ベースの Istio インテグレーションの最新モードを使用できます。

最低でも Agent 7.31.0 と Python 3 にアップグレードする必要があります。OpenMetrics を有効にするには、構成のセクションを参照してください。

Istio のデプロイメントで一般的な OpenMetrics インテグレーションを使用する

Istio のプロキシサイドカーインジェクションが有効な場合、istio_mesh_endpoint と同じメトリクスエンドポイントで OpenMetrics インテグレーションを使用して他の Prometheus メトリクスを監視すると、カスタムメトリクス使用量が多く、メトリクス収集が二重になることがあります。

OpenMetrics の構成により、メトリクスの収集が重複しないようにするためには、以下のどちらかを行います。

1. 構成オプション metrics で特定のメトリクスのマッチングを使用するか、または
2. metrics にワイルドカード * 値を使用する場合、以下の OpenMetrics インテグレーションオプションを使用して、Istio および Envoy インテグレーションで既にサポートされているメトリクスを除外することを検討します。

汎用的なメトリクス収集を使用した OpenMetrics の最新モード構成

カスタムメトリクスの高額請求を避けるため、必ず Istio と Envoy のメトリクスを構成から除外してください。openmetrics_endpoint が有効になっている場合は exclude_metrics を使用します。

## 各インスタンスは、他のインスタンスとは独立してスケジュールされます。
#
instances:
  - openmetrics_endpoint: <OPENMETRICS_ENDPOINT>
    metrics:
    - '.*'
    exclude_metrics:
      - istio_.*
      - envoy_.*

汎用的なメトリクス収集を使用した OpenMetrics のレガシーモード構成

カスタムメトリクスの高額請求を避けるため、必ず Istio と Envoy のメトリクスを構成から除外してください。prometheus_url が有効になっている場合は ignore_metrics を使用します。

instances:
  - prometheus_url: <PROMETHEUS_URL>
    metrics:
      - '*'
    ignore_metrics:
      - istio_*
      - envoy_*

ご不明な点は、Datadog のサポートチームまでお問い合わせください。

その他の参考資料

お役に立つドキュメント、リンクや記事:

• Datadog を使用した Istio サービスメッシュの監視
• Datadog でキーメトリクスを収集して Istio を監視する方法
• Datadog を使用した Istio の監視方法