本文档介绍了可用于降低提醒费用的策略。
整合提醒政策以监控更多资源
由于每个条件的费用为 0.10 美元，因此使用一个提醒政策监控多个资源比各资源分别使用一个提醒政策监控更具成本效益。请参考以下示例：
示例 1
数据
- 100 个虚拟机
- 每个虚拟机会发出一个指标，即
metric_name metric_name有一个标签，该标签有 10 个值
- 一个提醒条件
- 条件汇总到虚拟机级别
- 30 秒执行期
- 条件费用： 1 个条件 * 每月 0.10 美元 = 每月 0.10 美元
- 时序费用： 每期返回 100 个时序 * 每月 86,400 期 = 每月返回 860 万个时序 * 每百万个时序 0.35 美元 = 每月 3.02 美元
- 总费用：每月 3.12 美元
示例 2
数据
- 100 个虚拟机
- 每个虚拟机会发出一个指标，即
metric_name metric_name有一个标签，该标签有 10 个值
- 100 个条件
- 每个条件都经过过滤，并汇总到一个虚拟机
- 30 秒执行期
- 条件费用：100 个条件 * 每月 0.10 美元 = 每月 10 美元
- 时序费用： 100 个条件 * 每期每个条件返回 1 个时序 * 每月 86,400 期 = 每月返回 860 万个时序 * 每百万个时序 0.35 美元 = 每月 3.02 美元
- 总费用：每月 13.02 美元
在这两个示例中，您监控的资源数量相同。不过，示例 2 使用了 100 个提醒政策，而示例 1 仅使用了一个提醒政策。因此，示例 1 每月可节省近 10 美元。
仅汇总到需要发出提醒的级别
与汇总到较低细分程度相比，汇总到较高细分程度会产生更高的费用。例如，汇总到 Google Cloud 项目级的费用低于汇总到集群级的费用，而汇总到集群级的费用低于汇总到集群和命名空间级的费用。
请参考以下示例：
示例 1
数据
- 100 个虚拟机
- 每个虚拟机会发出一个指标，即
metric_name metric_name有一个标签，该标签有 10 个值
- 一个提醒条件
- 条件汇总到虚拟机级别
- 30 秒执行期
- 条件费用： 1 个条件 * 每月 0.10 美元 = 每月 0.10 美元
- 时序费用： 每期返回 100 个时序 * 每月 86,400 期 = 每月返回 860 万个时序 * 每百万个时序 0.35 美元 = 每月 3.02 美元
- 总费用：每月 3.12 美元
示例 4
数据
- 100 个虚拟机，其中每个虚拟机都属于一项服务
- 总共 5 项服务
- 每个虚拟机会发出一个指标，即
metric_name metric_name有一个标签，该标签有 10 个值
- 一个条件
- 条件汇总到服务级别
- 30 秒执行期
- 条件费用： 1 个条件 * 每月 0.10 美元 = 每月 0.10 美元
- 时序费用： 每期返回 5 个时序 * 每月 86,400 期 = 每月返回 432,000 个时序 * 每百万个时序 0.35 美元 = 每月 0.14 美元
- 总费用：每月 0.24 美元
示例 5
数据
- 100 个虚拟机
- 每个虚拟机会发出一个指标，即
metric_name metric_name具有 100 个标签，每个标签有 1,000 个值
- 一个条件
- 条件汇总到虚拟机级别
- 30 秒执行期
- 条件费用： 1 个条件 * 每月 0.10 美元 = 每月 0.10 美元
- 时序费用： 每期返回 100 个时序 * 每月 86,400 期 = 每月返回 850 万个时序 * 每百万个时序 0.35 美元 = 每月 3.02 美元
- 总费用：每月 3.12 美元
将示例 1 与示例 4 进行比较：这两个示例都在监控相同的底层数据，并且都具有单个提醒政策。不过，由于示例 4 中的提醒政策汇总到服务，而示例 1 中的提醒政策更精细地汇总到虚拟机，因此示例 4 比示例 1 中的提醒政策更便宜。
此外，请比较示例 1 和示例 5：在本例中，示例 5 中的指标基数比示例 1 中的指标基数高 10,000 倍。不过，由于示例 1 和示例 5 中的提醒政策都汇总到虚拟机，并且这两个示例中的虚拟机数量相同，因此这两个示例的价格相等。
配置提醒政策时，请选择最适合您的使用情形的汇总级别。例如，如果您希望收到 CPU 利用率方面的提醒，则可能需要汇总到虚拟机和 CPU 级别。如果您希望收到各端点延迟时间方面的提醒，则可能需要汇总到端点级别。
不要发出未汇总的原始数据方面的提醒
Monitoring 使用维度指标系统，其中任何指标的总基数都等于受监控的资源数量乘以相应指标的标签组合数量。例如，如果您有 100 个虚拟机在发出某个指标，并且该指标有 10 个标签，每个标签有 10 个值，那么您的总基数为 100 * 10 * 10 = 10,000。
由于基数缩放的方式，发出原始数据方面的提醒的费用可能会非常高。在上面的示例中，每个执行期都会返回 10,000 个时序。不过，如果您汇总到虚拟机，则无论底层数据的标签基数是多少，每个执行期都仅返回 100 个时序。
如果发出原始数据方面的提醒，当指标收到新标签时，时序有可能会增加。在前面的示例中，如果用户向您的指标添加了一个新标签，则总基数会增加到 100 * 11 * 10 = 11,000 个时序。在这种情况下，即使提醒政策未发生变化，返回的时序数量也会在每个执行期增加 1,000。如果您改为汇总到虚拟机，那么尽管底层基数有所增加，但系统仍只会返回 100 个时序。
过滤掉不必要的响应
配置条件，以便仅评估满足您的提醒需求的数据。如果您不会采取措施来修正某些问题，请将其从提醒政策中排除。例如，您可能不需要发出实习生的开发虚拟机方面的提醒。
为减少不必要的费用和突发事件，您可以过滤掉不重要的时序。您可以使用 Google Cloud 元数据标签为资源添加类别标记，然后过滤掉不需要的元数据类别。
使用 top-stream 运算符来减少返回的时序数量
如果您的条件使用 PromQL 或 MQL 查询，则可以使用 top-stream 运算符选择返回的具有最高值的时序数：
例如，PromQL 查询中的 topk(metric, 5) 子句会将每个执行期内返回的时序数量限制为 5 个。
将时序限制为前 N 个可能会导致数据缺失或触发错误的突发事件，例如：
- 如果超过 N 个时序违反了您设定的阈值，那么您将错过前 N 个时序之外的数据。
- 如果违规时序出现在前 N 个时序之外，即使被排除的时序仍违反该阈值，突发事件也可能会自动关闭。
- 您的条件查询可能不会显示重要背景信息，例如按预期运行的基准时序。
为降低此类风险，请为 N 选择较大的值，并且仅在评估大量时序的提醒政策中使用 top-stream 运算符，例如针对各个 Kubernetes 容器的突发事件。
增加执行期的时长（仅限 PromQL）
如果您的条件使用 PromQL 查询，则可以通过在条件中设置 evaluationInterval 字段来修改执行期的时长。
评估间隔越长，每月返回的时序就越少；例如，间隔为 15 秒的条件查询的运行频率是间隔为 30 秒的查询的两倍，而间隔为 1 分钟的查询的运行频率是间隔为 30 秒的查询的一半。