v1.21 Service Mesh のドキュメントを表示しています。

利用可能なバージョン

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

プロキシログをリクエストする

Cloud Service Mesh は、Cloud Logging で 2 つの異なるタイプのアクセスログをサポートしています。トラフィックログ（別称: Google Cloud Observability アクセスログ）と Envoy アクセスログです。このページでは、これらのログを有効化、無効化、表示、解釈する方法について説明します。トラフィックログはデフォルトで有効になっています。

アクセスログの有効化と無効化

マネージド Cloud Service Mesh

Envoy アクセスログ

次のコマンドを実行して、Envoy アクセスログを有効にし、トラフィックログを無効にします。

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: enable-envoy-disable-sd
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
  - providers:
      - name: stackdriver
    disabled: true
EOF

トラフィックログのプロバイダ名は stackdriver です。

トラフィックログ

デフォルトでは、トラフィックログは有効で、Envoy アクセスログは無効になっています。以前に Envoy アクセスログを有効にしていて、トラフィックログを有効にして Envoy アクセスログを無効にする場合は、次のコマンドを実行します。

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: disable-envoy-enable-sd
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
    disabled: true
  - providers:
      - name: stackdriver
EOF

両方

Envoy アクセスログとトラフィックログの両方を有効にするには、次のコマンドを実行します。

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: enable-envoy-and-sd-access-log
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
      - name: stackdriver
EOF

Envoy アクセスログとトラフィックログの両方を無効にするには、次のコマンドを実行します。

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: disable-envoy-and-sd
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
    disabled: true
  - providers:
      - name: stackdriver
    disabled: true
EOF

マネージド　`istiod`

Envoy アクセスログ

次のコマンドを実行して、Envoy アクセスロギングを有効にします。

次のコマンドを実行して accessLogFile: /dev/stdout を追加します。

cat <<EOF | kubectl apply -f -
apiVersion: v1
data:
  mesh: |-
    accessLogFile: /dev/stdout
kind: ConfigMap
metadata:
  name: istio-release-channel
  namespace: istio-system
EOF

release-channel は、リリースチャンネル（asm-managed、asm-managed-stable または asm-managed-rapid）です。

次のコマンドを実行して ConfigMap を表示します。

 kubectl get configmap istio-release-channel -n istio-system -o yaml

アクセスロギングが有効になっていることを確認するには、accessLogFile: /dev/stdout 行が mesh: セクションに表示されていることを確認します。
```
...
apiVersion: v1
data:
  mesh: |
    ....
    accessLogFile: /dev/stdout
...
```

トラフィックログ

トラフィックログはデフォルトで有効になっています。

クラスタ内

Envoy アクセスログ

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: "/dev/stdout"

詳細については、Envoy のアクセスロギングを有効にするをご覧ください。

トラフィックログ

トラフィックログは、Cloud Service Mesh が Istio CA（旧称 Citadel）を使用する Google Distributed Cloud にインストールされている場合を除き、デフォルトで有効になっています。

クラスタ内 Cloud Service Mesh をインストールするときに、Istio CA を使用する Google Distributed Cloud Virtual でトラフィックログを有効にするには、--option stackdriver フラグを使用します。また、クラスタ内 Cloud Service Mesh をインストールした後に、Istio CA を使用する Google Distributed Cloud Virtual でトラフィックログを有効にすることもできます。

アクセスログの表示

Envoy アクセスログ

コマンドライン

istio-proxy ログで Envoy アクセスログを表示するには、次のコマンドを実行します。

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy

ログエクスプローラ

ログエクスプローラでアクセスログを表示するには:

ログエクスプローラに移動します。

ログエクスプローラに移動
適切な Google Cloud プロジェクトを選択します。
次のクエリを実行します。

resource.type="k8s_container" \
resource.labels.container_name="istio-proxy"
resource.labels.cluster_name="CLUSTER_NAME" \
resource.labels.namespace_name="NAMESPACE_NAME" \
resource.labels.pod_name="POD_NAME"

トラフィックログ

ログエクスプローラでトラフィックログを表示するには:

ログエクスプローラに移動します。

ログエクスプローラに移動
適切な Google Cloud プロジェクトを選択します。

クライアントのアクセスログを表示するのか、サーバーのアクセスログを表示するのかに応じて、次のクエリを実行します。

サーバーログ

resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/server-accesslog-stackdriver"

クライアントログ

resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/client-accesslog-stackdriver"

Cloud Service Mesh ページで、指定した期間の Service のトラフィックログを表示するには、次の操作を行います。

Google Cloud コンソールの [Cloud Service Mesh] ページに移動します。

[Cloud Service Mesh] ページに移動
[サービス] で、検査するサービスの名前を選択します。
[指標] ページに移動します。
[期間] プルダウンメニューから期間を指定するか、タイムラインを使用してカスタムスパンを設定します。
[ フィルタオプションを選択] で、[トラフィックログを表示] をクリックします。

トラフィックログの名前は server-accesslog-stackdriver で、サービスが使用している対応するモニタリング対象リソース（k8s_container または gce_instance）に関連付けられます。トラフィックログには次の情報が記録されます。

ID、URL、サイズ、レイテンシ、共通ヘッダーなどの HTTP リクエストプロパティ。
ソースと宛先のワークロードの情報（名前、名前空間、ID、共通ラベルなど）。
トレースが有効な場合は、トレース情報（サンプリング、トレース ID、スパン ID など）。

ログエントリは次のようになります。

{
  insertId: "1awb4hug5pos2qi"
  httpRequest: {
    requestMethod: "GET"
    requestUrl: "YOUR-INGRESS/productpage"
    requestSize: "952"
    status: 200
    responseSize: "5875"
    remoteIp: "10.8.0.44:0"
    serverIp: "10.56.4.25:9080"
    latency: "1.587232023s"
    protocol: "http"
  }
  resource: {
    type: "k8s_container"
    labels: {
      location: "us-central1-a"
      project_id: "YOUR-PROJECT"
      pod_name: "productpage-v1-76589d9fdc-ptnt9"
      cluster_name: "YOUR-CLUSTER-NAME"
      container_name: "productpage"
      namespace_name: "default"
    }
  }
  timestamp: "2020-04-28T19:55:21.056759Z"
  severity: "INFO"
  labels: {
    destination_principal: "spiffe://cluster.local/ns/default/sa/bookinfo-productpage"
    response_flag: "-"
    destination_service_host: "productpage.default.svc.cluster.local"
    source_app: "istio-ingressgateway"
    service_authentication_policy: "MUTUAL_TLS"
    source_name: "istio-ingressgateway-5ff85d8dd8-mwplb"
    mesh_uid: "YOUR-MESH-UID"
    request_id: "021ce752-9001-4ac6-b6d6-3b15f5d3632"
    destination_namespace: "default"
    source_principal:  "spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"
    destination_workload: "productpage-v1"
    destination_version: "v1"
    source_namespace: "istio-system"
    source_workload: "istio-ingressgateway"
    destination_name: "productpage-v1-76589d9fdc-ptnt9"
    destination_app: "productpage"
  }
  trace: "projects/YOUR-PROJECT/traces/d4197f59b7a43e3aeff3571bac99d536"
  receiveTimestamp: "2020-04-29T03:07:14.362416217Z"
  spanId: "43226343ca2bb2b1"
  traceSampled: true
  logName: "projects/YOUR-PROJECT/logs/server-accesslog-stackdriver"
  receiveTimestamp: "2020-04-28T19:55:32.185229100Z"
}

Cloud Service Mesh テレメトリーを解釈する

以下のセクションでは、メッシュのステータスを確認する方法と、トラブルシューティングに役立つ情報を含むさまざまなテレメトリーを確認する方法について説明します。

コントロールプレーンの指標を解釈する

マネージド Cloud Service Mesh

マネージド Cloud Service Mesh コントロールプレーンを使用する Cloud Service Mesh は、コントロールプレーンの指標をサポートしていません。

マネージド　`istiod`

マネージド istiod コントロールプレーンを使用する Cloud Service Mesh は、このセクションのコントロールプレーンの指標検査をサポートしていません。

クラスタ内

クラスタ内コントロールプレーンを使用して Cloud Service Mesh をインストールしている場合、デフォルトでは、istiod はモニタリング用の指標を Google Cloud Observability にエクスポートします。istiod では、これらの指標に istio.io/control という接頭辞が付いており、各コントロールプレーンインスタンスに接続しているプロキシ数、構成イベント、push、検証など、コントロールプレーンの状態の分析情報を提供します。

次の手順でコントロールプレーンを監視またはトラブルシューティングします。

サンプルダッシュボードを読み込みます。

git clone https://github.com/GoogleCloudPlatform/monitoring-dashboard-samples && cd monitoring-dashboard-samples/dashboards && git checkout servicemesh

Cloud Service Mesh ダッシュボードをインストールします。

gcloud monitoring dashboards create --config-from-file=dashboards/servicemesh/anthos-service-mesh-control-plane-monitoring.json

リストで、Istio Control Plane Dashboard という名前のダッシュボードを探します。詳細については、インストールされたダッシュボードの表示をご覧ください。

利用可能な指標の一覧については、エクスポートされた指標をご覧ください。

構成の遅延を診断する

マネージド Cloud Service Mesh

マネージド Cloud Service Mesh コントロールプレーンを使用する Cloud Service Mesh は、構成の遅延の診断をサポートしていません。

マネージド　`istiod`

マネージド istiod コントロールプレーンを使用する Cloud Service Mesh は、構成の遅延の診断をサポートしていません。

クラスタ内

次の手順では、pilot_proxy_convergence_time 指標を使用して、構成の変更とすべてのプロキシ収束の遅延を診断する方法について説明します。

Pod でシェルコマンドを実行します。

kubectl debug --image istio/base --target istio-proxy -it $(kubectl get pod -l app=pilot -o jsonpath='{.items[0].metadata.name}' -n istio-system) -n istio-system -- curl -s

指標の convergence の localhost:15014 と grep にアクセスします。
```
curl http://localhost:15014/metrics | grep convergence
```

トラフィックログを解釈する

ここでは、トラフィックログを使用して接続の問題を解決する方法について説明します。トラフィックログはデフォルトで有効になっています。

Cloud Service Mesh は、トラフィックログにデータをエクスポートします。この情報は、次のような問題のデバッグに役立ちます。

トラフィックフローと障害
エンドツーエンドのリクエストルーティング

Google Kubernetes Engine への Cloud Service Mesh のインストールでは、トラフィックログがデフォルトで有効になります。トラフィックログを有効にするには、asmcli install を再実行します。最初にインストールしたオプションを使用しますが、Stackdriver を無効にするカスタムオーバーレイは省略します。

トラフィックログには次の 2 種類があります。

サーバーアクセスログでは、サーバーサイドのリクエストを確認できます。これらは server-accesslog-stackdriver の下にあり、k8s_container モニタリング対象リソースに接続されます。サーバーサイドのアクセスログを表示するには、次の URL 構文を使用します。
```
https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"&project=PROJECT_ID
```
クライアントアクセスログは、クライアントサイドのリクエストを表示します。これらは client-accesslog-stackdriver の下にあり、k8s_pod モニタリング対象リソースに接続されます。クライアント側のアクセスログを表示するには、次の URL 構文を使用します。
```
https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/client-accesslog-stackdriver"&project=PROJECT_ID
```

アクセスログには次の情報が含まれます。

ID、URL、サイズ、レイテンシ、共通ヘッダーなどの HTTP リクエストプロパティ。
ソースと宛先のワークロードの情報（名前、名前空間、ID、共通ラベルなど）。
送信元と宛先の正規サービスとリビジョン情報。
トレースが有効になっている場合、ログにはサンプリング、トレース ID、スパン ID などのトレース情報が含まれます。

トラフィックログには、次のラベルが含まれる場合があります。

route_name
upstream_cluster
X-Envoy-Original-Path

これはログエントリの例です。

{
  "insertId": "1j84zg8g68vb62z",
  "httpRequest": {
    "requestMethod": "GET",
    "requestUrl": "http://35.235.89.201:80/productpage",
    "requestSize": "795",
    "status": 200,
    "responseSize": "7005",
    "remoteIp": "10.168.0.26:0",
    "serverIp": "10.36.3.153:9080",
    "latency": "0.229384205s",
    "protocol": "http"
  },
  "resource": {
    "type": "k8s_container",
    "labels": {
      "cluster_name": "istio-e2e22",
      "namespace_name": "istio-bookinfo-1-68819",
      "container_name": "productpage",
      "project_id": "***",
      "location": "us-west2-a",
      "pod_name": "productpage-v1-64794f5db4-8xbtf"
    }
  },
  "timestamp": "2020-08-13T21:37:42.963881Z",
  "severity": "INFO",
  "labels": {
    "protocol": "http",
    "upstream_host": "127.0.0.1:9080",
    "source_canonical_service": "istio-ingressgateway",
    "source_namespace": "istio-system",
    "x-envoy-original-path": "",
    "source_canonical_revision": "latest",
    "connection_id": "32",
    "upstream_cluster": "inbound|9080|http|productpage.istio-bookinfo-1-68819.svc.cluster.local",
    "requested_server_name": "outbound_.9080_._.productpage.istio-bookinfo-1-68819.svc.cluster.local",
    "destination_version": "v1",
    "destination_workload": "productpage-v1",
    "source_workload": "istio-ingressgateway",
    "destination_canonical_revision": "v1",
    "mesh_uid": "cluster.local",
    "source_principal": "spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account",
    "x-envoy-original-dst-host": "",
    "service_authentication_policy": "MUTUAL_TLS",
    "destination_principal": "spiffe://cluster.local/ns/istio-bookinfo-1-68819/sa/bookinfo-productpage",
    "response_flag": "-",
    "log_sampled": "false",
    "destination_service_host": "productpage.istio-bookinfo-1-68819.svc.cluster.local",
    "destination_name": "productpage-v1-64794f5db4-8xbtf",
    "destination_canonical_service": "productpage",
    "destination_namespace": "istio-bookinfo-1-68819",
    "source_name": "istio-ingressgateway-6845f6d664-lnfvp",
    "source_app": "istio-ingressgateway",
    "destination_app": "productpage",
    "request_id": "39013650-4e62-9be2-9d25-78682dd27ea4",
    "route_name": "default"
  },
  "logName": "projects/***/logs/server-accesslog-stackdriver",
  "trace": "projects/***t/traces/466d77d15753cb4d7749ba5413b5f70f",
  "receiveTimestamp": "2020-08-13T21:37:48.758673203Z",
  "spanId": "633831cb1fda4fd5",
  "traceSampled": true
}

このログはさまざまな方法で使用できます。

Cloud Service Mesh のオプションの機能である Cloud Trace と統合する。
トラフィックログを BigQuery にエクスポートする。すべてのリクエストを選択すると 5 秒以上かかるようなクエリを実行できます。
ログベースの指標を作成する。
404 エラーと 503 エラーのトラブルシューティング

`404` エラーと `503` エラーのトラブルシューティング

次の例は、このレスポンスを使用して、404 または 503 のレスポンスコードでリクエストが失敗した場合のトラブルシューティングを行う方法を示しています。

クライアントアクセスログで、次のようなエントリを検索します。

httpRequest: {
requestMethod: "GET"
requestUrl: "://IP_ADDRESS/src/Util/PHP/eval-stdin.php"
requestSize: "2088"
status: 404
responseSize: "75"
remoteIp: "10.168.0.26:34165"
serverIp: "10.36.3.149:8080"
latency: "0.000371440s"
protocol: "http"
}

アクセスログエントリ内のラベルに移動します。次のような response_flag フィールドを探します。
```
response_flag: "NR"
```
NR 値は NoRoute の頭字語です。これは、宛先のルートが見つからなかったか、ダウンストリーム接続に一致するフィルタチェーンがなかったことを意味します。同様に、response_flag ラベルを使用して 503 エラーのトラブルシューティングを行うこともできます。
クライアントログとサーバーアクセスログの両方に 503 エラーが表示された場合は、各サービスに設定されたポート名が、サービス間で使用されているプロトコルの名前と一致していることを確認してください。たとえば、Golang バイナリクライアントが HTTP を使用して golang サーバーに接続されているが、ポート名は http2 の場合、プロトコルは自動的にネゴシエートされません。

詳細については、レスポンスフラグをご覧ください。

Envoy アクセスログを解釈する

以下の手順では、Envoy アクセスログを使用して、接続の両側でトラフィックを確認する方法を説明します。

Envoy アクセスログは、次のような問題の診断に役立ちます。

トラフィックフローと障害
エンドツーエンドのリクエストルーティング

Cloud Service Mesh のデフォルトでは、Envoy アクセスログは有効になっていません。メッシュ内のクラスタで有効にできます。

HTTP リクエストをトリガーするアクティビティをアプリケーション内で生成し、関連するログをソースログまたは宛先ログで調査することで、接続 / リクエストのエラーをトラブルシューティングできます。

トリガーされたリクエストがソースプロキシログに表示されている場合は、iptables トラフィックのリダイレクトが正常に動作しており、Envoy プロキシがトラフィックを処理していることを示します。ログにエラーが表示されたら、Envoy 構成ダンプを生成し、Envoy クラスタの構成が正しいことを確認してください。リクエストが表示されてログにエラーがない場合は、代わりに宛先プロキシのログを確認してください。

リクエストが宛先プロキシログに表示されている場合は、メッシュ自体が正常に動作していることを示しています。代わりにエラーが表示された場合は、Envoy 構成ダンプを実行し、リスナー構成で設定されているトラフィックポートの正しい値を確認します。

上述の手順で問題が解決しない場合は、Envoy がサイドカーとそのアプリケーション Pod 間でプロトコルを自動的にネゴシエートできない可能性があります。Kubernetes Service のポート名（http-80 など）がアプリケーションで使用するプロトコルと一致していることを確認します。

ログエクスプローラを使用してログをクエリする

ログエクスプローラインターフェースを使用して、特定の　Envoy　アクセスログを照会できます。たとえば、MULTUAL_TLS が有効で、grpc プロトコルを使用するすべてのリクエストをクエリで取得するには、サーバーアクセスログのクエリの末尾に以下を追加します。

labels.protocol="grpc" labels.service_authentication_policy="MULTUAL_TLS"

アクセスログポリシーを設定する

マネージド Cloud Service Mesh

マネージド Cloud Service Mesh コントロールプレーンを使用しする Cloud Service Mesh のアクセスログを構成するには、アクセスログの有効化をご覧ください。

マネージド　`istiod`

マネージド istiod コントロールプレーンを使用して Cloud Service Mesh のアクセスログを構成するには、アクセスログの有効化をご覧ください。

クラスタ内

クラスタ内コントロールプレーンを使用して Cloud Service Mesh のアクセスログポリシーを設定するには:

シナリオに適した AccessLogPolicyConfig 値を含む IstioOperator カスタムオーバーレイファイルを作成します。
クラスタ内コントロールプレーンの構成を更新するには、--custom_overlay オプションを使用して、このファイルを asmcli に渡します。カスタムオーバーレイファイルを使用して asmcli install を実行する方法については、オプション機能を使用してインストールするをご覧ください。

注意: 以前のインストールをカスタマイズした場合は、コントロールプレーンを再インストールして AccessLogPolicyConfig 設定を持つファイルを含める場合にも同じカスタマイズが必要になります。オーバーレイファイルを省略すると、インストールは成功しますが、省略された値はコントロールプレーンが再デプロイされるとデフォルトにリセットされるため、サービスメッシュの構成は意図したものとは異なります。

サービスまたはワークロード固有の情報を表示する

メッシュ全体ではなく、特定のサービスやワークロードに問題がある場合は、個々の Envoy プロキシを調査し、関連する情報を収集します。特定のワークロードとそのプロキシに関する情報を収集するには、pilot-agent を使用します。

kubectl exec POD_NAME -n NAMESPACE_NAME -c istio-proxy -- pilot-agent request GET SCOPE

この例では、SCOPE は次のいずれかです。

certs - Envoy インスタンス内の証明書
clusters - Envoy が構成されているクラスタ
config_dump - Envoy 構成をダンプする
listeners - Envoy が構成されているリスナー
logging - ロギング設定を表示して変更する
stats - Envoy 統計情報
stats/prometheus - Prometheus レコードとしての Envoy 統計情報

プロキシソケットの状態を表示する

次のプロセスを使用すると、Envoy プロキシソケットの状態を直接調べることが可能です。

確立されたソケットのリストを表示します（TIME_WAIT 状態のソケットを含む）。数が多いと、スケーラビリティに悪影響を与える可能性があります。
```
kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -anopim
```

ソケットの統計情報の概要を表示します。

kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -s

詳細については、ss コマンドの概要をご覧ください。

`istio-proxy` ログと `istio-init` ログ

また、istio-proxy ログを取得し、その内容を確認して、問題の原因を示しているエラーがないか確認します。

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy

init コンテナについても同じことができます。

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-init

次のステップ

Cloud Trace と統合する。Cloud Trace は、Cloud Service Mesh のオプション機能です。
BigQuery にトラフィックログをエクスポートする。
ログベースの指標を作成する。

プロキシログをリクエストする

アクセスログの有効化と無効化

マネージド Cloud Service Mesh

Envoy アクセスログ

トラフィック ログ

両方

マネージド istiod

Envoy アクセスログ

トラフィック ログ

クラスタ内

Envoy アクセスログ

トラフィック ログ

アクセスログの表示

Envoy アクセスログ

コマンドライン

ログ エクスプローラ

トラフィック ログ

サーバーログ

クライアント ログ

Cloud Service Mesh テレメトリーを解釈する

コントロール プレーンの指標を解釈する

マネージド Cloud Service Mesh

マネージド istiod

クラスタ内

構成の遅延を診断する

マネージド Cloud Service Mesh

マネージド istiod

クラスタ内

トラフィック ログを解釈する

404 エラーと 503 エラーのトラブルシューティング

Envoy アクセスログを解釈する

ログ エクスプローラを使用してログをクエリする

アクセスログ ポリシーを設定する

マネージド Cloud Service Mesh

マネージド istiod

クラスタ内

サービスまたはワークロード固有の情報を表示する

プロキシ ソケットの状態を表示する

istio-proxy ログと istio-init ログ

次のステップ

トラフィックログ

マネージド　`istiod`

トラフィックログ

トラフィックログ

ログエクスプローラ

トラフィックログ

クライアントログ

コントロールプレーンの指標を解釈する

マネージド　`istiod`

マネージド　`istiod`

トラフィックログを解釈する

`404` エラーと `503` エラーのトラブルシューティング

ログエクスプローラを使用してログをクエリする

アクセスログポリシーを設定する

マネージド　`istiod`

プロキシソケットの状態を表示する

`istio-proxy` ログと `istio-init` ログ