本指南介绍了使用 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 或指标类型名称存在错误。检查拼写和大小写。如果您没有使用 API Explorer，请尝试使用。如果您的 API 调用在 API Explorer 中可以正常运行，则您在发出 API 调用的环境中可能存在授权问题。前往 API 管理器页面，验证是否已为您的项目启用 Monitoring API。
400 INVALID_ARGUMENT，“字段过滤器的值无效”：检查监控过滤器的拼写和格式。如需了解详情，请参阅 Monitoring 过滤器。400 INVALID_ARGUMENT，其中包含“请求缺少字段 interval.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 次调用。如果问题是短期或暂时性情况，或者您已耗尽基于量的配额，则重试不会有用。对于暂时性条件，请考虑容忍失败。对于与配额相关的问题，请考虑减少配额用量或申请增加配额。
在编写可能会重试请求的代码时，首先请确保重试请求是安全的。
重试请求是否安全？
如果您的请求具有幂等性，则重试是安全的。幂等操作是指状态的任何变化不依赖于当前状态的操作。例如：
- 读取 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 次重试后或为应用花费的时间超过合理值时停止，以截断重试周期。
如需了解详情，请参阅维基百科文章指数退避算法。