排查 Managed Service for Prometheus 的问题

本文档介绍了使用 Google Cloud Managed Service for Prometheus 时可能遇到的一些问题，并提供了有关诊断和解决问题的信息。

您配置了 Managed Service for Prometheus，但在 Grafana 或 Prometheus 界面中没有看到任何指标数据。概括来讲，原因可能是以下其中一种：

• 查询端出现问题，因此无法读取数据。查询端问题通常是由于服务账号读取数据的权限不正确或 Grafana 配置错误导致的。

• 注入端出现问题，未发送任何数据。 注入端问题可能是由服务账号、收集器或规则评估的配置问题引起的。

要确定问题在于注入端还是查询端，请尝试使用 Google Cloud 控制台中的 Metrics Explorer PromQL 标签页来查询数据。此页面可保证读取权限或 Grafana 设置不存在任何问题。

如需查看此页面，请执行以下操作：

1. 使用 Google Cloud 控制台项目选择器选择看不到其数据的项目。

2. 在 Google Cloud 控制台中，转到 Metrics Explorer 页面：

   进入 Metrics Explorer

   如果您使用搜索栏查找此页面，请选择子标题为监控的结果。

3. 在查询构建器窗格的工具栏中，选择名为  MQL 或  PromQL 的按钮。

4. 验证已在PromQL 切换开关中选择 PromQL。语言切换开关位于同一工具栏中，用于设置查询的格式。

5. 在编辑器中输入以下查询，然后点击运行查询：

   up
   

如果您查询 up 指标并看到结果，则问题在于查询端。如需了解如何解决这些问题，请参阅查询端问题。

如果您查询 up 指标时没有看到任何结果，则问题在于注入端。如需了解如何解决这些问题，请参阅注入端问题。

防火墙也可能导致注入和查询问题；如需了解详情，请参阅防火墙。

Cloud Monitoring 指标管理页面提供的信息可帮助您控制在收费指标上支出的金额，而不会影响可观测性。指标管理页面报告以下信息：

• 针对指标网域中基于字节和基于样本的结算以及各个指标的注入量。
• 有关标签和指标基数的数据。
• 每个指标的读取次数。
• 指标在提醒政策和自定义信息中心内的使用。
• 指标写入错误率。

您还可以使用指标管理来排除不需要的指标，从而降低提取这些指标的费用。

如需查看指标管理页面，请执行以下操作：

1. 在 Google Cloud 控制台中，转到 指标管理页面：

   进入指标管理

   如果您使用搜索栏查找此页面，请选择子标题为监控的结果。

2. 在工具栏中，选择时间窗口。默认情况下，指标管理页面会显示有关前一天收集的指标的信息。

如需详细了解指标管理页面，请参阅查看和管理指标使用情况。

查询端问题

大多数查询端问题是由以下某种原因造成的：

• 服务账号的权限或凭据不正确。
• Workload Identity Federation for GKE 配置错误（如果您的集群已启用此功能）。如需了解详情，请参阅为 Workload Identity Federation for GKE 配置服务账号。

首先，请执行以下操作：

• 根据查询设置说明仔细检查您的配置。

• 如果您使用的是 Workload Identity Federation for GKE，请通过执行以下操作来验证您的服务账号是否具有正确的权限：

  1. 在 Google Cloud 控制台中，进入 IAM 页面：

     前往 IAM

     如果您使用搜索栏查找此页面，请选择子标题为 IAM 和管理的结果。

  2. 确认主账号列表中的服务账号名称。确认服务账号的名称拼写是否正确。然后，点击 修改。

  3. 选择角色字段，然后点击当前使用并搜索 Monitoring Viewer 角色。如果服务账号没有此角色，请立即添加。

如果问题仍然存在，请考虑以下可能性：

Secret 配置错误或输入错误

如果您看到以下任何情况，则说明 Secret 可能缺失或输入错误：

• Grafana 或 Prometheus 界面中的以下“禁止”错误之一：

  • “警告：提取服务器时间时出现意外响应状态：禁止”
  • “警告：提取指标列表时出错：提取指标名称时出现意外响应状态：禁止”

• 日志中类似以下内容的消息：
  “无法读取凭据文件：打开 /gmp/key.json：无此类文件或目录”

如果您使用数据源同步器对 Grafana 进行身份验证和配置，请尝试以下操作来解决这些错误：

1. 确认您选择了正确的 Grafana API 端点、Grafana 数据源 UID 和 Grafana API 令牌。您可以通过运行 kubectl describe cronjob datasource-syncer 命令来检查 CronJob 中的变量。

2. 确认您已将数据源同步器的项目 ID 设置为您的服务账号具有凭据的同一指标范围或项目。

3. 验证您的 Grafana 服务账号具有“Admin”角色，并且您的 API 令牌未过期。

4. 验证您的服务账号具有所选项目 ID 的 Monitoring Viewer 角色。

5. 通过运行 kubectl logs job.batch/datasource-syncer-init 验证数据源同步器作业的日志中没有错误。此命令必须在应用 datasource-syncer.yaml 文件后立即运行。

6. 如果使用 Workload Identity Federation for GKE，请核实您没有输错账号密钥或凭据，并核实已将其绑定到正确的命名空间。

如果您使用的是旧版前端界面代理，请尝试以下操作来解决这些错误：

1. 确认您已将前端界面的项目 ID 设置为您的服务账号具有凭据的同一指标范围或项目。

2. 验证您为任何 --query.project-id 标志指定的项目 ID。

3. 验证您的服务账号具有所选项目 ID 的 Monitoring Viewer 角色。

4. 验证您在部署前端界面时是否设置了正确的项目 ID，并且未将其设置为字面量字符串 PROJECT_ID。

5. 如果使用 Workload Identity，请核实您没有输错账号密钥或凭据，并核实已将其绑定到正确的命名空间。

6. 如果要装载您自己的 Secret，请确保存在该 Secret：

   kubectl get secret gmp-test-sa -o json | jq '.data | keys'
   

7. 验证 Secret 是否已正确装载：

   kubectl get deploy frontend -o json | jq .spec.template.spec.volumes
   
   kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].volumeMounts
   

8. 确保 Secret 已正确传递给容器：

   kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].args
   

Grafana 的 HTTP 方法不正确

如果您看到 Grafana 中出现以下 API 错误，则表示 Grafana 配置为发送 POST 请求，而不是 GET 请求：

• “{"status":"error","errorType":"bad_data","error":"no match[] parameter provided"}%”

如需解决此问题，请按照配置数据源中的说明将 Grafana 配置为使用 GET 请求。

大型或长时间运行的查询超时

如果您在 Grafana 中看到以下错误，则表示您的默认查询超时过短：

• “Post "http://frontend.NAMESPACE_NAME.svc:9090/api/v1/query_range": net/http: timeout awaiting response headers”（发布“http://frontend.NAMESPACE_NAME.svc:9090/api/v1/query_range”：net/http：等待响应标头超时）

Managed Service for Prometheus 不会在查询超过 120 秒之前超时，而 Grafana 默认在 30 秒后超时。如需解决此问题，请按照配置数据源中的说明将 Grafana 中的超时增加到 120 秒。

标签验证错误

如果您在 Grafana 中看到以下错误之一，则表示您可能使用了不受支持的端点：

• “验证：尚不支持名称以外的标签”
• “创建 [作业] 模板：更新选项时出错：尚不支持名称以外的标签。”

Managed Service for Prometheus 仅针对 __name__ 标签支持 /api/v1/$label/values 端点。此限制会导致 Grafana 中使用 label_values($label) 变量的查询失败。

请改用 label_values($metric, $label) 表单。建议使用此查询，因为它会按指标限制返回的标签值，这样可以避免检索与信息中心内容无关的值。此查询会调用 Prometheus 支持的端点。

如需详细了解支持的端点，请参阅 API 兼容性。

已超出配额

如果您看到以下错误，则表示已超出 Cloud Monitoring API 的读取配额：

• “429：RESOURCE_EXHAUSTED：配额指标‘时序查询’和使用方‘project_number：...’的服务‘monitoring.googleapis.com’的限制‘每分钟的时序查询数’已超出配额。”

要解决此问题，请提交增加 Monitoring API 读取配额的申请。如需帮助，请与 Google Cloud 支持团队联系。有关配额的详细信息，请参阅使用配额。

多个项目的指标

如果您要查看多个 Google Cloud 项目中的指标，则无需配置多个数据源同步器或在 Grafana 中创建多个数据源。

请改为在一个包含要监控的项目的 Google Cloud 项目（范围限定项目）中创建 Cloud Monitoring 指标范围。使用范围限定项目配置 Grafana 数据源时，您可以访问指标范围内所有项目的数据。如需了解详情，请参阅查询和指标范围。

未指定受监控的资源类型

如果您看到以下错误，则需要在使用 PromQL 查询 Google Cloud 系统指标时指定受监控的资源类型：

• “指标配置为与多个受监控的资源类型一起使用；系列选择器必须在受监控的资源名称上指定标签匹配器”

您可以使用 monitored_resource 标签进行过滤来指定受监控的资源类型。如需详细了解如何识别和选择有效的受监控资源类型，请参阅指定受监控的资源类型。

收集器界面和 Google Cloud 控制台之间的计数器、直方图和摘要原始值不匹配

在查询累计 Prometheus 指标（包括计数器、直方图和摘要）的原始值时，您可能会注意到本地收集器 Prometheus 界面和 Google Cloud 控制台中的值之间存在差异。这是预期行为。

Monarch 需要开始时间戳，但 Prometheus 没有开始时间戳。Managed Service for Prometheus 会跳过任何时序中的第一个注入点并将其转换为开始时间戳，从而生成开始时间戳。后续点的值会从初始跳过点的值中减去，以确保费率正确无误。这会导致这些点的原始值存在永久性缺陷。

收集器界面中的数字与 Google Cloud 控制台中的数字之差等于收集器界面中记录的第一个值，这是预期现象，因为系统跳过了该初始值，并从后续点中减去该值。

这是可以接受的做法，因为在生产环境中不需要针对累计指标的原始值运行查询。所有有用查询都需要 rate() 函数或类似函数，在这种情况下，两个界面之间的任何时间范围内的差异都是相同的。累积指标只会增加，因此您无法对原始查询设置提醒，因为时序只会达到阈值一次。所有有用的提醒和图表都会查看值的变化或值的变化率。

收集器仅在本地保存大约 10 分钟的数据。由于在 10 分钟范围之前发生了重置，因此也可能出现原始累积值差异。为了消除这种可能性，在将收集器界面与 Google Cloud 控制台进行比较时，请尝试仅设置 10 分钟的查询回溯期。

引起差异的原因也可能是应用中有多个工作器线程，每个线程具有 /metrics 端点。如果您的应用启动多个线程，您必须将 Prometheus 客户端库置于多进程模式。如需了解详情，请参阅有关在 Prometheus 的 Python 客户端库中使用多进程模式的文档。

计数器数据丢失或直方图损坏

此问题最常见的信号是在查询普通计数器指标（例如，metric_name_foo 的 PromQL 查询）时看不到数据或看到数据间隙。如果在向查询添加 rate 函数（例如 rate(metric_name_foo[5m])）后出现数据，您可以确认这一点。

您可能还会注意到，注入的样本数量急剧增加，并且爬取量没有发生显著变化，或者在 Cloud Monitoring 中创建带有“未知”或“未知：计数器”后缀的新指标。

您可能还会注意到直方图操作（例如 quantile() 函数）无法按预期工作。

如果收集指标时没有 Prometheus 指标 TYPE，则会出现这些问题。由于 Monarch 是强类型，因此 Managed Service for Prometheus 会将无类型指标的后缀视为“未知”，并将其注入两次，一次用于采样平均值，一次用于计数器。然后，查询引擎会根据您使用的查询函数来选择是查询底层仪表盘指标还是计数器指标。

虽然这种启发式方法通常效果很好，但它可能会导致问题，例如在查询原始“未知：计数器”指标时出现奇怪的结果。此外，由于直方图是 Monarch 中的具体类型对象，因此提取三个必需的直方图指标作为单个计数器指标会导致直方图函数不起作用。由于“未知”类型的指标会被注入两次，因此不设置 TYPE 会使注入的样本加倍。

未设置 TYPE 的常见原因包括：

• 意外将 Managed Service for Prometheus 收集器配置为联合服务器。使用 Managed Service for Prometheus 时不支持联合功能。由于联合功能会有意地丢弃 TYPE 信息，因此实现联合功能会导致“未知”类型的指标。
• 在注入流水线中的任何时间点使用 Prometheus 远程写入。此协议还会有意删除 TYPE 信息。
• 使用修改指标名称的重新添加标规则。这会导致重命名的指标与原始指标名称的关联 TYPE 信息解除关联。
• 导出器没有为每个指标发出 TYPE。
• 一个暂时性问题，收集器首次启动时 TYPE 会被丢弃。

如需解决此问题，请执行以下操作：

• 停止将联合与 Managed Service for Prometheus 搭配使用。如果您希望在将数据发送到 Monarch 之前“汇总”数据，以降低基数和费用，请参阅配置局部聚合。
• 停止在集合路径中使用 Prometheus 远程写入。
• 通过访问 /metrics 端点，确认每个指标都存在 # TYPE 字段。
• 删除任何修改指标名称的重新添加标签规则。
• 通过调用 DeleteMetricDescriptor 删除具有“未知”或“未知：计数器”后缀的所有冲突指标。
• 或者始终使用 rate 或其他计数器处理函数查询计数器。

pod 重启后 Grafana 数据未保留

如果您的数据在 pod 重启后似乎从 Grafana 消失，但却显示在 Cloud Monitoring 中，则说明您在使用 Grafana 查询本地 Prometheus 实例，而不是 Managed Service for Prometheus。

如需了解如何配置 Grafana，以将托管式服务用作数据源，请参阅 Grafana。

导入 Grafana 信息中心

如需了解如何使用信息中心导入程序并进行问题排查，请参阅将 Grafana 信息中心导入 Cloud Monitoring。

如需了解信息中心内容转换方面的问题，请参阅导入程序的 README 文件。

注入端问题

注入端问题可能与收集或规则评估有关。首先查看代管式收集的错误日志。您可以运行以下命令：

kubectl logs -f -n gmp-system -lapp.kubernetes.io/part-of=gmp

kubectl logs -f -n gmp-system -lapp.kubernetes.io/name=collector -c prometheus

在 GKE Autopilot 集群上，您可以运行以下命令：

kubectl logs -f -n gke-gmp-system -lapp.kubernetes.io/part-of=gmp

kubectl logs -f -n gke-gmp-system -lapp.kubernetes.io/name=collector -c prometheus

目标状态功能可帮助您调试爬取目标。如需了解详情，请参阅目标状态信息。

端点状态缺失或太旧

如果您启用了目标状态功能，但一个或多个 PodMonitoring 或 ClusterPodMonitoring 资源缺少 Status.Endpoint Statuses 字段或值，则可能有以下某个问题：

• Managed Service for Prometheus 无法访问您的某个端点所在节点上的收集器。
• 您的一个或多个 PodMonitoring 或 ClusterPodMonitoring 配置没有产生有效目标。

类似问题还可能会导致 Status.Endpoint Statuses.Last Update Time 字段的值早几分钟加上抓取时间间隔。

如需解决此问题，请先检查与爬取端点关联的 Kubernetes pod 是否正在运行。如果您的 Kubernetes pod 正在运行，则标签选择器会匹配，并且您可以手动访问爬取端点（通常是通过访问 /metrics 端点），然后检查 Managed Service for Prometheus 收集器是否正在运行。

收集器比例小于 1

如果您启用了目标状态功能，则会收到您资源的状态信息。PodMonitoring 或 ClusterPodMonitoring 资源的 Status.Endpoint Statuses.Collectors Fraction 值表示可访问的收集器的比例（从 0 到 1）。例如，值 0.5 表示 50% 的收集器可访问，而值 1 表示 100% 的收集器可访问。

如果 Collectors Fraction 字段的值不是 1，则表示一个或多个收集器无法访问，并且这些节点中的指标可能不会被爬取。确保所有收集器都正在运行并且可通过集群网络访问。您可以使用以下命令查看收集器 Pod 的状态：

kubectl -n gmp-system get pods --selector="app.kubernetes.io/name=collector"

在 GKE Autopilot 集群上，此命令看起来略有不同：

kubectl -n gke-gmp-system get pods --selector="app.kubernetes.io/name=collector"

您可以使用以下命令调查各个收集器 pod（例如名为 collector-12345 的收集器 pod）：

kubectl -n gmp-system describe pods/collector-12345

在 GKE Autopilot 集群上，运行以下命令：

kubectl -n gke-gmp-system describe pods/collector-12345

如果收集器健康状况不佳，请参阅 GKE 工作负载问题排查。

如果收集器运行状况良好，请检查操作者日志。要检查操作者日志，请先运行以下命令以查找操作者 pod 名称：

kubectl -n gmp-system get pods --selector="app.kubernetes.io/name=gmp-collector"

在 GKE Autopilot 集群上，运行以下命令：

kubectl -n gke-gmp-system get pods --selector="app.kubernetes.io/name=gmp-collector"

然后，使用以下命令检查操作者日志（例如名为 gmp-operator-12345 的操作者 pod）：

kubectl -n gmp-system logs pods/gmp-operator-12345

在 GKE Autopilot 集群上，运行以下命令：

kubectl -n gke-gmp-system logs pods/gmp-operator-12345

目标健康状况不佳

如果您启用了目标状态功能，但一个或多个 PodMonitoring 或 ClusterPodMonitoring 资源的 Status.Endpoint Statuses.Unhealthy Targets 字段值不是 0，则收集器无法爬取一个或多个目标。

查看 Sample Groups 字段，该字段按错误消息对目标进行分组，并找到 Last Error 字段。Last Error 字段来自 Prometheus，并告知您无法爬取目标的原因。要解决此问题，请使用示例目标作为参考，并检查爬取端点是否正在运行。

未经授权的爬取端点

如果您看到以下错误之一并且爬取目标需要授权，则说明您的收集器未设置为使用正确的授权类型，或者使用了错误的授权载荷：

• server returned HTTP status 401 Unauthorized
• x509: certificate signed by unknown authority

如需解决此问题，请参阅配置授权的爬取端点。

已超出配额

如果您看到以下错误，则表示您已超出 Cloud Monitoring API 的注入配额：

• “429：配额指标‘时序注入请求’和使用方‘project_number：PROJECT_NUMBER’的服务‘monitoring.googleapis.com’的限制‘每分钟的时序注入请求数’已超出配额，rateLimitExceeded”

此错误最常发生在首次启动托管式服务时。默认配额（每秒注入 100,000 个样本）将用完。

要解决此问题，请提交增加 Monitoring API 注入配额的申请。如需帮助，请与 Google Cloud 支持团队联系。有关配额的详细信息，请参阅使用配额。

节点的默认服务账号缺少权限

如果您看到以下错误之一，则表示节点上的默认服务账号可能缺少权限：

• “执行查询：查询 Prometheus 时出错：client_error：客户端错误：403”
• “就绪性探测失败：HTTP 探测失败并显示状态代码：503”
• “查询 Prometheus 实例时出错”

Managed Service for Prometheus 中的代管式收集和代管式规则评估器都使用节点上的默认服务账号。此账号在创建时拥有所有必要的权限，但客户有时会手动移除 Monitoring 权限。此移除操作会导致收集和规则评估失败。

如需验证服务账号的权限，请执行以下操作之一：

• 确定底层 Compute Engine 节点名称，然后运行以下命令：

  gcloud compute instances describe NODE_NAME --format="json" | jq .serviceAccounts
  

  查找字符串 https://www.googleapis.com/auth/monitoring。如有必要，请按照服务账号配置错误中的说明添加 Monitoring。

• 转到集群中的底层虚拟机并检查节点的服务账号的配置：

  1. 在 Google Cloud 控制台中，转到 Kubernetes 集群页面：

     转到 Kubernetes 集群

     如果您使用搜索栏查找此页面，请选择子标题为 Kubernetes Engine 的结果。

  2. 选择节点，然后点击节点表中的节点的名称。

  3. 点击详细信息。

  4. 点击虚拟机实例链接。

  5. 找到 API 和身份管理窗格，然后点击显示详细信息。

  6. 查找具有完整访问权限的 Stackdriver Monitoring API。

数据源同步器或 Prometheus 界面也可能被配置为查看错误的项目。如需了解如何验证您在查询预期的指标范围，请参阅更改查询的项目。

服务账号配置错误

如果您看到以下错误消息之一，则表示收集器使用的服务账号没有正确的权限：

• “code = PermissionDenied desc = Permission monitoring.timeSeries.create denied（或资源可能不存在）”
• “Google：找不到默认凭据。如需了解详情，请参阅 https://developers.google.com/accounts/docs/application-default-credentials。”

如需验证您的服务账号是否具有正确的权限，请执行以下操作：

1. 在 Google Cloud 控制台中，进入 IAM 页面：

   前往 IAM

   如果您使用搜索栏查找此页面，请选择子标题为 IAM 和管理的结果。

2. 确认主账号列表中的服务账号名称。确认服务账号的名称拼写是否正确。然后，点击 修改。

3. 选择角色字段，然后点击目前使用的角色并搜索 Monitoring Metric Writer 或 Monitoring Editor 角色。 如果服务账号不具有上述任一角色，则为服务账号授予 Monitoring Metric Writer (roles/monitoring.metricWriter) 角色。

如果您在非 GKE Kubernetes 上运行，则必须将凭据明确传递给收集器和规则评估器。您必须在 rules 和 collection 部分中重复凭据。如需了解详情，请参阅明确提供凭据（针对收集）或明确提供凭据（针对规则）。

服务账号的范围通常限定为单个 Google Cloud 项目。使用一个服务账号写入多个项目的指标数据（例如，一个代管式规则评估器查询多项目指标范围时）可能会导致此权限错误。如果您使用的是默认服务账号，请考虑配置专用服务账号，以便您可以安全地为多个项目添加 monitoring.timeSeries.create 权限。如果您无法授予此权限，则可以使用指标重标记来将 project_id 标签重写为其他名称。之后，项目 ID 会默认为 Prometheus 服务器或规则评估器在其中运行的 Google Cloud 项目。

爬取配置无效

如果您看到以下错误，则表示您的 PodMonitoring 或 ClusterPodMonitoring 格式不正确：

• “发生内部错误：调用网络钩子失败：‘validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com": Post "https://gmp-operator.gmp-system.svc:443/validate/monitoring.googleapis.com/v1/podmonitorings?timeout=10s’：EOF”

要解决此问题，请确保您的自定义资源根据规范设置了正确的格式。

无法解析的准入网络钩子或无效的 HTTP 客户端配置

在低于 0.12 版的 Managed Service for Prometheus 版本中，您可能会看到类似于以下内容的错误，这与非默认命名空间中的 Secret 注入有关：

• “admission webhook ‘validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com’拒绝了请求：端点的无效定义（索引为 0）：无法解析或无效的 Prometheus HTTP 客户端配置：必须使用命名空间“my-custom-namespace”，但得到的是“default””

要解决此问题，请升级到 0.12 版或更高版本。

爬取间隔和超时问题

使用 Managed Service for Prometheus 时，爬取超时不能大于爬取间隔。如需检查日志是否存在此问题，请运行以下命令：

kubectl -n gmp-system logs ds/collector prometheus

在 GKE Autopilot 集群上，运行以下命令：

kubectl -n gke-gmp-system logs ds/collector prometheus

查找以下消息：

• “作业名称为‘PodMonitoring/gmp-system/example-app/go-metrics’的爬取配置的爬取超时大于爬取间隔”

如需解决此问题，请将爬取间隔的值设置为等于或大于爬取超时值。

指标上缺少 TYPE

如果您看到以下错误，则表示指标缺少类型信息：

• “未找到指标名称‘{metric_name}’的元数据”

如需验证缺少类型信息是否是问题所在，请检查导出应用的 /metrics 输出。如果没有如下所示的行，则表示缺少类型信息：

# TYPE {metric_name} <type>

某些库（例如来自 VictoriaMetrics 1.28.0 之前版本的库）会有意删除类型信息。Managed Service for Prometheus 不支持这些库。

时序冲突

如果您看到以下错误之一，则表示可能有多个收集器尝试写入同一时序：

• “无法写入一个或多个时序：一个或多个点的写入频率高于为指标配置的最大采样周期。”
• “无法写入一个或多个时序：点必须按顺序写入。指定的一个或多个点的结束时间早于最近的点。”

最常见的原因和解决方案如下：

• 使用高可用性对。Managed Service for Prometheus 不支持传统的高可用性收集。使用此配置可能会创建多个收集器以尝试将数据写入同一时间序列，从而导致此错误。

  如需解决此问题，请将副本数减少到 1 来停用副本收集器，或使用受支持的高可用性方法。

• 使用重标记规则，尤其是对作业或实例进行操作的规则。Managed Service for Prometheus 通过 {project_id, location, cluster, namespace, job, instance} 标签组合部分标识唯一时间序列。使用重标记规则丢弃这些标签（尤其是 job 和 instance 标签）通常会导致冲突。建议不要重写这些标签。

  如需解决此问题，请删除导致问题的规则；这通常可以通过使用 labeldrop 操作的 metricRelabeling 规则来实现。您可以通过注释掉所有重新添加标签规则并一次恢复一条规则来识别有问题的规则，直到错误再次出现。

导致时序冲突的不太常见的原因是爬取间隔短于 5 秒。Managed Service for Prometheus 支持的最小爬取间隔为 5 秒。

超出标签数的限制

如果您看到以下错误，则表示您可能为某个指标定义了过多标签：

• “无法写入一个或多个时序：新标签会导致指标 prometheus.googleapis.com/METRIC_NAME 超过 PER_PROJECT_LIMIT 个标签”。

如果您频繁更改指标的定义，使得某个指标名称在指标的整个生命周期内具有多组独立的标签键，则通常会发生此错误。Cloud Monitoring 对每个指标的标签数设定了限制；如需了解详情，请参阅用户定义的指标的限制。

注意：标签数（也称为标签名称、标签键或维度）与基数不同。基数是指所有标签的唯一标签值的组合数量。

解决此问题有三个步骤：

1. 确定给定指标具有过多标签或频繁更改的标签的原因。

   • 您可以使用 metricDescriptors.list 页面上的 APIs Explorer 微件来调用该方法。如需了解详情，请参阅 APIs Explorer。如需查看示例，请参阅列出指标和资源类型。

2. 解决问题的来源，这可能涉及调整 PodMonitoring 的重新添加标签规则、更改导出器或修复插桩。

3. 删除此指标的指标描述符（这会导致数据丢失），以便使用更小、更稳定的标签集重新创建指标描述符。您可以使用 metricDescriptors.delete 方法来执行此操作。

最常见的问题来源包括：

• 从对指标附加了动态标签的导出程序或应用收集指标。例如，具有其他容器标签和环境变量的自行部署 cAdvisor 或注入动态注解的 DataDog 代理。

  如需解决此问题，您可以在 PodMonitoring 上使用 metricRelabeling 部分来保留或丢弃标签。某些应用和导出器还支持更改导出的指标的配置。例如，cAdvisor 具有许多高级运行时设置，可动态添加标签。使用托管式收集时，我们建议您使用内置自动 kubelet 收集。

• 使用重新添加标签规则（尤其是动态附加标签名称的规则），可能会导致标签数超出预期。

  如需解决此问题，请删除导致问题的规则条目。

有关创建和更新指标及标签的速率限制

如果您看到以下错误，则表示已达到创建新指标并将新指标标签添加到现有指标的每分钟速率限制：

• “请求受到限制。您已经达到每个项目每分钟的指标定义或标签定义更改次数限制。”

此速率限制通常仅在首次与 Managed Service for Prometheus 集成时才会达到，例如，迁移现有的成熟 Prometheus 部署以使用自部署收集。这不是注入数据点的速率限制。此速率限制仅在创建全新指标或向现有指标添加新标签时适用。

此配额是固定的，但在新指标和指标标签的创建达到每分钟限制时，任何问题都会自动解决。

有关指标描述符数量的限制

如果您看到以下错误，则表示已达到单个 Google Cloud 项目中的指标描述符数量配额限制：

• “您的指标描述符配额已用尽。”

默认情况下，此限制设置为 25,000。虽然如果您的指标格式正确，则可以根据请求提升此配额，但达到此上限的可能性极大，因为您会将格式错误的指标名称注入到系统中。

Prometheus 具有一个维度数据模型，该模型应将集群或命名空间名称等信息编码为标签值。当维度信息嵌入到度量名称本身中时，度量描述符的数量就会无限增加。此外，由于在这种情况下标签没有得到正确使用，跨集群、命名空间或服务查询和聚合数据变得更加困难。

Cloud Monitoring 和 Managed Service for Prometheus 均不支持非维度指标，例如为 StatsD 或 Graphite 设置格式的指标。虽然大多数 Prometheus 导出器都可以开箱即用正确配置，但某些导出工具（如 StatsD 导出器、Vault 导出器或 Istio 附带的 Envoy 代理）必须明确配置为使用标签而不是将信息嵌入指标名称中。格式错误的指标名称示例包括：

• request_path_____path_to_a_resource____istio_request_duration_milliseconds
• envoy_cluster_grpc_method_name_failure
• envoy_cluster_clustername_upstream_cx_connect_ms_bucket
• vault_rollback_attempt_path_name_1700683024
• service__________________________________________latency_bucket

如需确认此问题，请执行以下操作：

1. 在 Google Cloud 控制台中，选择与错误关联的 Google Cloud 项目。

2. 在 Google Cloud 控制台中，转到 指标管理页面：

   进入指标管理

   如果您使用搜索栏查找此页面，请选择子标题为监控的结果。

3. 确认“活跃”和“非活跃”指标的总和超过 25,000。在大多数情况下，您应该会看到大量非活跃指标。
4. 按计费样本数升序排序，浏览列表，并查找模式。

或者，您可以使用 Metrics Explorer 确认此问题：

1. 在 Google Cloud 控制台中，选择与错误关联的 Google Cloud 项目。

2. 在 Google Cloud 控制台中，转到 Metrics Explorer 页面：

   进入 Metrics Explorer

   如果您使用搜索栏查找此页面，请选择子标题为监控的结果。

3. 在查询构建器中，点击一个指标，然后清除“有效”复选框。
4. 在搜索栏中输入“prometheus”。
5. 查找指标名称中的任何模式。

确定指示指标格式错误的模式后，您可以通过在来源处修复导出器，然后删除违规指标描述符来缓解问题。

为防止再次出现此问题，您必须先配置相关导出器，使其不再发出格式错误的指标。我们建议您查看导出器的相关帮助文档。您可以通过手动访问 /metrics 端点并检查导出的指标名称来确认问题已解决。

然后，您可以使用 projects.metricDescriptors.delete 方法删除格式错误的指标来释放配额。为了更轻松地遍历格式错误的指标列表，我们提供了您可以使用的 Golang 脚本。此脚本接受可识别格式错误指标的正则表达式，并删除与模式匹配的任何指标描述符。由于指标删除操作是不可逆转的，因此我们强烈建议您先使用试运行模式运行脚本。

无错误，无指标

如果您使用的是代管式收集，则不会看到任何错误，但数据未显示在 Cloud Monitoring 中，最可能的原因是指标导出器或爬取配置未正确配置。除非您先应用有效的爬取配置，否则 Managed Service for Prometheus 不会发送任何时序数据。

如需确定这是否是原因，请尝试部署示例应用和示例 PodMonitoring 资源。现在，如果您看到 up 指标（可能需要几分钟时间），则表示爬取配置或导出器存在问题。

根本原因可能是存在任意数量的内容。我们建议您检查以下各项：

• PodMonitoring 是否引用了有效端口。

• 导出器的 Deployment 规范是否具有正确命名的端口。

• 选择器（最常见的是 app）是否与 Deployment 和 PodMonitoring 资源匹配。

• 您是否可以通过手动访问预期端点和端口来查看其数据。

• 您已将 PodMonitoring 资源安装在要抓取的应用所在的命名空间中。请勿在 gmp-system 或 gke-gmp-system 命名空间中安装任何自定义资源或应用。

• 指标和标签名称是否与 Prometheus 的验证正则表达式匹配。Managed Service for Prometheus 不支持以 _ 字符开头的标签名称。

• 您使用的不是一组导致所有数据被过滤掉的过滤条件。在 OperatorConfig 资源中使用 collection 过滤条件时要特别注意过滤条件没有冲突。

• 如果在 Google Cloud 之外运行，则应将 project 或 project-id 设置为有效的 Google Cloud 项目，并且将 location 设置为有效的 Google Cloud 区域。您不能将 global 用作 location 的值。

• 您的指标是四种 Prometheus 指标类型之一。某些库（例如 Kube State Metrics）公开了 Info、Stateset 和 GaugeHistogram 等 OpenMetrics 指标类型，但这些指标类型不受 Managed Service for Prometheus 支持并且会被静默删除。

短时间运行的目标缺失某些指标

Google Cloud Managed Service for Prometheus 已部署，并且没有配置错误；但是缺失某些指标。

确定生成部分缺失指标的部署。如果部署是 Google Kubernetes Engine 的 CronJob，则确定作业通常运行多长时间：

1. 查找 Cron 作业部署 yaml 文件，并查找状态（会在文件末尾列出）。以下示例中的状态显示作业运行了一分钟：

     status:
       lastScheduleTime: "2024-04-03T16:20:00Z"
       lastSuccessfulTime: "2024-04-03T16:21:07Z"
   

2. 如果运行时间少于五分钟，则作业运行的时间不够长，无法持续爬取指标数据。

   如需解决此问题，请尝试以下操作：

   • 配置作业，以确保它在作业启动后至少五分钟内不会退出。

   • 配置作业以检测在退出之前是否爬取了指标。此功能需要库支持。

   • 考虑创建一个基于日志的分布值指标，而不是收集指标数据。如果数据以低速率发布，建议使用此方法。如需了解详情，请参阅基于日志的指标。

3. 如果运行时间超过五分钟或或是运行时间不一致，请参阅本文档的目标健康状况不佳部分。

导出工具中的收集问题

如果导出工具中的指标未被注入，请进行如下检查：

• 使用 kubectl port-forward 命令验证导出工具是否正常运行并能够导出指标。

  例如，如需检查命名空间 test 中设置有 app.kubernetes.io/name=redis 选择器的 Pod 是否在端口 9121 上的 /metrics 端点发出指标，您可以通过输入以下命令来执行端口转发：

  kubectl port-forward "$(kubectl get pods -l app.kubernetes.io/name=redis -n test -o jsonpath='{.items[0].metadata.name}')" 9121
  

  使用浏览器或另一个终端会话中的 curl 访问端点 localhost:9121/metrics，以验证导出工具是否公开了指标以供抓取。

• 检查您是否可以在 Google Cloud 控制台中查询指标，但不能在 Grafana 中查询指标。如果是这样，则问题出在 Grafana，而不是指标收集功能。

• 通过检查收集器公开的 Prometheus 网页界面，验证代管式收集器是否能够抓取导出工具中的内容。

  1. 确定在运行导出工具的同一节点上运行的代管式收集器。例如，如果您的导出工具在命名空间 test 中的 Pod 上运行，并且这些 Pod 带有 app.kubernetes.io/name=redis 标签，则可通过以下命令确定在同一节点上运行的代管式收集器：

     kubectl get pods -l app=managed-prometheus-collector --field-selector="spec.nodeName=$(kubectl get pods -l app.kubernetes.io/name=redis -n test -o jsonpath='{.items[0].spec.nodeName}')" -n gmp-system -o jsonpath='{.items[0].metadata.name}'
     

  2. 从代管式收集器的端口 19090 设置端口转发：

     kubectl port-forward POD_NAME -n gmp-system 19090
     

  3. 导航到 localhost:19090/targets 网址以访问网页界面。如果导出工具列为目标之一，则表示您的代管式收集器能够成功抓取导出工具中的内容。

收集器内存不足 (OOM) 错误

如果您使用的是受管理集合，并且在收集器上遇到内存不足 (OOM) 错误，请考虑启用 Pod 纵向自动扩缩。

运算符出现内存不足 (OOM) 错误

如果您使用的是托管式收集，并且在运算符上遇到内存不足 (OOM) 错误，请考虑停用目标状态功能。目标状态功能可能会导致较大集群中的运算符性能问题。

防火墙

防火墙可能会导致注入和查询问题。您必须将防火墙配置为允许 POST 和 GET 请求发送到 Monitoring API 服务 monitoring.googleapis.com，以允许注入和查询。

关于并发修改的错误

“对项目配置执行的并发修改过多”错误消息通常是暂时的，几分钟后会解决。此错误通常是由于移除了影响许多不同指标的重新添加标签规则而导致的。移除操作会导致形成对项目中指标描述符的更新队列。处理队列后，该错误会消失。

如需了解详情，请参阅有关创建和更新指标及标签的限制。

不兼容的值类型

如果您在注入或查询时看到以下错误，则表示您的指标存在值类型不兼容问题：

• “指标 prometheus.googleapis.com/metric_name/gauge 的值类型必须为 INT64，但为 DOUBLE”
• “指标 prometheus.googleapis.com/metric_name/gauge 的值类型必须为 DOUBLE，但为 INT64”
• “无法写入一个或多个时序：指标 prometheus.googleapis.com/target_info/gauge 的值类型与现有值类型 (INT64) 冲突”

您可能会在提取时看到此错误，因为 Monarch 不支持将 DOUBLE 类型的数据写入 INT64 类型的指标，也不支持将 INT64 类型的数据写入 DOUBLE 类型的指标。使用多项目指标范围查询时，您也可能会看到此错误，因为 Monarch 无法将一个项目中的 DOUBLE 类型指标与另一个项目中的 INT64 类型指标进行合并。

只有在 OpenTelemetry 收集器报告数据时才会发生此错误，如果您同时使用 OpenTelemetry（使用 googlemanagedprometheus 导出器）和 Prometheus 报告同一指标的数据，则更有可能发生此错误，这在 target_info 指标中很常见。

原因可能是以下任一情况：

• 您正在收集 OTLP 指标，而 OTLP 指标库将其值类型从 DOUBLE 更改为 INT64，就像 OpenTelemetry 的 Java 指标一样。新版指标库现在与旧版指标库创建的指标值类型不兼容。
• 您同时使用 Prometheus 和 OpenTelemetry 收集 target_info 指标。Prometheus 会将此指标收集为 DOUBLE，而 OpenTelemetry 会将此指标收集为 INT64。现在，您的收集器会将两种值类型写入同一项目中的同一指标，并且只有首先创建指标描述符的收集器会成功。
• 您在一个项目中使用 OpenTelemetry 作为 INT64 收集 target_info，而在另一个项目中使用 Prometheus 作为 DOUBLE 收集 target_info。将这两个指标添加到同一指标范围，然后通过指标范围查询该指标，会导致不兼容的指标值类型之间的联合无效。

可以通过执行以下操作，强制所有指标值类型为 DOUBLE 来解决此问题：

1. 重新配置 OpenTelemetry 收集器，以通过启用 feature-gate exporter.googlemanagedprometheus.intToDouble 标志强制所有指标为 DOUBLE。
2. 删除所有 INT64 指标描述符，并将其重新创建为 DOUBLE。您可以使用 delete_metric_descriptors.go 脚本来自动执行此操作。

按照这些步骤操作会删除存储为 INT64 指标的所有数据。除了删除 INT64 指标之外，没有其他方法可以完全解决此问题。