排查 Monitoring API 问题

本指南介绍了使用 Google 文档 Monitoring API。

Monitoring API 是一组 Cloud API 中的一个。这些 API 共享一组通用的错误代码。如需查看 Cloud API 定义的错误代码列表以及处理错误的一般建议,请参阅处理错误

使用 API Explorer 进行调试

API Explorer 是内置于 API 方法参考页面的微件。它可让您通过填写字段来调用 方法;它不需要您 编写代码。

如果调用方法时遇到问题,请使用 APIs Explorer (试用此 API) widget 调试问题。如需了解详情,请参阅 API Explorer

常规 API 错误

以下是您可能会在 API 调用中看到的一些 Monitoring API 错误和消息:

  • 404 NOT_FOUND,“在此服务器上找不到请求的网址”:网址的某些部分不正确。将网址与 方法的参考页面上显示的方法的网址。 此错误可能表示存在拼写错误(例如“project”而不是“projects”)或大小写错误(例如“TimeSeries”而不是“timeSeries”)。

  • 401 UNAUTHENTICATED 中显示“用户无权访问该项目 (或指标)”:此错误代码通常表示存在授权问题, 但可能意味着项目 ID 或指标类型有误 名称。检查拼写和大小写。

    如果您没有使用 API Explorer,请尝试使用。如果您的 API 调用在 API Explorer 中可以正常运行,则您发出 API 调用的环境可能存在授权问题。前往 API 管理器页面进行验证 说明已为您的项目启用 Monitoring API。

  • 400 INVALID_ARGUMENT,“字段过滤器的值无效”:检查监控过滤器的拼写和格式。如需了解详情,请参阅 Monitoring 过滤器

  • 400 INVALID_ARGUMENT 包含“请求缺少字段间隔.endTime”: 如果缺少结束时间或显示结束时间, 格式不正确 如果您使用的是 API Explorer,请不要用英文引号括住时间字段的值。

    以下是一些有效的时间规范示例:

    2024-05-11T01:23:45Z
    2024-05-11T01:23:45.678Z
    2024-05-11T01:23:45.678+05:00
    2024-05-11T01:23:45.678-04:30
    

缺少结果

当 API 调用返回状态代码 200 和空响应时,请考虑以下操作: 以下:

  • 如果调用使用了过滤器,则该过滤器可能未匹配任何内容。过滤器匹配区分大小写。解析过滤条件 请先只指定一个过滤器组件,例如 metric.type,并确认是否可收到结果。逐个添加其他过滤器组件以构建请求。
  • 使用自定义指标时,请确认 定义了指定的指标。

使用 timeSeries.list 方法:

  • 数据可能已过时。 如需了解详情,请参阅数据保留

  • 数据可能尚未传播到 Monitoring。 如需了解详情,请参阅指标数据的延迟时间

  • 间隔时间无效:

    • 确认结束时间是否正确。
    • 请确认开始时间是否正确,是否早于 结束时间。如果开始时间缺失或格式错误,API 会将 从“start-time”更改为“end-time”。对于 GAUGE 个指标,仅限此时间间隔 与开始和结束时间正好是间隔时间的点匹配 结束时间。适用于CUMULATIVEDELTA指标,这些指标用于衡量 时间段,则没有匹配的数据点。 如需了解详情,请参阅时间间隔

重试 API 错误

两个 Cloud API 错误代码说明了重试请求可能有用的特定情形:

  • 503 UNAVAILABLE:如果问题是短期有效的或 暂时性条件。
  • 429 RESOURCE_EXHAUSTED:延迟后重试仅对具有基于时间的配额的长时间运行的后台作业有用,例如每 t 秒最多只能进行 n 次调用。如果该问题是短期存在或 或已用尽基于数量的配额时。对于暂时性情况,不妨考虑容忍失败。对于与配额相关的 请考虑减少配额用量或申请增加配额。

在编写可能会重试请求的代码时,首先请确保重试请求是安全的。

重试请求是否安全?

如果您的请求具有幂等性,则重试是安全的。幂等操作是指状态的任何变化不依赖于当前状态的操作。例如:

  • 读取 x 具有幂等性;值不发生变化。
  • x 设置为 10 具有幂等性;这一操作可能会更改状态(如果该值之前不是 10)。但是,当前值是什么无关紧要,尝试设置此值的次数也无关紧要。
  • 递增 x 不具有幂等性,因为新值取决于当前值。

使用指数退避重试

在实现代码以重试请求时,您不希望无限期地快速发出新请求。如果系统过载,则此方法会引起问题。

请改为使用截断指数退避算法方法。如果请求失败的原因是暂时过载而不是真正的不可用,则解决方案为减少负载。截断指数退避算法遵循以下一般模式:

  • 确定您愿意等待的重试时间或者您希望进行的重试次数。超出此限制时,将服务视为不可用,并为应用适当地处理该情况。这就是退避算法截断的原因,即在某个时刻停止重试。

  • 使用不断增长的暂停来重试请求,以退避重试频率。重试直到请求成功或达到您设置的限制。

    间隔通常按以重试次数为指数的某个函数增加,使其成为指数退避

实现指数退避的方法有很多。下面是一个示例,它会向 1000 毫秒的最小延迟增加不断增长的退避延迟。初始退避延迟为 2 毫秒,每次重试后,它会增加到 2重试次数毫秒。

下表显示了使用初始值的重试间隔:

  • 最小延迟 = 1 秒 = 1000 毫秒
  • 初始退避时间 = 2 毫秒
重试次数 增加的延迟(毫秒) 重试间隔(毫秒)
0 20 = 1 1001
1 21 = 2 1002
2 22 = 4 1004
3 23 = 8 1008
4 24 = 16 1016
n 2n 1000 + 2n

您可以在 n 次重试后或为应用花费的时间超过合理值时停止,以截断重试周期。

如需了解详情,请参阅维基百科文章指数退避算法