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

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

Cloud Service Mesh ページには、Cloud Logging にある 2 種類のログ（アクセスログ（別称: Envoy ログ）、トラフィックログ（別称: Google Cloud Observability のアクセスログ）へのリンクがあります。

アクセスログ

アクセスログを有効にする

アクセスログを有効にする手順は、Cloud Service Mesh のタイプ（マネージドまたはクラスタ内）によって異なります。

管理対象

マネージド Cloud Service Mesh でアクセスログを有効にするの手順に沿って操作します。

クラスタ内

クラスタ内 Cloud Service Mesh でアクセスログを有効にするの手順に沿って操作します。

アクセスログを表示する

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

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

ログエクスプローラに移動
適切な 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"

トラフィックログ

トラフィックログを有効にする

トラフィックログは、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 でトラフィックログを有効にすることもできます。

トラフィックログを表示する

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

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

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

ログエクスプローラに移動
適切な 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"

Anthos の [サービスメッシュ] ページでトラフィックログを表示する

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"
}

Anthos 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 という名前のダッシュボードを探します。詳細については、インストールされたダッシュボードの表示をご覧ください。

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

構成の遅延を診断する

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

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

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

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

Google Cloud Observability のアクセスログを解釈する

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

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

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

Google Kubernetes Engine への Cloud Service Mesh のインストールでは、Google Cloud Observability のアクセスログがデフォルトで有効になります。Google Cloud Observability のアクセスログを有効にするには、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 などのトレース情報が含まれます。

Istio 構成でログを有効にすると、Google Cloud Observability のアクセスログの情報は Envoy アクセスログから生成されます。これには次のヘッダーが含まれています。

route_name
upstream_cluster
X-Envoy-Original-Path
X-Envoy-Original-Host

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

{
  "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 プロキシログ）を使用して、接続の両端間のトラフィックを表示する方法について説明します。

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

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

Cloud Service Mesh のデフォルトでは、アクセスログは有効になっていません。このログは、メッシュ全体でグローバルに有効にできます。

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

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

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

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

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

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

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

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

マネージド Cloud Service Mesh のプロキシロギングを構成するには、Envoy アクセスログをご覧ください。

クラスタ内コントロールプレーンを使用して 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 exec POD_NAME -n NAMESPACE_NAME -c istio-proxy -- ss -anopim
```

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

kubectl exec POD_NAME -n NAMESPACE_NAME -c istio-proxy -- 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 にトラフィックログをエクスポートする。
ログベースの指標を作成する。

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

アクセスログ

アクセスログを有効にする

管理対象

クラスタ内

アクセスログを表示する

トラフィック ログ

トラフィック ログを有効にする

トラフィック ログを表示する

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