自动化运维、大数据、Docker

B站日志系统

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

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

原有日志系统

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

  1. 方案各异。 由于各个部门自行实现日志方案,没有专人维护,普遍存在维护成本高、系统不稳定、丢日志、易用性不足的情况。
  2. 业务日志没有统一的规范。业务日志格式各式各样,导致最直接的问题就是无法按照统一的规则对日志进行切分,这无疑大大的增加了日志的分析、检索成本。
  3. 对PAAS支持不好。公司内部正在大面积推广应用容器化,但是并没有一个好的日志方案支撑容器内应用日志的采集。
  4. 日志利用程度低。对于日志的利用程度普遍停留于日志检索的水平,受限于工具未对日志的价值进行进一步挖掘,例如:日志监控、统计分析、调用链分析。

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

  • 业务日志平滑接入:业务日志接入日志系统,只需要进行简单的配置;日志平台也只需要进行一些基本的配置,无须涉及日志内容等业务信息。
  • 多样性支持:环境多样:物理机(虚拟机)、容器;来源多样:系统日志、业务日志、中间件日志……;格式多样:单行/多行, plain/json。
  • 日志挖掘:快速可查,日志监控,统计分析。
  • 系统可用性:数据实时性;丢失率可控(业务分级、全链路监控)。

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的类型也应保持不变。

例如:

日志系统技术方案

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

日志采集

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

  • 对于业务模块日志,统一按照日志规范并且通过非落盘的方式进行输出。针对此类场景,与平台技术部合作,基于go我们开发了log agent模块。
    Elasticsearch

本文转载自 B站日志系统

赞(0) 打赏
蜷缩的蜗牛 , 版权所有丨如未注明 , 均为原创丨 转载请注明蜷缩的蜗牛 » B站日志系统
分享到: 更多 (0)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏