B站统⼀一监控系统的设计,演进 与实践分享 梁梁晓聪 devops @lxcong About Me • 梁梁晓聪 • 2015年年加⼊入B站 • devops • 热爱新技术,热爱开源 • ⼩小宅男 故事的开始 B站炸了了.舆情监控(括弧笑脸) 我们的挑战 • 技术栈多 • 产品模块复杂 • 业务爆发式增⻓长 • 运维要求⾼高 当前情况: • 覆盖率低 告警阈值需要随着流量量变化⽽而调整 wrong 建议: 告警规则: 业务A 慢请求⽐比例例 > 80% 案例例2 告警规则: 磁盘容量量可⽤用率 <10% 告警规则: 磁盘容量量预计将于3⼩小时后饱和 0 now -1h +3h predict_linear(node_filesystem_free{}[1h], 3 * 3600) < 0 异常检测 异常流量量 abs(requests

事件 ONCALL 中心建设方法 一站式处理值班 OnCall，智能降噪 北京快猫星云科技有限公司 前言 市面上有众多监控系统，刨去商业软件不说，开源的就有 Nagios、Zabbix、Open-Falcon、 Nightingale、Grafana、Prometheus、Elastalert 等等，还有云厂商提供的监控系统，比如华为云的云 监控、腾 表，手头上的紧急事务搞定之后就去处理 Info 邮件 每天下班前稍微看一眼，偶尔一两天忘了看也无 伤大雅 另外，如果 Critical 的告警规则很多，大概率也有问题，说明系统架构不够鲁棒，出点什么事都要立刻介 入，系统没有自愈能力。这样的系统，需要配备更多运维人员，而且还很难跟老板讲清楚价值。怎么办？ 这就需要制定运维准入规则，哪个系统要交给运维人员来运维，首先要提供一些信息。 ● 相关联系人，出了问 Webhook，当告警触发之后自动回调某个 HTTP 接口，来串联一些自动化的 逻辑，让告警事件无人值守自动处理。比如某个机房的某个服务挂掉了，Webhook 的逻辑是自动调用切 流的接口，把服务流量切走，这样来达到止损的目的。 告警自动处理的这段逻辑，未必一定能够做到告警自愈，有的时候只是使用这个机制来抓现场，也是非常 有价值的。比如某个进程挂掉了，在挂掉的时候我想知道当时机器的一些运行情况，比如各项资源的占用

后一个值和第一个值做数据外 推，一些毛刺现象就会被平滑掉，如果想要得到更敏感的数据，可以使用 irate 函数。irate 是 拿时间范围内的最后两个值来做计算，变化就会更剧烈，我们还是拿网卡入向流量这个指标来做 个对比： 蓝色的更变化更剧烈的线是 irate 函数计算的，紫色的相对平滑的线是 rate 函数计算得到的。 histogram_quantile 要了解 histogram_quantile