プロキシログをリクエストする
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] ページに移動します。
[サービス] で、検査するサービスの名前を選択します。
[指標] ページに移動します。
[期間] プルダウン メニューから期間を指定するか、タイムラインを使用してカスタムスパンを設定します。
[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"
}
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 のオペレーション スイートのアクセスログを解釈する
ここでは、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_nameupstream_clusterX-Envoy-Original-PathX-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を実行する方法については、オプション機能を使用してインストールするをご覧ください。
サービスまたはワークロード固有の情報を表示する
メッシュ全体ではなく、特定のサービスやワークロードに問題がある場合は、個々の Envoy プロキシを調査し、関連する情報を収集します。特定のワークロードとそのプロキシに関する情報を収集するには、pilot-agent を使用します。
kubectl exec POD_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 -c istio-proxy -- ss -anopim
ソケットの統計情報の概要を表示します。
kubectl exec POD_NAME -c istio-proxy -- ss -s
詳細については、ss コマンドの概要をご覧ください。
istio-proxy ログと istio-init ログ
また、istio-proxy ログを取得し、その内容を確認して、問題の原因を示しているエラーがないか確認します。
kubectl logs POD_NAME -c istio-proxy
init コンテナについても同じことができます。
kubectl logs POD_NAME -c istio-init
次のステップ
Cloud Trace と統合する。Cloud Trace は、Cloud Service Mesh のオプション機能です。