1.9 版

解决 Anthos Service Mesh 中的可观测性和遥测问题

本部分介绍常见的 Anthos Service Mesh 问题以及如何解决这些问题。如果您需要其他帮助,请参阅获取支持

在 Anthos Service Mesh 遥测中,Envoy 代理会定期调用 Google Cloud 的运维套件 API 以报告遥测数据。API 调用的类型决定了其调用频率:

  • 日志记录:每 10 秒
  • 指标:每分钟
  • 边缘(Context API/拓扑视图):每 分钟增量报告一次,每 10 分钟完整报告一次。
  • 跟踪记录:根据您配置的采样频率(通常每 100 个请求一个)决定。

遥测信息中心会从 Confluence 和 Google Cloud 的运维套件收集数据,以显示各种以服务为中心的信息中心。

服务信息中心缺少服务

信息中心仅显示 HTTP(S)/gRPC 服务。如果您的服务应出现在列表中,请验证 Anthos Service Mesh 遥测是否将其标识为 HTTP 服务。

如果服务仍然缺失,请验证集群中是否存在 Kubernetes 服务配置 {: class="external"}

查看所有 Kubernetes 服务的列表:

kubectl get services --all-namespaces

查看特定命名空间中的 Kubernetes 服务列表:

kubectl get services -n YOUR_NAMESPACE

服务缺少指标/指标有误

如果信息中心内的服务缺少指标或指标有误,请参阅以下部分,了解可能的解决方法。

验证 Sidecar 代理是否存在以及是否已正确注入

命名空间可能没有自动注入标签,或手动注入失败。确认命名空间中的 pod 至少有两个容器,并且其中一个是 istio-proxy 容器:

kubectl -n YOUR_NAMESPACE get pods

验证遥测配置是否存在

istio-system 命名空间中使用 EnvoyFilters 来配置遥测。如果不进行此配置,Anthos Service Mesh 将不会向 Google Cloud 的运维套件报告数据。

验证 Google Cloud 的运维套件配置(和元数据交换配置)是否存在:

kubectl -n istio-system get envoyfilter

预期输出结果类似如下所示:

NAME                        AGE
metadata-exchange-1.4       13d
metadata-exchange-1.5       13d
stackdriver-filter-1.4      13d
stackdriver-filter-1.5      13d
...

如需进一步确认 Google Cloud 的运维套件过滤器是否配置正确,请从每个代理收集配置转储,并查找是否存在 Google Cloud 的运维套件过滤器:

kubectl exec YOUR_POD_NAME -n YOUR_NAMESPACE -c istio-proxy curl localhost:15000/config_dump

在上一个命令的输出中,查找 Google Cloud 的运维套件过滤器,如下所示:

"config": {
    "root_id": "stackdriver_inbound",
    "vm_config": {
        "vm_id": "stackdriver_inbound",
        "runtime": "envoy.wasm.runtime.null",
        "code": {
            "local": {
                "inline_string": "envoy.wasm.null.stackdriver"
             }
         }
     },
     "configuration": "{....}"
}

验证 Anthos Service Mesh 可识别 HTTP 服务

如果 Kubernetes 服务的服务端口未使用 http 前缀,则界面中将不会显示指标。确认该服务为其端口使用了正确的名称。

验证项目已启用 Cloud Monitoring API

确认 Google Cloud Console 的“API 和服务”信息中心内已启用 Cloud Monitoring API(这是默认设置)。

验证没有向 Cloud Monitoring API 报告错误

在 Google Cloud Console 的“API 和服务”信息中心中,打开按响应代码划分的流量图表

如果您看到了错误消息,则可能意味着需要进一步调查。请特别留意大量 429 错误消息,这表示潜在的配额问题。如需了解问题排查步骤,请参阅下一部分。

验证 Cloud Monitoring API 的正确配额

在 Google Cloud Console 中,打开 IAM & Admin 菜单并验证是否有配额选项。您可以直接通过以下网址访问此页面:

https://console.cloud.google.com/iam-admin/quotas?project=YOUR_PROJECT_ID

此页面显示项目的完整配额,您可以在其中搜索 Cloud Monitoring API

验证 Envoy 代理中没有错误日志

查看相关代理的日志,并搜索错误消息实例:

kubectl -n YOUR_NAMESPACE logs YOUR_POD_NAME -c istio-proxy

但是,请忽略如下正常警告消息:

[warning][filter] [src/envoy/http/authn/http_filter_factory.cc:83]
mTLS PERMISSIVE mode is used, connection can be either plaintext or TLS,
and client cert can be omitted. Please consider to upgrade to mTLS STRICT mode
for more secure configuration that only allows TLS connection with client cert.
See https://istio.io/docs/tasks/security/mtls-migration/ [warning][config]
[bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91]
gRPC config stream closed: 13

服务缺少遥测数据或遥测数据不正确

默认情况下,安装 Anthos Service Mesh 时,将在 Cloud 项目中启用 Cloud Monitoring 和 Cloud Logging。如需报告遥测数据,注入到服务 pod 的每个 Sidecar 代理都会调用 Cloud Monitoring API 和 Cloud Logging API。部署工作负载后,遥测数据大约需要一两分钟的时间才会显示在 Cloud Console 中。Anthos Service Mesh 自动使服务信息中心保持最新:

  • 对于指标,Sidecar 代理大约每分钟调用一次 Cloud Monitoring API。
  • 为了更新拓扑图,Sidecar 代理大约每分钟发送一次增量报告,大约每十分钟发送一次完整报告。
  • 对于日志记录,Sidecar 代理大约每十秒调用一次 Cloud Logging API。
  • 如需进行跟踪,您必须启用 Cloud Trace。跟踪将根据您配置的采样频率(通常每 100 个请求一个)进行报告。

在 Anthos Service Mesh 的“指标”页面上仅为 HTTP 服务显示指标。如果您没有看到任何指标,请验证应用服务的命名空间中的所有 pod 是否已注入 Sidecar 代理:

kubectl get pod -n YOUR_NAMESPACE --all

在输出中,请注意 READY 列显示每个工作负载均有两个容器:主容器和 Sidecar 代理的容器。