Anthos Service Mesh 1.6 已达到服务终止期限，不再受支持。请参阅从早期版本升级。

查看最新文档或选择其他可用版本：

可用版本

1.20（最新）
1.19
1.18
1.17
1.16
1.15
1.14
1.13
{1.18
{1.12
{1.12
{1.12
{1.12）。{/1.12
{1.13
{1.12
{1.12
{1.12
{1.12
）。{/1.12
{1.12

解读 Anthos Service Mesh 日志

以下部分介绍了如何查看网格的状态，并查看包含有用信息的各种日志，以便进行问题排查。

解读控制层面指标

使用 asm-gcp 配置文件安装 Anthos Service Mesh 时，默认情况下，Istiod 会将指标导出到 Google Cloud Observability 以进行监控。Istiod 会在这些指标前面加上 istio.io/control，有助于深入了解控制层面状态，例如连接到每个控制层面实例的代理数量、配置事件、推送和验证。

请按照以下步骤观察控制层面或排查控制层面问题。

加载示例信息中心：

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

安装 Anthos Service Mesh 信息中心：

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

在列表中查找名为 Istio Control Plane Dashboard 的信息中心。如需了解详情，请参阅查看已安装的信息中心。

如果您未使用 asm-gcp 配置文件，仍可以通过将环境变量添加到 Istiod 部署来启用控制层面指标：
```
- name: ENABLE_STACKDRIVER_MONITORING
value: "true"
```
此外，您还可以使用安装选项 components.pilot.k8s.env 添加此环境变量。

如需查看可用指标的完整列表，请参阅导出的指标。

诊断配置延迟问题

以下步骤说明了如何使用 pilot_proxy_convergence_time 指标来诊断配置更改和所有代理汇聚之间的延迟问题。

在 pod 中运行 shell 命令：

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

访问 localhost:15014，并通过 grep 命令查找指标中的 convergence：
```
curl http://localhost:15014/metrics | grep convergence
```

解读 Google Cloud 可观测性访问日志

以下信息说明了如何使用 Google Cloud Observability 访问日志来排查连接问题。

Anthos Service Mesh 将数据导出到 Google Cloud Observability 访问日志，这些日志可以帮助您调试以下类型的问题：

流量流和故障
端到端请求路由

默认情况下，Google Cloud 可观测性访问/流量日志会在整个网格的 asm-gcp 配置文件中启用。不过，如果它们尚未启用，您可以使用以下命令：

istioctl install --set profile=PROFILE_NAME --set revision==ASM_VERSION \
    --set values.telemetry.v2.stackdriver.enabled=true \
    --set values.telemetry.v2.stackdriver.logging=true

访问日志有两种类型：

服务器访问日志提供请求的服务器端视图。这些日志位于 server-accesslog-stackdriver 下，并附加到 k8s_container 受监控的资源。使用以下网址语法显示服务器端访问日志：
```
https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"&project=PROJECT_ID
```
客户端访问日志提供请求的客户端视图。这些日志位于 client-accesslog-stackdriver 下，并附加到 k8s_pod 受监控的资源。使用以下网址语法显示客户端访问日志：
```
https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/client-accesslog-stackdriver"&project=PROJECT_ID
```
.

默认情况下，系统仅启用客户端错误日志以减少日志记录费用，但您可以使用以下命令启用所有客户端日志（成功和错误）：

istioctl install --set profile=PROFILE_NAME --set revision==ASM_VERSION 

    --set values.telemetry.v2.stackdriver.enabled=true 

    --set values.telemetry.v2.stackdriver.outboundAccessLogging=FULL

访问日志包含以下信息：

HTTP 请求属性，例如 ID、网址、大小、延迟时间和常见标头。
源和目标工作负载信息，例如名称、命名空间、身份和常见标签。
源和目标规范服务和修订版本信息。
如果启用了跟踪，则日志将包含采样、跟踪 ID 和 Span 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 Trace 集成，这是 Anthos Service Mesh 中的可选功能。
将流量日志导出到 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 访问日志对于诊断以下问题非常有用：

流量流和故障
端到端请求路由

默认情况下，Anthos Service Mesh 中未启用访问日志，您只能在整个网格中全局启用访问日志。

您可以通过以下方法排查连接/请求失败问题：在您的应用中生成触发 HTTP 请求的活动，然后在来源日志或目标日志中检查关联的请求。

如果您触发请求，并且该请求出现在来源代理日志中，则说明 iptables 流量重定向正常并且 Envoy 代理正在处理流量。如果您在日志中看到错误，请生成 Envoy 配置转储文件，并检查 Envoy 集群配置以确保其正确无误。如果您看到请求，但日志没有错误，请改为检查目标代理日志。

如果请求出现在目标代理日志中，则说明网格本身工作正常。相反，如果您看到错误，请运行 Envoy 配置转储文件，并验证监听器配置中设置的流量端口的正确值。

如果在执行上述步骤后问题仍然存在，则说明 Envoy 可能无法自动协商 Sidecar 与其应用 Pod 之间的协议。请确保 Kubernetes 服务端口名称（例如 http-80）与应用使用的协议匹配。

使用日志浏览器查询日志

您可以使用日志浏览器界面来查询特定的访问日志。例如，如需查询所有启用了 MULTUAL_TLS 并使用协议 grpc 的请求，请将以下代码附加到服务器访问日志查询：

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

设置访问日志政策

您可以设置代理日志记录政策，用于确定您收集的信息类型。这有助于控制日志的范围以排查问题。例如，日志记录功能会自动捕获错误，但您可以将 logWindowDuration 设置为额外捕获特定时段的成功事件，也可以将时段设置为 0 以记录所有访问。政策是在网格或集群级层设置的。

如需启用访问日志政策，请使用以下命令：

istioctl install --set profile=PROFILE_NAME \
    --set values.telemetry.v2.stackdriver.enabled=true \
    --set values.telemetry.v2.stackdriver.logging=true \
    --set values.telemetry.accessLogPolicy.enabled=true

如需详细了解访问日志配置选项（例如 logWindowDuration），请参阅 AccessLogPolicy 配置。

查看特定于服务或工作负载的信息

如果您遇到特定服务或工作负载的问题，而不是网格相关的问题，请检查各个 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