您正在查看旧版 v1.19 Service Mesh 文档。

可用版本

Cloud Service Mesh
1.22 归档
 1.21 归档
 1.20 归档
 1.19 归档
 1.18 归档

此页面由 Cloud Translation API 翻译。

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

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

在 Cloud Service Mesh 遥测中，Envoy 代理会调用 Google Cloud Observability API 定期报告遥测数据。API 调用的类型决定了其调用频率：

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

遥测信息中心会从 Confluence 和 Google Cloud Observability 收集数据，以显示各种以服务为中心的信息中心。

服务信息中心缺少服务

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

如果服务仍然缺失，请验证集群中是否存在 Kubernetes 服务配置。

查看所有 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 来配置遥测。如果不进行此配置，Cloud Service Mesh 将不会向 Google Cloud Observability 报告数据。

验证 Google Cloud Observability 配置（和元数据交换配置）是否存在：

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 Observability 过滤条件：

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": "{....}"
}

验证 Cloud Service Mesh 可识别 HTTP 服务

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

验证项目已启用 Cloud Monitoring API

确认 Google Cloud 控制台的“API 和服务”信息中心内已启用 Cloud Monitoring API（这是默认设置）。

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

在“Google Cloud 控制台 API 和服务”信息中心中，打开“按响应代码划分的流量”图表网址：

https://console.cloud.google.com/apis/api/monitoring.googleapis.com/metrics?folder=&organizationId=&project=YOUR_PROJECT_ID

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

验证 Cloud Monitoring API 的正确配额

在 Google Cloud 控制台中，打开 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

验证 `metric.mesh_uid` 是否已正确设置

打开 Metrics Explorer 并运行以下 MQL 查询：

fetch istio_canonical_service
| metric 'istio.io/service/server/request_count'
| align delta(1m)
| every 1m
| group_by [metric.destination_canonical_service_namespace, metric.destination_canonical_service_name, metric.mesh_uid]

验证所有预期的服务是否正在报告指标，并且其 metric.mesh_uid 格式为 proj-<Cloud Service Mesh fleet project number>。

如果 metric.mesh_uid 具有任何其他值，则 Cloud Service Mesh 信息中心不会显示指标。metric.mesh_uid 是在集群上安装 Cloud Service Mesh 时进行设置，因此请调查您的安装方法，了解是否有办法将其设置为预期值。

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

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

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

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

kubectl get pod -n YOUR_NAMESPACE --all

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

此外，“服务”信息中心仅显示服务器指标，因此如果客户端不在网格中或者配置为仅报告客户端指标（例如入站流量网关），则遥测数据可能不会显示。