排查 Monitoring API 问题

本指南介绍了使用 Monitoring API v3 时可能会出现的一些问题。

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

使用 API Explorer 进行调试

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

如果您在调用方法时遇到问题,请使用该方法的参考页面上的 API Explorer(试用此 API)微件来调试您的问题。如需详细了解,请参阅 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 v3。

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

  • 400 INVALID_ARGUMENT,“请求缺少字段 interval.endTime”:如果缺少结束时间,或结束时间存在但格式不正确,您会看到此消息。您使用的是 API Explorer,请不要引用时间字段的值。

    下面是一些正确的时间规范示例:

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

缺少结果

如果您的 API 调用返回状态代码 200 和空响应,则有以下几种可能:

  • 如果您的调用使用了过滤器,则该过滤器可能未匹配任何内容。过滤器匹配区分大小写。要解决过滤器问题,请先仅指定一个过滤器组件(如 metric.type),看看能否获得结果。逐个添加其他过滤器组件以构建请求。

  • 如果您使用的是自定义指标,则可能尚未指定定义自定义指标的项目。

如果您使用 timeSeries.list 提取时间序列数据后发现某些数据点缺失,请检查以下其他原因:

  • 如果数据的发布时间已超过几周,则该数据可能已过期。如需了解详情,请参阅数据保留

  • 如果数据是刚刚写入的,则可能还不在 Monitoring 中。如需了解详情,请参阅指标数据的延迟时间

  • 检查您指定的时间间隔是否正确:

    • 检查结束时间是否正确。
    • 检查开始时间是否正确,且是否早于结束时间。如果开始时间缺失或格式不正确,则默认为结束时间值,并且时间间隔将仅匹配开始时间和结束时间正好为间隔结束时间的点。这对 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 次重试后或为应用花费的时间超过合理值时停止,以截断重试周期。

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