Anthos Service Mesh と Traffic Director は Cloud Service Mesh になりました。詳細については、Cloud Service Mesh の概要をご覧ください。

Cloud Service Mesh でのオブザーバビリティとテレメトリーの問題を解決する

このセクションでは、Cloud Service Mesh の一般的な問題とその解決方法について説明します。さらにサポートが必要な場合は、サポートの利用をご覧ください。

Cloud Service Mesh テレメトリーでは、Envoy プロキシが定期的に Google Cloud Observability API を呼び出してテレメトリーデータを報告します。API 呼び出しのタイプによって頻度が決まります。

ロギング: 約 10 秒ごと
指標: 約 1 分ごと
Edge（Context API / トポロジビュー）: 約 1 分ごとに差分レポートを生成し、完全なレポートは約 10 分ごとになります。
トレース: 構成したサンプリング頻度で決定（通常は 100 リクエストごとに 1 回）

テレメトリーダッシュボードでは、Confluence と Google Cloud Observability の両方からデータが収集され、各サービスに特化したダッシュボードが表示されます。

Istio テレメトリー API 構成が 1 つだけであることを確認する

このセクションは、マネージド Cloud Service Mesh コントロールプレーンにのみ適用されます。

Telemetry API の構成を一覧表示するには、次のコマンドを実行します。 Istio Telemetry API 構成が 1 つだけであることを確認します。

kubectl -n istio-system get telemetry

サービスダッシュボードにサービスが表示されない

ダッシュボードに HTTP(S) / gRPC サービスのみが表示されます。リストに目的のサービスが表示されていない場合は、Cloud Service Mesh テレメトリーがそのサービスを HTTP サービスとして認識しているかどうかを確認します。

サービスが見つからない場合は、クラスタに Kubernetes サービス構成が存在しているかどうかを確認します。

すべての Kubernetes サービスのリストを確認します。
```
kubectl get services --all-namespaces
```
特定の名前空間の Kubernetes サービスの一覧を確認します。
```
kubectl get services -n YOUR_NAMESPACE
```

サービスの指標が見つからないか間違っている

ダッシュボードにサービスの指標がないか、正しくない場合は、次のセクションにある解決策を試してください。

サイドカープロキシが存在し、インジェクションが正しく行われていることを確認する

名前空間に自動インジェクションのラベルがないか、手動インジェクションが失敗している可能性があります。名前空間の Pod に 2 つ以上のコンテナがあり、そのいずれかが istio-proxy コンテナになっていることを確認します。

kubectl -n YOUR_NAMESPACE get pods

テレメトリー構成の存在を確認する

Google Cloud Observability フィルタが構成されていることを確認するには、各プロキシから構成ダンプを収集し、Google Cloud Observability フィルタが存在するかどうかを確認します。

kubectl debug --image istio/base --target istio-proxy -it YOUR_POD_NAME -n YOUR_NAMESPACE curl localhost:15000/config_dump

前のコマンドの出力で、次のような Google Cloud Observability フィルタを探します。

"config": {
    "root_id": "stackdriver_inbound",
    "vm_config": {
        "vm_id": "stackdriver_inbound",
        "runtime": "envoy.wasm.runtime.null",
        "code": {
            "local": {
                "inline_string": "envoy.wasm.null.stackdriver"
             }
         }
     },
     "configuration": "{....}"
}

Cloud Service Mesh が HTTP サービスを識別することを確認する

Kubernetes Service のサービスポート名が http でない場合や、名前の接頭辞が http- の場合、指標はユーザーインターフェースに表示されません。サービスのポートに適切な名前が設定されていることを確認します。

プロジェクトで Cloud Monitoring API が有効になっていることを確認する

Google Cloud コンソールの [API とサービス] ダッシュボードで、Cloud Monitoring API が有効になっていることを確認します。これがデフォルトです。

Cloud Monitoring API へのエラー報告を確認する

Google Cloud コンソールの [API とサービス] ダッシュボードで、レスポンスコード別のトラフィックグラフの URL を開きます。

https://console.cloud.google.com/apis/api/monitoring.googleapis.com/metrics?folder=&organizationId=&project=YOUR_PROJECT_ID

エラーメッセージが表示される場合は、詳細な調査が必要な問題である可能性があります。特に、多数の 429 エラーメッセージが表示されたかどうかを確認してください。これは割り当てに問題がある可能性があります。トラブルシューティングの手順については、次のセクションをご覧ください。

Cloud Monitoring API の割り当てが正しいことを確認する

Google Cloud コンソールで IAM & Admin メニューを開き、[割り当て] オプションがあることを確認します。このページには、次の URL から直接アクセスできます。

https://console.cloud.google.com/iam-admin/quotas?project=YOUR_PROJECT_ID

このページには、プロジェクトの割り当てがすべて一覧表示されます。ここで Cloud Monitoring API を検索できます。

Envoy プロキシでエラーログが生成されていない確認する

目的のプロキシのログを確認し、エラーメッセージを検索します。

kubectl -n YOUR_NAMESPACE logs YOUR_POD_NAME -c istio-proxy

ただし、以下のような警告メッセージは無視してください。これは正常な状態を表します。

[warning][filter] [src/envoy/http/authn/http_filter_factory.cc:83]
mTLS PERMISSIVE mode is used, connection can be either plaintext or TLS,
and client cert can be omitted. Please consider to upgrade to mTLS STRICT mode
for more secure configuration that only allows TLS connection with client cert.
See https://istio.io/docs/tasks/security/mtls-migration/ [warning][config]
[bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91]
gRPC config stream closed: 13

`metric.mesh_uid` が正しく設定されていることを確認する

Metrics Explorer を開き、次の MQL クエリを実行します。

fetch istio_canonical_service
| metric 'istio.io/service/server/request_count'
| align delta(1m)
| every 1m
| group_by [metric.destination_canonical_service_namespace, metric.destination_canonical_service_name, metric.mesh_uid]

想定されるすべてのサービスが指標を報告していること、およびそれらの metric.mesh_uid が proj-<Cloud Service Mesh fleet project number> の形式であることを確認します。

metric.mesh_uid に他の値がある場合、Cloud Service Mesh ダッシュボードには指標は表示されません。Cloud Service Mesh がクラスタにインストールされた時点で metric.mesh_uid が設定されるため、インストール方法を調べて、想定される値にこれを設定する方法があるかどうかを確認します。

サービスのテレメトリーデータがない、または正しくない

デフォルトでは、Cloud Service Mesh をインストールすると、Google Cloud プロジェクトで Cloud Monitoring と Cloud Logging が有効になります。テレメトリーデータを報告するため、サービス Pod を呼び出す各サイドカープロキシが Cloud Monitoring API と Cloud Logging API を呼び出します。ワークロードをデプロイしてから Google Cloud コンソールにテレメトリーデータが表示されるまでに 1～2 分かかります。Cloud Service Mesh は、サービスダッシュボードを自動的に最新の状態に保ちます。

指標の場合、サイドカープロキシは約 1 分ごとに Cloud Monitoring API を呼び出します。
トポロジグラフを更新する場合は、サイドカープロキシが約 1 分ごとに増分レポートを、約 10 分ごとに完全なレポートを送信します。
ロギングの場合、サイドカープロキシは約 10 秒ごとに Cloud Logging API を呼び出します。
トレースの場合、Cloud Trace を有効にする必要があります。トレースは、構成したサンプリング頻度でレポートされます（通常は 100 リクエストごとに 1 回）。

Cloud Service Mesh 指標ページに表示されるのは、HTTP サービスの指標のみです。指標が表示されない場合は、アプリケーションのサービスの名前空間ですべての Pod にサイドカープロキシが挿入されていることを確認します。

kubectl get pod -n YOUR_NAMESPACE --all

出力の READY 列には、ワークロードごとに 2 つのコンテナ（プライマリコンテナとサイドカープロキシのコンテナ）が表示されます。

また、サービスダッシュボードに表示されるのはサーバーの指標のみであるため、メッシュにクライアントがない場合や、クライアントの指標（Ingress ゲートウェイなど）のみを報告するように構成されている場合、テレメトリーデータは表示されません。