梁梁晓聪 • 2015年年加⼊入B站 • devops • 热爱新技术,热爱开源 • ⼩小宅男 故事的开始 B站炸了了.舆情监控(括弧笑脸) 我们的挑战 • 技术栈多 • 产品模块复杂 • 业务爆发式增⻓长 • 运维要求⾼高 当前情况: • 覆盖率低 • 误报，漏漏报多 • 告警⻛风暴暴 监控问题爆发: 重新定义的监控系统 ✦ 完整的监控体系 ✦ 科学的告警策略略 filter数据 精度降低 建议 降低使⽤用成本 agent prometheus target target target alert_manager 告警平 服务 cache db平台 rms资 外围系统 监控⽬目 规则⽣生 告警规 api 规则管理理 获取监控⽬目标 IDC_1 agent prometheus target target target IDC_2 获取监控数据 获取监控数据 推送告警 降低使⽤用成本 agent prometheus target target target alert_manager 告警平 服务 cache db平台 rms资 外围系统 监控⽬目 规则⽣生 告警规 api 规则管理理 获取监控⽬目标 IDC_1 agent prometheus target target target IDC_2

发现一些不同的线索，需要及时同步给所有相关的人，这个 时候就可以在故障下面添加评论，其他人就可以及时看到。等到止损之后，大家还要根据故障时间线复 盘，产出一系列跟进项，这个时候就需要这个故障管理模块具备跟进项管理的功能，或者至少能够跟任务 管理系统良好打通。 有了这样一个故障协同的机制之后，故障被处理掉的概率就大幅提升了，后续再配合一些运营统计手段， 统计各个团队的平均故障止损时 效得多。 如上，是从思路方法层面，对事件的处理做了逻辑讲解。要求所有的监控系统实现这些能力不太现实，而 且会造成一个一个的事件孤岛，所以典型的做法是把所有监控系统生成的事件统一聚合到一个平台来处 理，这就是 OnCall 中心，下面我们以 FlashDuty 来举例，讲解 OnCall 中心的工具实践。 工具实践篇 称手好用的工具是可以大幅提升效率的，同时，好的工具可以沉淀最佳实践，沉淀经验，假设由你来设计

ation_seconds_bucket[10m])) 上面的例子，是会对每个请求分别做计算，假设有两个模块：n9e-proxy、n9e-webapi，都统 计了 http_request_duration_seconds_bucket ，我们可能希望以模块为颗粒度，分别计算每 个模块的90分位延迟，写法是： histogram_quantile( 0.9, sum by (job, le) (rate(http_request_duration_seconds_bucket[10m])) ) 注意，这里通过job标签来区分模块，le是计算histogram_quantile必须的，所以也要放到sum by后面，如果我们要计算全部数据的90分位值呢（虽然这大概率是个伪需求）？ histogram_quantile( 0.9, 1 2 3 4 5 1 2

夜莺介绍：国产开源监控系统 第三部分 国产开源监控产品相对比较匮乏，夜莺希望重新定义国产开 源监控，支持云原生监控，经受了滴滴大规模生产检验 Nightingale 夜莺是新一代国产智能监控平台，既可以解决传统物理机虚拟机的场景，也可以解 决容器的场景。衍生自Open-Falcon和滴滴Odin监控，经受了包括小米、美团、滴滴 在内的数百家企业的生产环境验证，简单可依赖，好用到爆！ 3500+