找到相关指标数据，会找到5条，再根 据 mem_total{app="clickhouse"} 也能找到5条，二者相除的逻辑姑且可以理解为，循环遍历 mem_available 的5条记录，对于每一条，去 mem_total 的5条记录中找标签相同的记录，进 行除法运算。除法运算得到5条结果（0~1之间的数字），然后跟100相乘（得到百分比大 小），100这个数字称为标量，5条结果和标量计算，会把每一条结果分别乘以100，得到最终 拼上 < 60 即可： 1 如上的方法，其实就是告警引擎的核心逻辑。告警规则里会要求用户配置promql以及执行频 率，告警引擎就会根据执行频率周期性执行，每次执行的时候就是拿着promql去查询，promql 中带有阈值，即上例中的 <60，所以如果所有机器的内存可用率都很高，比如维持在80~90， 那这个promql是不会返回查询结果的，此时监控系统就认为一切正常。如果返回了结果，比如 1 2 sum by (le) (rate(http_request_duration_seconds_bucket[10m])) ) 针对分位值的计算，已经阐述清楚了，但是分位值的计算是个挺重的查询，可能会把后端时序库 打爆，所以很多公司可能在业务埋点SDK中不提供histogram这种方式，只提供summary方 式。 所谓的summary，也是prometheus的一种埋点数据类

事件 ONCALL 中心建设方法 一站式处理值班 OnCall，智能降噪 北京快猫星云科技有限公司 前言 市面上有众多监控系统，刨去商业软件不说，开源的就有 Nagios、Zabbix、Open-Falcon、 Nightingale、Grafana、Prometheus、Elastalert 等等，还有云厂商提供的监控系统，比如华为云的云 监控、腾 员，我们应该怎么处理？我的建议是分产品线统计一个指标：“Runbook 预置率”，就是各个产品线有 多少告警规则配置了 Runbook，有多少没有配置，这个比例要统计出来，然后做成红黑榜，让大家去治 理，治理一段时间之后有经验了，知道预置率大概在一个什么范围是合理的，然后就可以要求大家至少达 到预置率下限的值。否则，就一定是有问题的。 Runbook 这个配置原则，是我最为推荐的 3、根据时间 + 文本相似度做收敛 文本相似度需要引入算法，但是算法总得有个规律，我们很想把某个故障相关的告警聚拢到一起，但是显 然，很难有个行之有效的规律，没有规律的算法效果自然好不到哪儿去。 既然没办法把告警自动收敛成故障，那就手工来做。一个故障关联的关键告警，还是相对容易区分的，只 要把关键告警关联到故障，后续基于这个故障做协同就可以了。所谓协同，一个是信息同步、协同处理，