B站统⼀一监控系统的设计,演进 与实践分享 梁梁晓聪 devops @lxcong About Me • 梁梁晓聪 • 2015年年加⼊入B站 • devops • 热爱新技术,热爱开源 • ⼩小宅男 故事的开始 B站炸了了.舆情监控(括弧笑脸) 我们的挑战 • 技术栈多 • 产品模块复杂 • 业务爆发式增⻓长 • 运维要求⾼高 当前情况: • 覆盖率低 告警规 api 规则管理理 获取监控⽬目标 IDC_1 agent prometheus target target target IDC_2 获取
 监控⽬目标
 告警规则 web push rule push rule 获取监控数据 获取监控数据 推送告警 降低使⽤用成本 agent prometheus target target target alert_manager 告警规 api 规则管理理 获取监控⽬目标 IDC_1 agent prometheus target target target IDC_2 获取
 监控⽬目标
 告警规则 web push rule push rule 获取监控数据 获取监控数据 推送告警 1. 降低编写规则的成本 降低使⽤用成本 agent prometheus target target

监控痛点：全面完备、跨云 02 夜莺介绍： 国产开源监控系统 03 夜莺设计实现：Agentd 数据采集 04 夜莺设计实现：Server 数据处理 05 夜莺设计实现：技术难点及细节 06 运维监控需求来源 第一部分 如果贵司的业务强依赖IT技术，IT故障会直接影响营业收入， 稳定性体系一定要重视起来，而监控，就是稳定性体系中至 关重要的一环 运维监控需求来源 01.监控的原始需求来自业务稳定性 01.监控数据采集，all in one的agentd Agentd 进程存 活 端口监 控 插件脚 本 日志监 控 网络设 备 中间件 类 数据库 类 • 支持在web上配置采集策略，不同的采集可以指定 不同的探针机器、目标机器，便于管理和知识传 承 • 独创在端上流式读取日志，根据正则提取指标的 机制，轻量易用，无业务侵入性 • 内置集成了多种数据库中间件的采集以及网络设 write 夜莺Server数据处理 06. data - read 夜莺Server数据处理 夜莺设计实现 技术难点及细节 第六部分 0１. 规则集中化管理及自动发现 夜莺 技术难点及细节 0２. 采集器 夜莺 技术难点及细节 0２. 数据序列化及传输问题 夜莺 技术难点及细节 Thank you

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 函数非常多 大概是： (20-10)*(50/150)+10=13s 这是假设数据是均匀分布在各个桶的，假设10~20那个桶的150个请求，最大延迟的那个请求， 其延迟数据是11秒，而这里算出13秒，显然与现实不符，不符也没办法，这本来就是个预估 值，知道大概数量级就可以了，还是那句话，监控数据是采样数据，这么计算虽然不是那么准 确，但是成本低。 实际上，我们基于某个指标的历史所有数据计算分位值，意义不大，通常我们是基于最近一段时

用钉钉发送，会呈现为一张告警消息卡片： 我们可以直接在钉钉（或飞书、企微等 IM）内部点击跟进，或直接关闭、临时屏蔽，方便地移动办公。 当然，也可以登录 FlashDuty，在 WEB 上查看，需要有个非常直观的页面告诉用户您当前有哪些告 警，分成了几类，每一类有多少条之类的。 告警/故障查看 OnCall 中心需要对接各类监控系统，同一时间可能会有很多告警事件发到