レガシー v1.19 サービスメッシュのドキュメントを表示しています

利用可能なバージョン

Cloud Service Mesh
1.20 アーカイブ
 1.19 アーカイブ
 1.18 アーカイブ

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 の両方からデータが収集され、各サービスに特化したダッシュボードが表示されます。

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

ダッシュボードに 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

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

テレメトリーを構成するには、istio-system 名前空間で EnvoyFilters を使用します。この構成を行わないと、Cloud 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": "{....}"
}

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 ゲートウェイなど）のみを報告するように構成されている場合、テレメトリーデータは表示されません。