本指南介绍了使用 Monitoring API 时可能会出现的一些问题。
Monitoring API 是一组 Cloud API 中的一个。这些 API 共享一组通用的错误代码。如需查看 Cloud API 定义的错误代码列表以及处理错误的一般建议，请参阅处理错误。
使用 APIs Explorer 进行调试
API Explorer 是内置于 API 方法参考页面的微件。它可让您通过填写字段来调用方法，而无需编写代码。
如果您在调用方法时遇到问题，请使用该方法的参考页面上的 APIs Explorer（试用此 API）widget 来调试问题。如需了解详情，请参阅 APIs 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，“请求缺少字段 interval.endTime”：如果缺少结束时间，或结束时间存在但格式不正确，您会看到此消息。 如果您使用的是 APIs 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）。但是，当前值是什么无关紧要，尝试设置此值的次数也无关紧要。
- 递增 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
如需了解详情，请参阅维基百科文章指数退避算法。