原创高效运维12-17 00:23

摘要: B站日志系统(Billions)diao在哪里?

作者简介

王翔宇

Bilibili资深运维研发工程师。曾就职于百度、饿了么,2017年加入B站,负责B站日志平台的设计和开发工作。

B站的日志系统(Billions)从2017年5月份开始建设,基于elastic stack,面向全站提供统一的日志采集、检索、监控服务。目前集群规模20台机器,接入业务200+,单日日志量10T+。

借此机会跟大家分享一些B站在日志系统的建设、演进以及优化的经历。由于经验尚少,抛砖引玉,欢迎大家一起交流讨论。文章主要分为三个部分:原有日志系统现有系统演进未来的展望

原有日志系统

在Billions之前,B站内部并没有统一的日志平台,基本是业务之间各自为战,既有基于ELK的比较前瞻的方式,又有服务器上使用tail/grep比较基本原始的方式,水平参差不齐。在了解各个产品线的情况后,存在的问题和诉求主要有以下几点:

  1. 方案各异。 由于各个部门自行实现日志方案,没有专人维护,普遍存在维护成本高、系统不稳定、丢日志、易用性不足的情况。

  2. 业务日志没有统一的规范。业务日志格式各式各样,导致最直接的问题就是无法按照统一的规则对日志进行切分,这无疑大大的增加了日志的分析、检索成本。

  3. 对PAAS支持不好。公司内部正在大面积推广应用容器化,但是并没有一个好的日志方案支撑容器内应用日志的采集。

  4. 日志利用程度低。对于日志的利用程度普遍停留于日志检索的水平,受限于工具未对日志的价值进行进一步挖掘,例如:日志监控、统计分析、调用链分析。

针对上述问题,提出新的日志系统的设计目标如下:

Billions的演进

系统的初建

日志规范

为了解决业务日志格式多样性问题,统一制定了日志格式规范,使用JSON作为日志的输出格式。
格式要求:

  1. 必须包含四类元信息:

    • time: 日志产生时间,ISO8601格式

    • level:日志等级, FATAL、ERROR、WARN、INFO、DEBUG

    • app_id:应用id,用于标示日志来源,与公司服务树一致,全局唯一

    • instance_id:实例id,用于区分同一应用不同实例,格式业务方自行设定

  2. 日志详细信息统一保存到log字段中。

  3. 除上述字段之外,业务方也可以自行添加额外的字段。

  4. json的mapping应保持不变:key不能随意增加、变化,value的类型也应保持不变。

例如:

{"log": "hello billions, write more", "level": "INFO", "app_id": "testapp111", "instance_id": "instance1", "time": "2017-08-04T15:59:01.607483", "id": 0}

日志系统技术方案

日志从产生到消费,主要经历以下几个阶段:采集->传输->切分->检索。

日志采集

日志采集针对非落盘和落盘两种方式。

日志采集

公司内部已经有了统一的数据传输平台(lancer),lancer的优势如下:

因此我们直接选择lancer作为我们的日志传输系统。

日志切分

日志切分模块的主要作用是从kafka消费日志,对日志进行处理(字段提取、格式转换),最终存储到elasticsearch的对应的index中。我们使用logstash作为我们的日志切分方案。

其中:

日志检索

elasticsearch集群规模为:master node*3, hot node*20, stale node*20,client node*2。es版本为5.4.3,集群配置如下:

经过上述步骤,最终日志就可以在kibana上进行查询。第一阶段,日志系统的整体架构为:

系统迭代

随着接入的日志量越来越大,渐渐出现一些问题和新的需求,Billions主要在以下方面进行了升级迭代。

shard管理

最初采用了es默认的管理策略,所有的index对应5*2个shard(5个primary,5个replica),带来的主要问题如下:

针对上述问题,开发了index管理模块(shard mng),根据index的历史数据量(昨日数据),决定创建明日index对应shard数量,目前策略为30GB/shard,shard数量上限为15。通过以上优化,集群shard数量降低了70%+,磁盘IO使用也更加高效。

日志采样

某些业务的日志量很大(大于500GB/day),多为业务的访问日志,对日志而言,“大量数据中的一小部分就足以进行问题排查和趋势发现”,与研发和运维进行沟通,这个观点也得到认同。
因此在数据采集源头log agent(collector模块)中增加了日志采样(log sample)功能:

针对日志量大的业务进行采样,在不影响使用的情况下,节省了大量的es资源。目前每天减少3T+的日志写入。

data node硬件瓶颈解决

晚上20:00-24:00是B站业务的高峰期,同时也是日志流量的高峰期。随着流量的增长,经常收到日志延迟的报警(日志没有及时的写入es),通过观察监控,主要发现两个现象:

通过以上现象,怀疑是SSD IO不足导致的es写入拒绝。后续对SSD进行了性能测试和对比,发现此型机器上SSD的写性能较差。为了减少SSD IO压力,我们将一部分实时写流量迁移到了stale node(stale node之前不接受实时写流量,写入压力很小),日志延迟的问题暂时得以解决。
终极解决办法:data node的机型为40 core CPU,256G内存,1T SSD+4*6T SATA,很明显此机型SSD从性能和容量上都是瓶颈,为了提升此机型的利用率和解决SSD IO性能瓶颈,最终我们为每台机器添加了2*1.2T pcie SSD,一劳永逸!

logstash性能解决

在解决了上述es写入瓶颈后,过了一段时间,高峰期日志延迟的问题又出现了。这次es并没有出现bulk request rejected的问题。 从整条链路进行排查,日志收集和日志传输上都没有出现日志延迟的现象,最终把注意力放在了日志切分模块(logstash)。

logstash性能差是社区内公认的,进一步针对logstash进行性能测试,在(2 core+4G memory)情况下,不断调整worker数量和pipeline.batch.size, 极限性能为8000qps,性能的确很差,高峰期的流量为40W/s, 因此至少需要50个logstash实例才能满足要求,显然这样的资源消耗无法接受。考虑到业务日志对应的切分功能较为单一,因此我们使用go自研了日志切分模块(billions index)。

自研的模块性能有了很大的提升,2 core+4G memory条件下,极限性能提升到5w+qps,并且内存只消耗了150M。 线上的资源消耗从(2 core+4G memory) 30 减少到了(2 core+150M memory)15,性能问题也得到解决。

日志监控

随着越来越多的业务的接入,日志监控的需求越来越强烈。目前社区的解决方案中,Yelp的elastalert最为成熟,功能丰富,并且也方便进行进一步的定制化。因此我们选择基于elastalert实现日志监控。
结合自身需求,通过查看文档和阅读代码,elastalert也有一些不足之处:

针对上述不足和自身需要,我们对于elastalert进行了二次开发:

主要的改进点包括:

日志监控1.0目前已经投入使用,并且还在持续迭代。

最新Billions的架构如下:

现有问题和下一步工作

目前日志系统还存在很多不足的地方,主要有:

上述不足之处也是下一阶段我们着重改善的地方。除此之外,基于es强大的检索和聚合分析功能,日志更深层次的价值挖掘也是我们探索的方向。我们需要努力的地方还有很多,期待和社区中的伙伴们有更深层次的沟通交流!

END



更多相关文章阅读

民生银行:我们的 ELK 日志分析平台

有一种能力叫 运维

微信月活9亿的高效运维之路

从鹿晗恋爱事件看运维的节假日准备工作

Linux Bash 提示符的一些骚操作

六个人如何运维一万台服务器?

运维需要懂的那些安全技能

运维的耻辱感


监控系统设计哪家强?

来 GOPS2017·上海站

来自 Bilibili 的梁晓聪老师即将带来精彩演讲

《B站统一监控系统的设计,演进与实战》


点击阅读原文关注大会官网