本文档介绍了可用于降低提醒费用的策略。
整合提醒政策，以便在更多资源上运行
由于每个条件的费用为 1.50 美元，因此使用一个提醒政策监控多个资源比使用一个提醒政策监控每个资源更经济高效。请参考以下示例：
示例 1
数据
- 100 个虚拟机
- 每个虚拟机都会发出一个指标
metric_name metric_name有一个标签，其中包含 10 个值
- 1 个提醒发出条件
- 条件汇总到虚拟机级
- 30 秒的执行时段
- 条件费用： 1 个条件 * 每月 $1.50 = 每月 $1.50
- 时间序列费用： 每个时间段返回的时序数为 100 个 * 每月 86,400 个周期 = 每月返回 860 万个时序 * 每 100 万个时序 $0.35 = 每月 $3.02
- 总费用：每月 4.52 美元
示例 2
数据
- 100 个虚拟机
- 每个虚拟机都会发出一个指标
metric_name metric_name有一个标签，其中包含 10 个值
- 100 项条件
- 系统会过滤每个条件，并将其汇总到一个虚拟机
- 30 秒执行期
- 条件费用：100 个条件 * 每月 1.50 美元 = 每月 150 美元
- 时间序列费用： 100 个条件 * 每个时间段的每个条件返回 1 个时序 * 每月 86,400 个周期 = 每月返回 860 万个时序 * 每 100 万个时序 $0.35 = 每月 $3.02
- 总费用：每月$153.02
在这两个示例中，您监控的资源数量相同。不过，示例 2 使用了 100 项提醒政策，而示例 1 仅使用了 1 项提醒政策。因此，示例 1 每月的费用几乎要低 150 美元。
仅汇总到您需要提醒的级别
与汇总到较低粒度级别相比，汇总到较高粒度级别会导致费用更高。例如，汇总到 Google Cloud 项目级的费用低于汇总到集群级的费用，汇总到集群级的费用低于汇总到集群和命名空间级的费用。
请参考以下示例：
示例 1
数据
- 100 个虚拟机
- 每个虚拟机都会发出一个指标
metric_name metric_name有一个标签，其中包含 10 个值
- 1 个提醒发出条件
- 条件汇总到虚拟机级
- 30 秒的执行时段
- 条件费用： 1 个条件 * 每月 $1.50 = 每月 $1.50
- 时间序列费用： 每个时间段返回的时序数为 100 个 * 每月 86,400 个周期 = 每月返回 860 万个时序 * 每 100 万个时序 $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 个时序 * 每 100 万个时序 $0.35 = 每月 $0.14
- 总费用：每月$1.64
示例 5
数据
- 100 个虚拟机
- 每个虚拟机发出一个指标：
metric_name metric_name有 100 个标签，每个标签有 1,000 个值
- 一个条件
- 条件汇总到虚拟机级
- 30 秒的执行时段
- 条件费用： 1 个条件 * 每月 $1.50 = 每月 $1.50
- 时间序列费用： 每个时间段返回的时序数为 100 个 * 每月 86,400 个周期 = 每月返回 850 万个时序 * 每 100 万个时序 $0.35 = 每月 $3.02
- 总费用：每月$4.52
将示例 1 与示例 4 进行比较： 这两个示例针对相同的底层数据运行，并且具有单个提醒 政策。不过，由于示例 4 中的提醒政策会汇总到服务，因此其费用低于示例 1 中的提醒政策，后者会更精细地汇总到虚拟机。
此外，请将示例 1 与示例 5 进行比较：在这种情况下，示例 5 中的指标基数是示例 1 中的指标基数的 1 万倍。但是，由于 示例 1 和示例 5 都会汇总到虚拟机，因为 两个示例中的虚拟机数量相同，但这两个示例 价格。
配置提醒政策时，请选择 最适合您的用例。例如，如果您想要在 CPU 上发出提醒， 那么您可能希望聚合到虚拟机和 CPU 级别。如果您希望按端点发出延迟时间提醒，则可能需要汇总到端点级别。
不针对未汇总的原始数据发出提醒
Monitoring 使用维度指标系统，其中任何指标 总 [基数][基数] 等于受监控的资源数量 乘以该指标的标签组合数。例如，如果您有 100 个虚拟机发送指标，并且该指标有 10 个标签，每个标签有 10 个值，那么基数总和为 100 * 10 * 10 = 10,000。
由于基数的扩展方式，基于原始数据发出提醒的费用可能非常高。在上面的示例中，每个执行周期都会返回 10,000 个时间序列。但是，如果您汇总到虚拟机， 每个执行期仅返回 100 个时序，而不考虑标签 或底层数据的基数。
如果针对原始数据发出提醒，当指标收到新标签时，您可能会面临时序增加的风险。在前面的示例中，如果用户向您的指标添加了新标签，则基数总数会增加到 100 * 11 * 10 = 11,000 个时间序列。在这种情况下， 即使提醒数量和时序不超过 1000 个， 政策保持不变。如果您改为汇总到虚拟机， 的基础基数增加，您仍然只返回了 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 秒）。