收集 Anthos Service Mesh 日志

以下几个部分介绍如何收集各种 Anthos Service Mesh 日志以排查问题或联系 Google 支持团队

使用 Bug 报告工具收集日志

Anthos Service Mesh 提供了一种自动化的 Bug 报告工具,用于收集相关诊断日志并允许您将日志附加到 Google 支持服务工单。

在开始之前,请确保您的 kubeconfig 上下文已设置为目标集群。

  1. 使用以下命令验证您的上下文:

    kubectl config current-context
  2. 下载和使用 Bug 报告工具的过程取决于您使用的 Anthos Service Mesh 版本。请参阅下表,确定您当前的 istioctl 版本是否合适或者您是否必须下载该工具的独立版本。

Anthos Service Mesh/Istio 版本 Bug 报告工具
Anthos Service Mesh 1.7.* 及更高版本 istioctl bug-report
Anthos Service Mesh 1.6.* 独立版本
Anthos Service Mesh 1.5.* 独立版本
Istio 1.7.* 独立版本
Istio 1.6.* 独立版本
Istio 1.5.* 独立版本

如需下载 Bug 报告工具的独立版本,请按以下步骤操作:

  1. 从列表中选择与您的操作系统环境匹配的发行版:

    • https://storage.googleapis.com/gke-release/asm/bug-report_darwin_amd64-v2
    • https://storage.googleapis.com/gke-release/asm/bug-report_linux_386-v2
    • https://storage.googleapis.com/gke-release/asm/bug-report_linux_amd64-v2
    • https://storage.googleapis.com/gke-release/asm/bug-report_linux_arm-v2
  2. 使用 curl 下载选定的发行版,例如:

    curl -LO https://storage.googleapis.com/gke-release/asm/bug-report_darwin_amd64-v1
  3. 设置 Bug 报告工具二进制文件的权限以允许其运行,例如:

    chmod +x bug-report_darwin_amd64-v1

开始收集日志

如需开始收集日志,请运行 bug-report 工具并传递配置文件作为参数。如果需要,您可以使用额外的运行时选项覆盖配置(您可以使用 --help 选项查看该配置)。

如果您的 Anthos Service Mesh 版本已经在 istioctl 中包含了 bug-report 工具,请使用以下命令:

istioctl bug-report

如果您需要使用独立的 Bug 报告工具,请重命名该工具,并按以下命令(这些命令使用 Darwin 发行版作为示例)所示运行该工具:

mv ./bug-report_darwin_amd64-v1 ./bug-report
./bug-report

上传您的调试归档文件

将调试日志归档文件放入 Bug 报告工具的工作目录中。您可以解压缩归档文件并按照问题排查指南来尝试自行排查问题。但是,如果您有支持套餐,则可以与 Google Cloud 支持团队联系,他们将为您提供更多步骤来安全地上传日志归档文件。

手动收集 Anthos Service Mesh 日志

本部分介绍如何手动收集所有相关日志,而不是使用 Anthos Service Mesh Bug 报告工具。

Envoy 访问日志

Envoy 代理访问日志包含对问题排查有用的详细信息。但是,您必须启用这些日志并设置正确的详细信息级别。

如需详细了解如何解读日志内容,请参阅解读 Envoy 日志

启用或停用 Envoy 日志

如需启用 Envoy 代理访问日志,请为集群内 ASM 配置叠加文件,或为代管式 ASM 配置 ConfigMap

提高日志记录的详细信息级别

如需暂时提高日志的详细信息级别,请使用以下命令。重新创建 Pod 后,此设置将被撤消。

kubectl -n NAMESPACE exec POD_NAME -c istio-proxy -- curl -X POST http://localhost:15000/logging?level=info

将 Envoy 日志写入文件夹

如需收集 Envoy 代理访问日志并将其存储在文件夹中,请使用以下命令:

kubectl logs -l app=APPLICATION_NAME -c istio-proxy > /FILE_PATH

如需了解详情,请参阅获取 Envoy 的访问日志

Kubernetes 日志

Kubernetes 会生成多项日志,其中包含 istiod 组件(例如 Istiod、Ingress Gateway 和代理)的行为信息。您可以查看这些日志中是否存在错误,从而可能缩小问题的潜在原因范围。

使用以下命令捕获 istiod 日志:

kubectl -n istio-system logs $(kubectl -n istio-system get pods -lapp=istiod -oname) > ./LOGS_FOLDER/istiod.log

使用以下命令捕获 Istio Ingress Gateway 日志:

kubectl -n istio-system logs $(kubectl -n istio-system get pods -lapp=istio-ingressgateway -oname) > /FILE_PATH

使用以下命令捕获 Istio Proxy 日志:

kubectl -n WORKLOAD_NAMESPACE logs POD_NAME -c istio-proxy > ./LOGS_FOLDER/proxy.log

Kubernetes 配置转储文件

借助此信息,无权直接访问集群的用户可以查看各种资源的状态并识别潜在的配置问题。以下命令将 Kubernetes 配置写入 YAML 文件:

for namespace in "istio-system" "ns1" "ns2"; do kubectl get -oyaml deploy,statefulset,job,ingress,endpoints,configmap,event,secret,service,istio-io > ./LOGS_FOLDER/kubernetes.log; done

Envoy 核心转储文件

Envoy 核心转储文件通常对最终用户没有什么用处,但 Google 支持团队可能会请您按照以下步骤在问题排查过程中收集这些文件。

  1. 通过将以下内容添加到 IstioOperator 配置中,为网格中的所有代理启用核心转储文件:

    spec:
    values:
    global:
      proxy:
        enableCoreDumps: true
  2. 使用以下命令重新安装:

    istioctl install -f myOperatorFile.yaml
  3. 删除目标 Pod,使其在启用代理核心转储文件的情况下重新创建。

  4. 让进程运行;在它遇到问题时,请通过在 istio-proxy 容器中运行以下命令来触发核心转储文件:

    kubectl exec -it POD_NAME -c istio-proxy
  5. 查找 Envoy 容器的 PID:

    ps aux | grep -i envoy
  6. 使用 PID 停止 Envoy 进程,这会生成核心转储文件:

    kill -3 PID
  7. 等待容器重启(或使用 kill 命令)。

  8. 运行以下命令将核心转储文件提取到当前目录:

    kubectl cp PID:/var/lib/istio/data/core.proxy -c istio-proxy ./core.proxy

Envoy 代理配置

详细的 Envoy 代理配置包含额外的详细信息,这些详细信息可能有助于排查问题。您可以使用以下命令来收集此信息。在此示例命令中,ENDPOINT 是以下各项之一(按重要性顺序显示):* /certs * /clusters * /listeners * /config_dump * /memory * /server_info * /stats/prometheus * /runtime。

kubectl exec -i POD_NAME -c istio-proxy curl 127.0.0.1:15000/ENDPOINT > out.log