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

Cloud Service Mesh は、Cloud Logging で 2 種類のアクセスログをサポートしています。トラフィック ログ(Google Cloud オブザーバビリティ アクセスログ)と 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 アクセス ロギングを有効にします。

  1. 次のコマンドを実行して 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-managedasm-managed-stable または asm-managed-rapid)です。

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

     kubectl get configmap istio-release-channel -n istio-system -o yaml
    
  3. アクセス ロギングが有効になっていることを確認するには、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

ログ エクスプローラ

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

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

    ログ エクスプローラに移動

  2. 適切な Google Cloud プロジェクトを選択します。

  3. 次のクエリを実行します。

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"

トラフィック ログ

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

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

    ログ エクスプローラに移動

  2. 適切な Google Cloud プロジェクトを選択します。

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

    サーバーログ

    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 のトラフィック ログを表示するには、次の操作を行います。

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

    [Cloud Service Mesh] ページに移動

  2. [サービス] で、検査するサービスの名前を選択します。

  3. [指標] ページに移動します。

  4. [期間] プルダウン メニューから期間を指定するか、タイムラインを使用してカスタムスパンを設定します。

  5. [ フィルタ オプションを選択] で、[トラフィック ログを表示] をクリックします。

トラフィック ログの名前は 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、検証など、コントロール プレーンの状態の分析情報を提供します。

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

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

    git clone https://github.com/GoogleCloudPlatform/monitoring-dashboard-samples && cd monitoring-dashboard-samples/dashboards && git checkout servicemesh
  2. Cloud Service Mesh ダッシュボードをインストールします。

    gcloud monitoring dashboards create --config-from-file=dashboards/servicemesh/anthos-service-mesh-control-plane-monitoring.json
  3. リストで、Istio Control Plane Dashboard という名前のダッシュボードを探します。詳細については、インストールされたダッシュボードの表示をご覧ください。

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

構成の遅延を診断する

マネージド Cloud Service Mesh

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

マネージド istiod

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

クラスタ内

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

  1. 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
  2. 指標の convergencelocalhost:15014grep にアクセスします。

    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 のレスポンス コードでリクエストが失敗した場合のトラブルシューティングを行う方法を示しています。

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

    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"
    }
  2. アクセス ログエントリ内のラベルに移動します。次のような response_flag フィールドを探します。

    response_flag: "NR"

    NR 値は NoRoute の頭字語です。これは、宛先のルートが見つからなかったか、ダウンストリーム接続に一致するフィルタ チェーンがなかったことを意味します。同様に、response_flag ラベルを使用して 503 エラーのトラブルシューティングを行うこともできます。

  3. クライアント ログとサーバー アクセスログの両方に 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 のアクセスログ ポリシーを設定するには:

  1. シナリオに適した AccessLogPolicyConfig 値を含む IstioOperator カスタム オーバーレイ ファイルを作成します。

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

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

メッシュ全体ではなく、特定のサービスやワークロードに問題がある場合は、個々の 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 プロキシ ソケットの状態を直接調べることが可能です。

  1. 確立されたソケットのリストを表示します(TIME_WAIT 状態のソケットを含む)。数が多いと、スケーラビリティに悪影響を与える可能性があります。

    kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -anopim
  2. ソケットの統計情報の概要を表示します。

    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

次のステップ