B站的日志系统

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

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

原有日志系统

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

  1. 方案各异。 由于各个部门自行实现日志方案,没有专人维护,普遍存在维护成本高、系统不稳定、丢日志、易用性不足的情况。
  2. 业务日志没有统一的规范。业务日志格式各式各样,导致最直接的问题就是无法按照统一的规则对日志进行切分,这无疑大大的增加了日志的分析、检索成本。
  3. 对PAAS支持不好。公司内部正在大面积推广应用容器化,但是并没有一个好的日志方案支撑容器内应用日志的采集。
  4. 日志利用程度低。对于日志的利用程度普遍停留于日志检索的水平,受限于工具未对日志的价值进行进一步挖掘,例如:日志监控、统计分析、调用链分析。
针对上述问题,提出新的日志系统的设计目标如下:
  1. 业务日志平滑接入:业务日志接入日志系统,只需要进行简单的配置;日志平台也只需要进行一些基本的配置,无须涉及日志内容等业务信息。
  2. 多样性支持:环境多样:物理机(虚拟机)、容器;来源多样:系统日志、业务日志、中间件日志……;格式多样:单行/多行, plain/json。
  3. 日志挖掘:快速可查,日志监控,统计分析。
  4. 系统可用性:数据实时性;丢失率可控(业务分级、全链路监控)。
Billions的演进

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

格式要求:

必须包含四类元信息:

  1. time: 日志产生时间,ISO8601格式
  2. level:日志等级, FATAL、ERROR、WARN、INFO、DEBUG
  3. app_id:应用id,用于标示日志来源,与公司服务树一致,全局唯一
  4. instance_id:实例id,用于区分同一应用不同实例,格式业务方自行设定
  5. 日志详细信息统一保存到log字段中。
  6. 除上述字段之外,业务方也可以自行添加额外的字段。
  7. 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}

日志系统技术方案

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

日志采集

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