排查 Monitoring API 问题

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

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 或指标类型名称有误。检查拼写和大小写。

    如果您使用的不是 APIs Explorer，请尝试使用它。如果您的 API 调用在 API Explorer 中正常进行，可能是因为您进行 API 调用的环境中存在授权问题。请前往 API 管理器页面，验证是否已为您的项目启用 Monitoring API。

  • 带有“字段过滤条件包含无效值”的 400 INVALID_ARGUMENT：验证监控过滤条件的拼写和格式。如需了解详情，请参阅 Monitoring 过滤器。

  • 400 INVALID_ARGUMENT 带有“Request was missing field bucket.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 会将开始时间设置为结束时间。对于 GAUGE 指标，此时间间隔仅与开始时间和结束时间恰好是其结束时间的点匹配。对于跨时间范围进行衡量的 CUMULATIVE 或 DELTA 指标，没有匹配的积分。如需了解详情，请参阅时间间隔。

重试 API 错误

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

  • 503 UNAVAILABLE：当问题属于短期或暂时情况时，重试非常有用。
  • 429 RESOURCE_EXHAUSTED：对于采用基于时间的配额（例如每 t 秒调用 n 次）的长时间运行的后台作业，在延迟之后重试会非常有用。如果问题是短期或暂时的，或者基于卷的配额已用尽，重试就毫无用处。对于暂时性情况，请考虑容忍失败。对于配额相关问题，请考虑减少配额用量或申请增加配额。

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

重试请求是否安全？

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

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

使用指数退避重试

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

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

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

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

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

实现指数退避的方法有很多。以下示例将不断增加的退避延迟时间添加到 1,000 毫秒的最短延迟时间。初始退避延迟为 2 毫秒，每次重试后，它会增加到 2retry_count毫秒。

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

  • 最小延迟 = 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 次重试后或为应用花费的时间超过合理值时停止，以截断重试周期。n

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