些方面，按照一个什么方式执行动 作，应该有一个手册参考。如果告警发生之后没有后续动作，那这个告警的意义就不大了。在 Nightingale 的告警规则配置页面，可以看到一个专门的 Runbook 配置，Grafana 的告警配置页面， 也有一个 Runbook 的选项，就能看出他们对它的重视程度。 这个原则看起来是不是很合理？但是真要落地的时候，又会发现紧急需要处理的告警事件通常容易对应 聊天群组，平时都不用关注，只要 每天早上上班或晚上下班之前稍微看一眼就行，这样就可以减少打扰。 制定了这个原则之后，如果大家不遵守怎么办呢？还是有很多告警没有对应的 Runbook，作为管理人 员，我们应该怎么处理？我的建议是分产品线统计一个指标：“Runbook 预置率”，就是各个产品线有 多少告警规则配置了 Runbook，有多少没有配置，这个比例要统计出来，然后做成红黑榜，让大家去治 往上升级。 告警升级机制需要认领功能的配合，也就是一线人员收到告警之后要通过某种机制告诉系统：“我已知晓 告警，现在我开始处理了，你不要升级了”。典型的认领功能一般是做在页面上的，告警后打开告警事件 管理中心，选中相关告警一键认领，也可以通过上行短信或即时通讯工具中的上行回调机制来完成。 升级机制会给值班人员很大的压力，毕竟谁也不想稍不留神就把电话打到老板那里，所以一般只有严重的

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

进程存 活 端口监 控 插件脚 本 日志监 控 网络设 备 中间件 类 数据库 类 • 支持在web上配置采集策略，不同的采集可以指定 不同的探针机器、目标机器，便于管理和知识传 承 • 独创在端上流式读取日志，根据正则提取指标的 机制，轻量易用，无业务侵入性 • 内置集成了多种数据库中间件的采集以及网络设 备的采集，复用telegraf和datadog-agent的能力 夜莺Server数据处理 05. data - write 夜莺Server数据处理 06. data - read 夜莺Server数据处理 夜莺设计实现 技术难点及细节 第六部分 0１. 规则集中化管理及自动发现 夜莺 技术难点及细节 0２. 采集器 夜莺 技术难点及细节 0２. 数据序列化及传输问题 夜莺 技术难点及细节 Thank you