(multiplication)  / (division)  % (modulo)  ^ (power/exponentiation) 1 1 举一个例子来演示真实环境下的算术运算符的应用，比如之前的例子，对于内存可用率的指标 mem_available_percent 这个指标是采集器直接计算好的，如果采集器没有计算，而是上报了 原始指标 mem_available 逻辑/集合运算符 相关运算符有三个：and、or、unless 用于 instant-vector 之间的运算。首先来解释一下各个 运算符的行为。 and vector1 and vector2，其结果是一个由vector1的元素组成的向量，对于这些元素，vector2中 存在着完全匹配的标签集，其他元素被删除。metric的名称和值从左边的向量转移过来。 用于什么场景？先经过 vector1 做过滤 率70%还有非常大的余量，所以这里我们使用and附加一个条件，限制一下disk_total，即磁盘 总大小，磁盘总大小小于500GB，才适用磁盘利用率大于70%这个规则。 or vector1 or vector2，其结果是一个向量，包含vector1的所有原始元素（标签集+值）以及 vector2中所有在vector1中没有匹配标签集的元素。 举一个例子，比如系统负载，有最近1分钟、最近5分钟、最近15分钟的负载，需求是：最近1分

Prometheus（Kubernetes 可能有多套，以至于 Prometheus 可能有多套）或者 Nightingale， 日志的监控可能用的 Elastalert，如果上云了，可能还会有多套不同的云监控（尤其是多云场景下）。 监控系统的重心，通常是采集、存储、可视化、生成告警事件，但通常都不具有完备的事件后续处理能 力。这里说的后续处理主要包括：多渠道分级通知、告警静默、抑制、收敛聚合、降噪、排班、认领升 制、收敛聚合、降噪、排班、认领升级、协同闭环 处理等等。看起来需求很多，最核心的痛点有两个： ● 告警太多，打扰太多 ● 告警疏漏，无法闭环 我们先来看第一个痛点，首先分析一下造成告警太多、打扰太多的原因是什么，然后针对原因提出对应的 方案。 告警太多的常见原因 最常见的原因，是告警规则设置得不合理。比如很多规则触发了告警之后，实际没有后续动作，只是起到 第四个原因是预期内的维护动作导致的。比如程序升级变更，如果进程重启时间过长，可能会导致关联的 服务告警，或者某个机器重启，忘记提前屏蔽了，也会产生一堆关联告警。 了解了常见原因，下面我们来看一下有哪些常见解法。 优化告警规则 类似 PagerDuty FlashDuty 这种产品，一定程度上是可以解决一些告警过多的问题，但如果能从告警规 则的源头做好优化，自然是事半功倍。很多