プロキシログをリクエストする
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 アクセス ロギングを有効にします。
次のコマンドを実行して
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 アクセスログ
詳細については、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] ページに移動します。
[サービス] で、検査するサービスの名前を選択します。
[指標] ページに移動します。
[期間] プルダウン メニューから期間を指定するか、タイムラインを使用してカスタムスパンを設定します。
[filter_list フィルタ オプションを選択] で、[トラフィック ログを表示] をクリックします。
トラフィック ログの名前は 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
を実行する方法については、オプション機能を使用してインストールするをご覧ください。
サービスまたはワークロード固有の情報を表示する
メッシュ全体ではなく、特定のサービスやワークロードに問題がある場合は、個々の 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 のオプション機能です。