bilibili 屠辉:海量监测平台的演进之路

阅读数:60 2019 年 10 月 9 日 10:55

bilibili 屠辉:海量监测平台的演进之路

七牛云架构师实践日南京站于 11 月 9 日在南京成功举行,以「大数据技术的实践与分享」为主题,邀请了多名业内大咖,为大家带来了精彩演讲。bilibili 的架构师屠辉,在会上作了题为《海量监测平台的演进之路》的分享。

以下内容为根据现场演讲内容速记的实录整理。

各位下午好!我叫屠辉。目前在 bilibili 担任基础平台的架构开发。在加入 bilibili 之前,曾在京东担任 APM 平台和公网链路探测的架构开发。

今天我分享的主题是《海量监测平台的演进之路》。首先介绍一下 bilibili,我想在座的应该都很熟悉,有大量年轻人喜欢在我们的平台上发布视频。而我们的监测平台,具有平台化、数据化、自主化、全局性和定位性这样的特点。

bilibili 监控系统的演进阶段

首先,我来介绍一下 bilibili 的监控系统,在演进过程中存在的几个阶段。

人肉堆积阶段

因为 bilibili 的监测系统起步较晚,从 2015 年才有第一名运维人员入职。之前都是处在一个人肉运维的堆积阶段,这是比较原始的,这些监测系统基本上就是八仙过海各显神通,所有数据都分布在一个个孤岛上面,没有统一的整合。

监测系统的平台化建设

大概从 2016 年开始,在意识到之前分散的系统是无法整合之后,我们开始注重监测系统平台化建设。我们开始了新一代 B 站的系统研发,把一些纷乱复杂的系统去除,选用 PROMETHEUS 系统作为我们的基础。

监测数据的分析和统计

第三个是用监测系统做分析,对之前割裂的信息进行空前的聚合,我们可以基于这些海量的数据做大数据分析,例如对容量的动态扩速容的评估。

研发和运维共同合作阶段

第四个阶段是研发和运维合作的阶段。把研发和运维密切结合起来,PROMETHEUS 的特性是可以从研发侧接入到运维的监控平台,提供有力保障,可以用不同的开发语言来作为买点。

站点可靠性建设

第五个阶段是可靠性建设。首先说一下 B 站监测平台的动向覆盖,bilibili 分为两个视角。一个是用户的视角,比如说用户的视觉感观有卡顿,从运维上可以反映出一些奇怪的问题。我们需要从中介入,找到问题的根源。另外一个视角,就是运维侧发起的监控需求。两边同时往中间演进,中间有一些中间件,比如说应用程序买点和其他系统监测,达到一个纵向的覆盖。

bilibili 屠辉:海量监测平台的演进之路

在 2016 年之前,因为 B 站都是用拉维克斯(音),只能做一些基础监控,像 CPU 、内存等,对于研发的接入成本是比较高的。所以我们的监控覆盖率就只有大概在 30% 左右,很多业务上的运维都是独立的。比如说有一些弹幕系统,运维部这边是完全没有感知的。

经过大概一年的时间,我们从 2017 年下半年开始对整个系统进行重构,我们用一个比较通用的模式来进入到监控平台,基本上是基于 PROMETHEUS 的二次开发,把它埋在一个公共框架里面。到了 2018 年我们的监测覆盖率大概可以达到 90% 。我们的愿景是最终达到 100% 的可以横向监控覆盖率。

下面我来说一下,建设海量指标的监测平台需要什么。目前 bilibili 的监测是分为两个团队两个技术站,我所在的主要是基于度量值的监控平台。

首先是多样化自主接入。不仅局限在网络监测,而且从不同的角度来洞悉全局,我们需要一个可靠的数据采集系统。

第二个是各个指标的灵活配置。监测指标全部接进来之后,每种指标的配置规则是不同的。相对来说就是纷乱复杂,无法达到一个有机的整合。

第三个是监测指标可视化。把海量的监测指标有机结合起来,针对某个系统来进行一个集中展示。例如我们对直播的监控,可以统计在线人数,用不同的活动页来展示,这样我们可以针对一个特殊的场景来解决问题,例如每半年季的活动。

第四个是告警的调用链和洞悉全局。像我个人每天可能要收到 4000 多条的告警消息,当然不可能一一看过来,所以说我们如何把一些关键的消息在最关键的时刻推送给关键的人,这是比较重要的问题。

整个系统重构之后发生了什么?

bilibili 屠辉:海量监测平台的演进之路

我们系统从选用 PROMETHEUS 之后,我们的数据采集量从原来的 30% 到目前翻了 20 倍。因为 bilibili 的业务比较复杂,有一些海外业务,包括在台湾、日本,包括在欧洲、美洲都有一些节点,我们的服务器是比较分散的。这就无法满足我们的监测需求,所以说我们必须采用分布式场景来做。当然网络监控目前也是统一到 PROMETHEUS 这边来。

这里就介绍一下我们的可视化监测平台。我们把所有的服务器和应用都挂在一个服务器上,从部门级别分散到应用级别,每个应用级别都有自己对应的系统。我们的监测系统不会直接把告警人写在里面,包括监测系统的规则配置等所有系统,都和这个平台关联起来,这样可以看到,主机名和一些规则配置都是基于我们这个概念来做的。

bilibili 屠辉:海量监测平台的演进之路

这是我们的监测平台事件中心。对每天产生的事件,有告警认领和简单统计的功能,你可以对告警屏蔽一段时间甚至进行进一步操作。当然每个告警都有它的级别,不同的级别告警频率也是不同的。目前来说,我们定了五个级别。比如 P0 级会通过电话、短信、企业微信三个渠道发送到具体接收人。P1 级别可能只有短信和企业微信,而 P2 级别,是目前最多的,一般来说都是通过企业微信来发送。P2 以下的 P3、P4、P5 都是通过邮件来发送。因为有些告警并不是致命性的问题,所以说我们会在周末对它进行静默。因为告警太多,所以说很多运维人员不想在周末接收到这种非致命性告警,所以我们在周末会把一些级别下调,调到 P3 左右。这里可以看到,每天的告警量最高在 2000 左右,平均一天大约在 1500 条左右。

bilibili 屠辉:海量监测平台的演进之路

这是我们可视化的监测平台 METRIC 管理。在用了 PROMETHEUS 以后,我们原则上不添加新的 METRIC,不同的 METRIC 之间肯定是不到 1000 个,包括一些中间的,还有一些个性化的埋点。

bilibili 屠辉:海量监测平台的演进之路

这个是我们的可视化监测平台。其中定制化的不多,稍微改了一些界面。

bilibili 屠辉:海量监测平台的演进之路

这是可视化的监测平台中的告警配置。我们目前的告警可视化后端,都是 PROMETHEUS。下面是它的查询语句呈现出的图形,上面是一些筛选的条件。

bilibili 屠辉:海量监测平台的演进之路

这是我们可视化监测平台的首页。其中包括时钟、基础监测,以及网络方面的信息。它是分几个级别,包括基础侧、中间件、应用侧,是我们根据主站的调用关系、外部链路的首超时、冗段这些数据,来进行不同的级别分层。目前我们所有的监控平台都是基于这个来做的。

下图是监控模板和它的一些配置,主要是数据的展示。

bilibili 屠辉:海量监测平台的演进之路

下图是我们的汇总,它可以看到每台机器的 QPS,找到一些关键的指标和相关的负责人。

bilibili 屠辉:海量监测平台的演进之路

与很多互联网公司不同,bilibili 采用的是一个大运维体系。从 2015 年做运维开始,我们所有的监控都是统一的整合,很多都是研发提供给我们的。所以我们来比较了解一下,研发大概需要什么样的运维监测系统。

  • 海量数据检索能力

不管是基础监控,还是研发埋点的上报数据,都需要一个统计的数据检索,这个 PROMETHEUS 就完全能满足需求。

  • 故障的发现能力

因为研发的所有数据都已经上报了,研发这一侧完全没有监控能力。所以整个监控的压力全部压在技术平台这边,所以我们对每一个监控都要有及时发现的能力,把它反馈给研发。

  • 高度自由化的系统

作为一个平台建设者,我们的系统并不处在人肉运维的阶段。比如配置一个复杂的告警,每天可能有十几个研发从早到晚找你,并不能够满足大量的需求,所以说我们需要一个高度自由化的系统。

目前来说,我们这一块做得还是不够。因为这里所有都是基于 PROMETHEUS 来做的,就无法满足如计算冗段的值数据复杂的一些复杂场景。如何解决这个问题,当然会成为我们今后工作的重点。

  • 使 SRE 的落地成为可能

因为 bilibili 是主推 SRE 的,目前公司有大概十个平台全部是做这个的,所以站点可靠性建设是一个长期的过程,光靠运维或者研发一方的各自努力是不行的,必须进行合作共赢,需要一个大强度的整合。

挡在我们新一代监测系统之前的几座大山

第一座大山 - 配置复杂的问题

尽管 PROMETHEUS 提供一个很强大的查询系统,但有一定的学习成本,如果有相对复杂的告警配置,一般需要专业的工程师才能完成,无法完全下放研发。

第二座大山 - 平台的扩展能力

原生的 PROMETHEUS 并没有很好的企业级解决方案,并且不支持集群化,所有都分散在各个机房,PROMETHEUS 的机房也比较复杂,首先有 IDC,也有海外的公有云和自己的私有云,基本上是一个混合云的架构。所以说我们的 PROMETHEUS 不支持集群化方案,我们必须在不同的环境去部署 PROMETHEUS,每台系统之间都是无法有效集合在一起。也就是你要查一个数据,可能首先要知道这个数据在哪个云上,业务在哪里,才能查询到,所以说这是一个比较麻烦的问题。

第三个座大山 - 告警的智能化

这个问题主要是如何应对告警公报。如果每天收集到 4000 多条消息,这些消息是完全没有价值的,你根本不可能一条条看过来。我们目前是采用一个打标签的方式,也在研究一些机器学习的算法,来把它应用到一个告警平台里面去,可以对相同内容的告警进行一些智能的聚合。

配置 18000 行监测告警的痛苦

在这种情况下调配,我们一般来说是安排两个运维工程师坐班不停地跟研发配告警规则,如果是相似的可以做到一些程序化,如果有一些特殊的需求就无法满足了。

bilibili 屠辉:海量监测平台的演进之路

告警配置自主化下放是目前我们是和友商合作进行的,对我们所有的配置文件进行图形化的配置,可以基于一些标签,用服务器进行筛选,然后对服务进行筛选。因为所有的监控都在我们这边,所以说你们会看到形形色色的监控。

原生的 PROMETHEUS 是不支持告警的,如果这边告警断了以后你是无法察觉到,就是你告警是完全报不出,你不知道它的数据。这边是一个配置,就是把所有的配置做成图形化。

目前我们把这些配置下到研发,大概有 300 多个研发,完全让他们自主化配置,可以对它进行一些静默操作。

下图是一些复杂告警配置。比如说一个主站的监控,可能要监测到设备耗时,是一些第三方组件的耗时,所有的服务都是在我们这个平台上托管。等于我们现在把所有的监控通过这个平台下放给研发,让研发可以自主配置。

bilibili 屠辉:海量监测平台的演进之路

下图是一个复杂告警配置。像这样的语句是计算 HTDP 错误码占比,正常情况下应该是有一定比例的,当超过一定的比例以后我们就要发出告警。假如你要写 PROMETHEUS 的告警语句,是相当复杂的,如果你是没有受过专业学习的普通研发,可能这个语句都写不了。所以说我们目前会有一个运维人员把具体的语句写好,再在平台上创建一个指标,普通的人只要针对这个指标过滤一些方法、UIL,来决定到底哪个 UIL 需要报警。用这样的方法,就解放出我们很大的工作量。

bilibili 屠辉:海量监测平台的演进之路

下图是我们 PROMETHEUS 的企业解决方案。这可以基本上把挡在我们面前的三座大山解决,可以提高我们研发 PROMETHEUS 的很多潜力,包括一些告警策略可视化、监测指标白名单等等都是可以完善的。

bilibili 屠辉:海量监测平台的演进之路

针对告警配置无法下放和 PROMETHEUS 的企业平台化问题,我们通过和 OPSMIND 合作,使得 bilibili 基于 PROMETHEUS 的企业级监测方案获得了很大的提高,成功缩减了人力成本,提升了平台的交付能力,同时也夯实了间系统的工程强度,为后续基于监测数据大数据分析和 AIOPS 的实施提前扫清了障碍。目前使用 11 台服务器分布式环境承载 1 亿条时序指标,成功解决了原有系统的性能和容量问题,将两名配置专员从日常的机械性工作中解放出来。

原来 PROMETHEUS 一个简单的告警可能要反复写,目前通过抽象以后,可以把原来 10 万行的告警配置通过优简化大概到 300 条左右,因为这些都可以通过标签来选择了,而不需要创建新的,这样就降低我们维护的劳动成本。平均每天我们需求方之前大概需要 120 人次,由人力输出变成一个服务型输出,响应时间也大大缩短。

下图是 PROMETHEUS 的整合方案。我们的数据通过不同的结构上报到 PROMETHEUS 以后,会有一些自己的外部系统来进行 PROMETHEUS 的数据展示。同时这是一个双写过程,把这个数据拷贝一份,上到我们 PROMETHEUS 平台,和外部系统的一个展示功能,通过这边可以做一些告警。对整个系统是无损的,对我们架构来说用不着太大的改进。

bilibili 屠辉:海量监测平台的演进之路

海量监测平台的建设任重而道远,我觉得可以分为下图所示的四个阶段。

bilibili 屠辉:海量监测平台的演进之路

首先是初级阶段。B 站的运维起步比较晚,从 2015 年开始,所以很长一段时间我们都是处在初级阶段。

入门阶段是 2015 年到 2017 年之间,通过整合所有监测系统,引入 PROMETHEUS 监测方案来统一。目前我们通过和友商的合作,把一个复杂的告警配置完全下放,我们自身只是专注于平台化建设。例如海量的 PROMETHEUS 探测目标的管理。

接下来是高级阶段。我们目前所用的,都是一些业务系统上淘汰下来的,所以说高可用的几乎没有。做好平台的高可用、消除单点故障,是这个阶段的关键。一个机房可能只有一台 PROMETHEUS ,如果一个挂了,整个机器在监控平台机房就会挂掉。一旦发生了致命性故障,其实并不会影响到生产系统,所以说随着我们的数据不断接入,我们的重要性越来越高,我们需要一个高可用消除单点故障。

最后是一个智能运维阶段。因为监控本身是有规律的一些数据,我们可以基于这些做一些大数据分析,进行一个整合,这样我们就可以从繁重的劳动中解脱出来。

以上就是我演讲的全部内容,谢谢大家!

作者介绍:
屠辉,拥有 10 年以上运维经验,现任哔哩哔哩基础平台架构师。

本文转载自公众号七牛云(ID:qiniutek)。

原文链接:

https://mp.weixin.qq.com/s/SQMuNgBdeKzxd6ST5xwpMw

评论

发布