• 欢迎访问蜷缩的蜗牛博客 蜷缩的蜗牛
  • 微信搜索: 蜷缩的蜗牛 | 联系站长 kbsonlong@qq.com
  • 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧

B站日志系统

ELK 蜷缩的蜗牛 8个月前 (01-15) 21次浏览 已收录


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 站日志系统


蜷缩的蜗牛 , 版权所有丨如未注明 , 均为原创丨 转载请注明B 站日志系统
喜欢 (0)
[]
分享 (0)