海海量量监测平台的演进之路路 平台化数据化 自主化全局性定位性 ç
的监测系统的演进经过如下 几个阶段 人 肉堆积阶段 监测系统的平台化建设 监测数据的分析和统计 研发和运维共同合作阶段 站点可靠性建设 1. 人 肉堆积阶段 - 采 用 比较原始的模式, 例例如系统监测采 用 Zabbix, 网络监测采 用 Cacti 等, 八仙过海海各显神通, 所有的数据都是 一个个海海上孤岛 2. 平台化建设 - 当意识到以上问题时, 开始了了 B 站新 一代监测系统的平台化建设, 首先是去 ZC, 把整个监测系统的技术栈统 一到 Prometheus 3. 监测数据的分析和统计 - 当数据汇总以后, 很多之前割裂的信息达到空前的整合, 可以基于海海量量的监测数据进 行行 大数据分析, 例例如容量量评估等 4. 研发和运维共同合作阶段 - 把研发和运维有机的结合在 一起, 因为统 一了了技术栈, 而 Prometheus 的技术特性天 生为研发帮助运维改进系统可靠性提供的有利利的保障, 可以 用不不同开发语 言来进 行行埋点, 上报各种个性化的监测需求 5. 站点可控性建设 - 因为有了了强 大监测系统, 便便可以洞洞悉整个站点, 使 SRE 成为可能 2
监测平台的纵向覆盖 3
监测平台的横向覆盖 2016 30% 在采 用 Prometheus 来重构整个 B 站监测系统之前 大约只能做到 30% 左右的横向覆盖, 因为 高昂的系统接 入成本让很多业务 无法 自已接 入, 需要 高度的定制化开发才 行行, 所以横向覆盖有限 2018 90% 2017 年年下半年年对整个系统进 行行了了重构, 统 一了了技术栈, 各个业务系统可以使 用 比较通 用的模式接 入到监测平台, 从 而使得接 入成本 大 大降低, 目前的系统覆盖度 大约有 90% 左右 ç 100% 愿景则是最终可以达到 100% 的横向监测覆盖 4
建设海海量量指标的监测平台我们需要什什么? 多样化的 自主接 入 各个指标的灵活配置 01 接 入的数据将不不再只局限于基础监测, 网络监测, 而且从不不同的 角度来洞洞悉整个系统, 那么你就需要 方便便可靠的监测数据采集系统 02 监测指标海海量量以后随之带来的则是配置问题, 不不同的监测指标有不不同的度量量值, 不不再是以前简单的逻辑运算, 会变得相当复杂 监测指标的可视化 告警的调 用链, 洞洞悉全局 03 把海海量量的监测指标有 几的结合起来, 针对某个系统来进 行行集中的 Dashboard 展示, 或者是详尽的可视化的问题排查 04 为了了避免告警 风暴暴, 让最有价值的告警信息出现在最关键的时刻, 需要各个指标之间能互相调 用, 通过 比较分析发出最准确的告警信息 5
BIILIBILI 基础 监测指标数量量的成倍增 长 30% 985% 迁移到 PROMETHEUS 后发 生了了什什么 20 倍 由于之前 Bilibili 的监测系统是采 用的 Zabbix 和 Cacti 的 方案, 其中 Zabbix 用来监测基础的系统信息, 例例如 CPU, 磁盘, 内存等,Cacti 用来监测 网络带宽流量量等, 监测的指标数相当有限 当更更换为 Prometheus 后, 因为有其强 大的多语 言 SDK 支持, 以及 非侵 入式的监测数据采集 方案, 得以 大量量的业务监测数据接 入进来, 使得整个 Metric 度量量值指数级别增 长
可视化的监测平台 7
可视化的监测平台 - 事件中 心 8
可视化的监测平台 -METRIC 管理理 9
可视化的监测平台 10
可视化的监测平台 11
可视化的监测平台 12
可视化的监测平台 13
可视化的监测平台 - 数据统计 14
海海量量数据检索能 力力不不管是基础监测, 还是研发侧埋点上报的度量量值, 都要有统 一的数据结构 用来存储, 我们这 里里采 用Prometheus 的时序数据库 故障的发现能 力力有了了海海量量的监测数据但是并不不能把关键的告警遗漏漏, 如何解决 狼来了了 的问题, 将数据有机的结合是平台建设的关键 研发需要的运维监测系统 使 SRE 的落地成为可能站点可靠性建设是 一个漫 长的过程, 光靠运维或者研发 一 方的各 自努 力力是不不 行行的, 只有合作共赢, 一起推进才有可能 高度 自由化的系统作为平台建设 方, 我们提供 高度 自由化的监测告警配置和可视化平台配置提供给整个研发部 门使 用 15
挡在新 一代监测系统之前的 几座 大 山 30% 配置复杂的问题 30% 平台的扩展能 力力 30% 告警的智能化 尽管配置很强 大, 但因为太过于灵活, 有 一定的学习成本, 如果有相对复杂的告警配置, 一般需要专业的 工程师才能完成, 无法完全下放研发 原 生的 Prometheus 并没有 一个很好的企业级解决 方案, 并且不不 支持集群化, 所以扩展和维护是 一个很 大的问题 如何应对告警 风暴暴, 对告警进 行行智能收敛也是我们 目前存在的问题, 目前采 用打标签的 方式, 未来需要引 入机器器学习对内容进 行行智能收敛 16
感受 一下配置 18000 行行监测告警的痛苦之处 17
告警配置的 自助化和完全下放 18
复杂告警配置的的可视化 19
复杂告警配置的的可视化 20
通过引 入 PROMETHEUS 的企业级解决 方案使得挡在我们 面前的三座 大 山得以可以跨 管理理能 力力 告警策略略可视化配置监控指标 白名单 大屏 exporter 自动发现监控指标可视化分布式存储告警发送 告警 ack 时序存储 Prometheus 指标采集 多机 高可 用代码级定制 原 生 Prometheus OpsMind + Prometheus 吞吐能 力力 1000 万 / 秒 数亿 / 秒 分布式存储 无 支持按 metric + time 监控指标管理理 无 有 数据查询 PromQL 可视化界 面 大屏 Grafana Grafana DataV 告警策略略 YAML 配置 文件 自助化配置 告警微调 不不 支持 支持 告警合并 不不 支持 支持 容量量 * 数据保留留 3.5 月 数据 无限时 长保留留 原 厂维保 定制化开发 无 有 工程强度 21
所以针对告警配置负责 无法下放, 和 PROMETHEUS 的企业平台化, 目前我们通过与 OPSMIND 合作, 使得 基于 PROMETHEUS 的企业级监测 方案获得了了很 大的提 高, 成功缩减了了 人 力力成本, 提升了了平台的交付能 力力, 同时也夯实了了监控系统的 工程强度, 为后续基于监测数据做 大数据分析和 AIOPS 的实施提前扫清了了障碍 1 亿 2 人 300 条 120 人次 1 分钟 使 用 11 台服务器器的分布式环境承载 1 亿条时序指标, 成功解决了了原有系统的性能和容量量问题 将 2 名配置专员从 日常的机械性 工作中解放出来 导 入 10 万 行行告警配置, 通过优化简化到 300 条主告警条 件和数千条告警微调, 大 大降低了了维护系统的劳动成本 平台每天由需求 方 自助使 用 120 人次, 成功由 人 力力型输出转为服务型输出 需求响应时间由 1 小时缩短为低于 1 分钟, 需求 方满意度 大幅提升 22
整合 方案采 用 无侵 入的 方案, 对系统本身 几乎没有侵 入性 Grafana API 级兼容 OPSMIND alert manager k8s 外部系统 remote_write remote_write remote_write CMDB Prometheus-1 Prometheus-2 exporters targets 23
海海量量监测平台的建设任重 而道远 04 03 02 01 初级阶段 入 门阶段 高级阶段 智能阶段 初级阶段 入 门阶段 高级阶段 智能阶段 B 站的运维建设起步较晚, 从 2015 年年开始只有第 一名专职运维 入职, 所以很 长的 一段时间都是运 行行在监测平台的初级阶段 通过整合所有监测系统, 例例如从同 一技术架构, 抛弃原有的 Zabbix 和 Cacti 因为其缺乏灵活性, 而且当业务海海量量增 长时整个系统已经不不堪重负, 对研发测的业务接 入成本也很 大, 引 入了了 Prometheus 的监测 方案来统 一 我们 目前通过和 Opsmind 的合作也刚刚踏 入这个阶段, 通过把复杂的告警配置完全下放, 自身专注于做平台化建设, 例例如海海量量 Prometheus 监测 目标的管理理, 注重平台的 高可 用, 消除单点故障, 使整个监测系统成为 B 站运营体系 里里的云之基 石 智能故障判断, 故障 自愈则是运维系统的 高级阶段, 机器器学习其实是运维故障处理理的 一个很好的落地点, 只要做到所有的故障都有迹可循, 则智能运维将成为可能, 也是我们未来 工作的重点 24
谢谢