本文档可帮助您排查 Google Distributed Cloud 中的可观测性问题。如果您遇到任何这些问题，请查看建议的修复和解决方法。
如果您需要其他帮助，请与 Cloud Customer Care 联系。
您还可以参阅获取支持，详细了解支持资源，包括以下内容：
不收集 Cloud Audit Logs 日志
在集群配置的cloudAuditLogging 部分中检查 Cloud Audit Logs 是否已启用。验证项目 ID、位置和服务账号密钥配置正确。项目 ID 必须与 gkeConnect 下的项目 ID 相同。如果启用了 Cloud Audit Logs，则权限是不收集日志的最常见原因。在这种情况下，Cloud Audit Logs 代理容器中会显示权限遭拒的错误消息。
Cloud Audit Logs 代理容器以以下方式运行：- 管理员集群或独立集群中的静态 Pod。
kube-apiserverPod 中的边车容器。
如果您看到权限错误，请遵循排查和解决权限问题的步骤。
另一个可能的原因是您的项目可能已达到支持的服务账号数量上限，请参阅 Cloud Audit Logs 服务账号泄露。
不会收集 kube-state-metrics 指标
kube-state-metrics (KSM) 作为集群中的单个副本 Deployment 运行，并为集群中的几乎所有资源生成指标。当 KSM 和 gke-metrics-agent 在同一节点上运行时，所有节点上的指标代理发生服务中断的风险会提高。
KSM 指标的名称遵循 kube_<ResourceKind> 格式，例如 kube_pod_container_info。以 kube_onpremusercluster_ 开头的指标来自本地集群控制器，而不是 KSM。
如果缺少 KSM 指标，请查看以下问题排查步骤：
- 在 Cloud Monitoring 中，使用
kubernetes.io/anthos/container/...等摘要 API 指标检查 KSM 的 CPU、内存和重启数量。这是具有 KSM 的单独流水线。确认 KSM Pod 不受资源不足的限制。- 如果这些摘要 API 指标不适用于 KSM，则同一节点上的
gke-metrics-agent可能也存在相同的问题。
- 如果这些摘要 API 指标不适用于 KSM，则同一节点上的
- 在集群中，检查 KSM Pod 以及同一节点上具有 KSM 的
gke-metrics-agentPod 的状态和日志。
kube-state-metrics 崩溃循环
症状
Cloud Monitoring 不提供 kube-state-metrics (KSM) 的指标。
原因
大型集群或具有大量资源的集群更有可能发生这种情况。KSM 作为单个副本 Deployment 运行，并列出集群中几乎所有资源，例如 Pod、Deployment、DaemonSet、ConfigMap、Secret 和 PersistentVolume。并为每个资源对象生成指标。如果任何资源具有许多对象（例如具有超过 10,000 个 Pod 的集群），则 KSM 可能会耗尽内存。
受影响的版本
任何版本的 Google Distributed Cloud 都可能遇到此问题。
在最近的几个 Google Distributed Cloud 版本中，默认 CPU 和内存限制已提高，因此这些资源问题应该不常见。
修复和解决方法
如需检查您的问题是否是由内存不足引起的，请遵循以下步骤：
- 使用
kubectl describe pod或kubectl get pod -o yaml，并查看错误状态消息。 - 在重启之前，检查 KSM 的内存消耗和利用率指标，并确认其是否达到限制。
如果确认问题在于内存不足，请使用以下任一解决方案：
提高 KSM 的内存请求和限制。
如需调整 KSM 的 CPU 和内存，请执行以下步骤：
对于 Google Distributed Cloud 1.16.0 版或更高版本，Google Cloud Observability 会管理 KSM。如需更新 KSM，请参阅替换 Stackdriver 组件的默认 CPU 及内存请求和限制。
对于 Google Distributed Cloud 1.10.7 或更高版本、1.11.3 或更高版本、1.12.2 或更高版本，以及 1.13 及更高版本（但低于 1.16.0），请创建一个
ConfigMap来调整 CPU 和内存：使用以下定义在
kube-system命名空间（对于 1.13 或更高版本为gke-managed-metrics-server）中创建一个名为kube-state-metrics-resizer-config的ConfigMap。根据需要调整 CPU 和内存数量：apiVersion: v1 kind: ConfigMap metadata: name: kube-state-metrics-resizer-config namespace: kube-system data: NannyConfiguration: |- apiVersion: nannyconfig/v1alpha1 kind: NannyConfiguration baseCPU: 200m baseMemory: 1Gi cpuPerNode: 3m memoryPerNode: 20Mi ```创建 ConfigMap 后，请使用以下命令删除 KSM Pod，以重启 KSM Deployment：
kubectl -n kube-system rollout restart deployment kube-state-metrics
对于 Google Distributed Cloud 1.9 及更低版本、1.10.6 或更低版本、1.11.2 或更低版本，以及 1.12.1 或更低版本：
- 没有适合的长期解决方案。如果您修改 KSM 相关资源，
monitoring-operator会自动还原更改。 - 您可以将
monitoring-operator缩减到 0 个副本，然后修改 KSM 部署以调整其资源限制。但是，集群将不会收到使用monitoring-operator的新补丁版本提供的漏洞补丁。请记得在集群升级到包含修复的更高版本后重新扩容monitoring-operator。
- 没有适合的长期解决方案。如果您修改 KSM 相关资源，
减少 KSM 中的指标数量。
对于 Google Distributed Cloud 1.13，KSM 默认仅公开少量称为“核心指标”的指标。此行为意味着资源用量低于以前的版本，但您可以遵循相同的过程进一步减少 KSM 指标的数量。
对于比 1.13 低的 Google Distributed Cloud 版本，KSM 使用默认标志。此配置公开了大量指标。
gke-metrics-agent 崩溃循环
如果 gke-metrics-agent 仅在存在 kube-state-metrics 的节点上遇到内存不足问题，则原因在于大量 kube-state-metrics 指标。如需缓解此问题，请缩减 stackdriver-operator 并修改 KSM 以公开一小部分所需的指标，如上一部分所述。在集群升级到 Google Distributed Cloud 1.13（其中 KSM 默认公开较少数量的核心指标）后，请记得对 stackdriver-operator 重新扩容。
gke-metric-agent 的 Pod 日志。您可以通过向 Stackdriver 自定义资源添加 resourceAttrOverride 字段来调整所有 gke-metrics-agent Pod 的 CPU 和内存。
stackdriver-metadata-agent 崩溃循环
症状
在 Cloud Monitoring 中过滤指标时，没有可用的系统元数据标签。
原因
stackdriver-metadata-agent 崩溃循环的最常见原因是内存不足事件。此事件与 kube-state-metrics 类似。尽管 stackdriver-metadata-agent 未列出所有资源，但它仍会列出相关资源类型的所有对象，如 Pod、Deployment 和 NetworkPolicy。代理作为单个副本 Deployment 运行，如果对象数量过大，这会增加内存不足事件的风险。
受影响的版本
任何版本的 Google Distributed Cloud 都可能遇到此问题。
在最近的几个 Google Distributed Cloud 版本中，默认 CPU 和内存限制已提高，因此这些资源问题应该不常见。
修复和解决方法
如需检查您的问题是否是由内存不足引起的，请遵循以下步骤：
- 使用
kubectl describe pod或kubectl get pod -o yaml，并查看错误状态消息。 - 在重启之前，检查
stackdriver-metadata-agent的内存消耗和利用率指标，并确认其是否达到限制。
resourceAttrOverride 字段中的内存限制。
metrics-server 崩溃循环
症状
Pod 横向自动扩缩器和 kubectl top 无法在集群中运行。
原因和受影响的版本
此问题不常见，但会因为大型集群或 Pod 密度较高的集群内存不足错误而出现。
任何版本的 Google Distributed Cloud 都可能遇到此问题。
修复和解决方法
提高指标服务器资源限制。在 Google Distributed Cloud 1.13 版及更高版本中，metrics-server 的命名空间及其配置已从 kube-system 移至 gke-managed-metrics-server。
在删除 Cloud Audit Logs 服务账号期间，并非所有资源都会移除
删除用于 Cloud Audit Logs 的服务账号后，并非所有 Google Cloud资源都会被删除。如果您定期删除并重新创建用于 Cloud Audit Logs 的服务账号，审核日志记录最终会开始失败。
症状
Cloud Audit Logs 代理容器中会显示权限遭拒的错误消息。
如需确认审核日志失败是否由此问题引起，请运行以下命令：
curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/global/features/cloudauditlogging
将 PROJECT_NUMBER 替换为您的项目编号。
响应会返回项目中与 Cloud Audit Logs 搭配使用的所有服务账号，包括已删除的服务账号。
原因和受影响的版本
删除用于 Cloud Audit Logs 的服务账号后，并非所有 Google Cloud 资源都会移除，最终您会达到项目的服务账号数量上限（1,000 个）。
任何版本的 Google Distributed Cloud 都可能遇到此问题。
修复和解决方法
创建一个环境变量，其中包含您要保留的所有服务账号的英文逗号分隔列表。使用英文单引号将每个服务账号邮箱括起来，然后使用英文双引号将整个列表括起来。您可以从以下内容入手：
SERVICE_ACCOUNT_EMAILS="'SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com'"替换以下内容：
PROJECT_ID：您的项目 ID。SERVICE_ACCOUNT_NAME：服务账号名称。
完整的列表应类似于以下示例：
"'sa_name1@example-project-12345.iam.gserviceaccount.com','sa_name2@example-project-12345.iam.gserviceaccount.com','sa_name3@example-project-12345.iam.gserviceaccount.com'"运行以下命令，从项目中移除 Cloud Audit Logs 功能：
curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "Content-Type: application/json" \ https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/FLEET_REGION /features/cloudauditlogging替换以下内容：
PROJECT_NUMBER：项目编号。FLEET_REGION：集群的舰队成员资格位置。这可以是特定区域，例如us-central1或global。您可以运行gcloud container fleet memberships list命令来获取成员资格位置。
此命令会完全删除所有服务账号。
仅使用要保留的服务账号重新创建 Cloud Audit Logs 功能：
curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "Content-Type: application/json" \ https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/FLEET_REGION/features?feature_id=cloudauditlogging \ -d '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":[$SERVICE_ACCOUNT_EMAILS]}}}'
后续步骤
如果您需要其他帮助，请与 Cloud Customer Care 联系。
您还可以参阅获取支持，详细了解支持资源，包括以下内容：