本文档可帮助您排查 Google Distributed Cloud Virtual for Bare Metal 中的可观测性问题。如果您遇到任何这些问题，请查看建议的修复和解决方法。
如果您需要其他帮助，请与 Google 支持团队联系。
不收集 Cloud Audit Logs 日志
Cloud Audit Logs 默认启用，除非在集群配置的clusterOperations 部分下设置了 disableCloudAuditLogging 标志。
如果启用了 Cloud Audit Logs，则权限是不收集日志的最常见原因。在这种情况下，Cloud Audit Logs 代理容器中会显示权限遭拒的错误消息。
Cloud Audit Logs 代理容器在所有 Google Distributed Cloud Virtual for Bare Metal 集群中以 DaemonSet 的形式运行。如果您看到权限错误，请遵循排查和解决权限问题的步骤。
不会收集 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 Virtual for Bare Metal 中，都可能会遇到此问题。
默认的 CPU 和内存限制在最近几个 Google Distributed Cloud Virtual for Bare Metal 版本中有所提高，因此这些资源问题应该不太常见。
修复和解决方法
如需检查您的问题是否是由内存不足引起的，请遵循以下步骤：
- 使用
kubectl describe pod或kubectl get pod -o yaml，并查看错误状态消息。 - 在重启之前，检查 KSM 的内存消耗和利用率指标，并确认其是否达到限制。
如果确认问题在于内存不足，请使用以下任一解决方案：
提高 KSM 的内存请求和限制。
如需调整 KSM 的 CPU 和内存，请为
kube-state-metrics使用 Stackdriver 自定义资源的 resourceOverride。减少 KSM 中的指标数量。
对于 Google Distributed Cloud Virtual for Bare Metal 1.13，默认情况下，KSM 仅公开少量指标，称为核心指标。此行为意味着资源用量低于以前的版本，但您可以遵循相同的过程进一步减少 KSM 指标的数量。
对于低于 1.13 的 Google Distributed Cloud Virtual for Bare Metal 版本，KSM 使用默认标志。此配置公开了大量指标。
gke-metrics-agent 崩溃循环
如果 gke-metrics-agent 仅在存在 kube-state-metrics 的节点上遇到内存不足问题，则原因在于大量 kube-state-metrics 指标。如需缓解此问题，请缩减 stackdriver-operator 并修改 KSM 以公开一小部分所需的指标，如上一部分所述。请记住在集群升级到 Google Distributed Cloud Virtual for Bare Metal 1.13 后，对 stackdriver-operator 进行纵向扩容（其中 KSM 默认公开较少数量的核心指标）。
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 Virtual for Bare Metal 中，都可能会遇到此问题。
在过去几个 Google Distributed Cloud Virtual for Bare Metal 版本中，默认的 CPU 和内存限制有所提高，因此这些资源问题应该不太常见。
修复和解决方法
如需检查您的问题是否是由内存不足引起的，请遵循以下步骤：
- 使用
kubectl describe pod或kubectl get pod -o yaml，并查看错误状态消息。 - 在重启之前，检查
stackdriver-metadata-agent的内存消耗和利用率指标，并确认其是否达到限制。
resourceAttrOverride 字段中的内存限制。metrics-server 崩溃循环
症状
Pod 横向自动扩缩器和 kubectl top 无法在集群中运行。
原因和受影响的版本
此问题不常见，但会因为大型集群或 Pod 密度较高的集群内存不足错误而出现。
在任何版本的 Google Distributed Cloud Virtual for Bare Metal 中，都可能会遇到此问题。
修复和解决方法
提高指标服务器资源限制。在 Google Distributed Cloud Virtual for Bare Metal 1.13 版及更高版本中，metrics-server 的命名空间及其配置已从 kube-system 移至 gke-managed-metrics-server。
metrics-server-operator 并手动更改 metrics-server Pod。后续步骤
如果您需要其他帮助，请与 Google 支持团队联系。