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