B站统⼀一监控系统的设计,演进 与实践分享 梁梁晓聪 devops @lxcong About Me • 梁梁晓聪 • 2015年年加⼊入B站 • devops • 热爱新技术,热爱开源 • ⼩小宅男 故事的开始 B站炸了了.舆情监控(括弧笑脸) 我们的挑战 • 技术栈多 • 产品模块复杂 • 业务爆发式增⻓长 • 运维要求⾼高 当前情况: • 覆盖率低

metric的标签可能并非完全一致，不过好在二者都有个instance标签，且相同instance标签的数 据从语义上来看就表示一个实例的多个指标数据，那就可以用on关键字，指定只使用instance 标签做匹配，忽略其他标签。 与on相反的是ignoring关键字，顾名思义，ignoring是忽略掉某些标签，用剩下的标签来做匹 配。我们拿 Prometheus 文档中的例子来说明： ## example series m ouse"}) 1 2 3 4 1 2 另外，我们有时会有分组统计的需求，比如我想分别统计clickhouse和canal的机器的内存可用 率，可以使用by关键字指定分组统计的维度（与by相反的是without）： avg(mem_available_percent{app=~"clickhouse|canal"}) by (app) 函数 Prometheus 函数非常多 increase，无非就是最后一个值减去第一个 值，即965323899880-965304237246=19662634，很遗憾，实际结果是23595160.8，差别 有点大，显然这个直观理解的算法是错的。 实际上，increase 这个 promql 发起请求的时间是1661570909，时间范围是[1m]，相当于告 诉Prometheus，我要查询1661570849（16615709

中的告 警和故障建立完美的对应关系，不过从降噪收敛角度来看，够用了。 3、根据时间 + 文本相似度做收敛 文本相似度需要引入算法，但是算法总得有个规律，我们很想把某个故障相关的告警聚拢到一起，但是显 然，很难有个行之有效的规律，没有规律的算法效果自然好不到哪儿去。 既然没办法把告警自动收敛成故障，那就手工来做。一个故障关联的关键告警，还是相对容易区分的，只 要把关键告 告警聚合 事件到告警的聚合比较容易，通常是用类似下面的算法来计算不同事件的关联关系： hash(32 + ["__name__=cpu_usage_idle", "host=host1"]) 这个值姑且称为事件 Hash，相同 Hash 的事件就被聚合为一条告警。更复杂的是告警到故障的合并，当 前我们支持基于规则的聚合，后面会基于算法聚合： 比如基于告警规则标题做聚合，某一时刻，基础网络故障，有