このセクションでは、Anthos Service Mesh の一般的な問題とその解決方法について説明します。さらにサポートが必要な場合は、サポートの利用をご覧ください。
Anthos Service Mesh テレメトリーでは、Envoy プロキシが Google Cloud Observability API を定期的に呼び出し、テレメトリー データを報告します。API 呼び出しのタイプによって頻度が決まります。
- ロギング: 約 10 秒ごと
- 指標: 約 1 分ごと
- Edge（Context API / トポロジビュー）: 約 1 分ごとに差分レポートを生成し、完全なレポートは約 10 分ごとになります。
- トレース: 構成したサンプリング頻度で決定（通常は 100 リクエストごとに 1 回）
テレメトリー ダッシュボードでは、Confluence と Google Cloud Observability の両方からデータが収集され、各サービスに特化したダッシュボードが表示されます。
サービス ダッシュボードにサービスが表示されない
ダッシュボードに HTTP(S) / gRPC サービスのみが表示されます。リストに目的のサービスが表示されていない場合は、Anthos Service Mesh テレメトリーがそのサービスを HTTP サービスとして認識しているかどうかを確認します。
サービスが見つからない場合は、クラスタに Kubernetes サービス構成 {: class="external"} が存在しているかどうかを確認します。
すべての Kubernetes サービスのリストを確認します。
kubectl get services --all-namespaces
特定の名前空間の Kubernetes サービスの一覧を確認します。
kubectl get services -n YOUR_NAMESPACE
サービスの指標が見つからない、または正しくない
ダッシュボードにサービスの指標がないか、正しくない場合は、次のセクションにある解決策を試してください。
サイドカー プロキシが存在し、インジェクションが正しく行われていることを確認します。
名前空間に自動インジェクションのラベルがないか、手動インジェクションが失敗している可能性があります。名前空間の Pod に 2 つ以上のコンテナがあり、そのいずれかが istio-proxy コンテナになっていることを確認します。
kubectl -n YOUR_NAMESPACE get pods
テレメトリー構成の存在を確認する
テレメトリーを構成するには、istio-system 名前空間で EnvoyFilters を使用します。この構成を行わないと、Anthos Service Mesh は Google Cloud Observability にデータを報告しません。
Google Cloud Observability 構成（とメタデータ交換構成）が存在することを確認します。
kubectl -n istio-system get envoyfilter
想定される出力は次のようになります。
NAME AGE metadata-exchange-1.4 13d metadata-exchange-1.5 13d stackdriver-filter-1.4 13d stackdriver-filter-1.5 13d ...
Google Cloud Observability フィルタが適切に構成されていることを確認するには、各プロキシから構成ダンプを収集し、Google Cloud Observability フィルタが存在するかどうかを確認します。
kubectl exec YOUR_POD_NAME -n YOUR_NAMESPACE -c istio-proxy 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": "{....}"
}Anthos Service Mesh が HTTP サービスを識別することを確認する
Kubernetes Service のサービスポート名に http 接頭辞が付いていない場合、指標はユーザー インターフェースに表示されません。サービスのポートに適切な名前が設定されていることを確認します。
プロジェクトで Cloud Monitoring API が有効になっていることを確認する
Google Cloud コンソールの [API とサービス] ダッシュボードで、Cloud Monitoring API が有効になっていることを確認します。これがデフォルトです。
Cloud Monitoring API へのエラー報告を確認する
Google Cloud コンソールの [API とサービス] ダッシュボードで、[レスポンス コード別のトラフィック] グラフを開きます。
エラー メッセージが表示される場合は、詳細な調査が必要な問題である可能性があります。特に、多数の 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
サービスのテレメトリー データがない、または正しくない
デフォルトでは、Anthos Service Mesh をインストールすると、Google Cloud プロジェクトで Cloud Monitoring と Cloud Logging が有効になります。テレメトリー データを報告するため、サービス Pod を呼び出す各サイドカー プロキシが Cloud Monitoring API と Cloud Logging API を呼び出します。ワークロードをデプロイしてから Google Cloud コンソールにテレメトリー データが表示されるまでに 1～2 分かかります。Anthos Service Mesh は、サービス ダッシュボードを自動的に最新の状態に保ちます。
- 指標の場合、サイドカー プロキシは約 1 分ごとに Cloud Monitoring API を呼び出します。
- トポロジグラフを更新する場合は、サイドカー プロキシが約 1 分ごとに増分レポートを、約 10 分ごとに完全なレポートを送信します。
- ロギングの場合、サイドカー プロキシは約 10 秒ごとに Cloud Logging API を呼び出します。
- トレースの場合、Cloud Trace を有効にする必要があります。トレースは、構成したサンプリング頻度でレポートされます（通常は 100 リクエストごとに 1 回）。
Anthos Service Mesh 指標ページに表示されるのは、HTTP サービスの指標のみです。指標が表示されない場合は、アプリケーションのサービスの名前空間ですべての Pod にサイドカー プロキシが挿入されていることを確認します。
kubectl get pod -n YOUR_NAMESPACE --all
出力の READY 列には、ワークロードごとに 2 つのコンテナ（プライマリ コンテナとサイドカー プロキシのコンテナ）が表示されます。