B 站日志系统的前世此生

王翔宇node

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

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

借此机会跟你们分享一些B站在日志系统的建设、演进以及优化的经历。因为经验尚少，抛砖引玉，欢迎你们一块儿交流讨论。文章主要分为三个部分：原有日志系统，现有系统演进，将来的展望。json

原有日志系统

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

方案各异。因为各个部门自行实现日志方案，没有专人维护，广泛存在维护成本高、系统不稳定、丢日志、易用性不足的状况。缓存

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

对PAAS支持很差。公司内部正在大面积推广应用容器化，可是并无一个好的日志方案支撑容器内应用日志的采集。服务器

日志利用程度低。对于日志的利用程度广泛停留于日志检索的水平，受限于工具未对日志的价值进行进一步挖掘，例如：日志监控、统计分析、调用链分析。markdown

针对上述问题，提出新的日志系统的设计目标以下：架构

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

Billions的演进

系统的初建

日志规范

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

必须包含四类元信息：

time: 日志产生时间，ISO8601格式
level：日志等级， FATAL、ERROR、WARN、INFO、DEBUG
app_id：应用id，用于标示日志来源，与公司服务树一致，全局惟一
instance_id：实例id，用于区分同一应用不一样实例，格式业务方自行设定

日志详细信息统一保存到log字段中。
除上述字段以外，业务方也能够自行添加额外的字段。
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}复制代码{"log": "hello billions, write more", "level": "INFO", "app_id": "testapp111", "instance_id": "instance1", "time": "2017-08-04T15:59:01.607483", "id": 0}

日志系统技术方案

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

日志采集

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

对于业务模块日志，统一按照日志规范而且经过非落盘的方式进行输出。针对此类场景，与平台技术部合做，基于go咱们开发了log agent模块。

log agent部署在物理机上，暴露出一个domain sock文件，程序将日志经过unixgram方式输出到domain sock。
对于运行在PAAS上的应用，在container初始化的时候，sock文件被默认mount到container内部，这样容器内的程序就能够输出日志。
log agent分为两个部分，collector和sender。collector用于接收日志，sender用于向传输系统发送日志。二者直接经过一个文件缓存进行交互。这样在日志传输系统故障的状况下，依赖本地缓存能够保证日志的正常接收。
咱们提供了不一样语言对应的日志库（sdk），程序能够快速接入日志系统。

非业务模块（中间件、系统模块、接入层）日志，因为定制化能力较差，咱们经过读取生成的日志文件完成日志的采集。

咱们采用的elastic stack中的filebeat进行采集，filebeat具备方便部署、配置简单、资源消耗低的优点，并且支持多行日志的拼接。
物理机上部署一个单独的filebeat进程，每一类日志对应一个单独的配置文件。
每一条日志都会被单独打上一个app_id标签，这个相似业务日志的app_id字段，这样在最终消费日志的时候就能够进行区分了。
filebeat会自动标示日志来源机器，这样也就具备了区分同一应用不一样实例的能力。

日志采集

公司内部已经有了统一的数据传输平台（lancer），lancer的优点以下：

基于flume+kafka作二次定制化开发，内部自动负载均衡，容量可水平扩展。
数据接收端实现了一套可靠的数据传输协议，完善的链路监控，数据传输安全可靠。
能够根据业务须要对接不一样的消费方式（kafka、hdfs）。
有专业的团队进行7*24维护。

所以咱们直接选择lancer做为咱们的日志传输系统。

log agent中的sender模块基于lancer的定制化的数据传输协议发送日志，最终日志被传输到kafka集群中的不一样topic（根据日志流量，配置topic），后续从kafka消费日志，全部的topic采用一个统一的prefix。
因为暂时没有精力对filebeat进行二次定制化开发，所以filebeat直接将日志输出到lancer的kafka集群。

日志切分

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

其中：

对于按照日志规范生成的日志，日志的kafka topic采用了统一的前缀，所以咱们采用topics_pattern的方式来消费日志。
logstash的partition_assignment_strategy要设置为”org.apache.kafka.clients.consumer.RoundRobinAssignor”，默认的策略（Range partitioning）会致使partition分配不均，若是采用默认的策略，当consumer（logstash数量*worker数量）的数量大于topic partition数量时，partition老是只会被分配给固定的一部分consumer。
对于非标准格式日志，因为logstash single event pipeline的限制，所以缺少对于多配置的支持（期待6.0的multi event pipeline）。每种日志配置不一样，所以须要单独的logstash进程进行消费。

日志检索

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

数据机器（40core，256G内存, 1T ssd, 6T*4 SATA）采用冷热分离的方案：同时部署一个hot node和stale node。hot node使用ssd做为存储介质，接收实时日志。stale node使用sata盘做为存储介质，存储历史日志（只读不写）。每日固定时间进行热->冷迁移。
client node对外提供读取api，对接kibana、管理程序（好比curator、cerebro等）。
index管理（迁移、删除）采用curator，日志默认保留7天。
es集群配置优化借鉴了不少社区的建议，就不详细介绍了。
使用template进行index mapping的管理。
index提早一天进行建立，防止集中建立致使数据没法写入。
es监控：调研了官方的x-pack monitor，因为x-pack monitor功能不足（例如缺乏对于线程池的监控），而且不能进行报警，最终选择自研。公司内部监控系统基于Prometheus，咱们开发了es_exporter负责采集es的状态信息，最终监控报警经过Prometheus实现。报警主要包含关键指标，例如：es cluster的状态信息、thread rejected数量、node节点数量、unassign shard数量。

通过上述步骤，最终日志就能够在kibana上进行查询。第一阶段，日志系统的总体架构为：

系统迭代

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

shard管理

最初采用了es默认的管理策略，全部的index对应5*2个shard（5个primary，5个replica），带来的主要问题以下：

每一个shard都是有额外的开销的（内存、文件句柄），大部分的index的数量都比较小，彻底没有必要建立5个shard。
某些index的数据量很大（大于500GB/day），单个shard对应的数据量就会很大，这样会致使检索的速度不是最优, 而且磁盘write IO集中在少数机器上。

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

日志采样

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

日志采样以app_id为维度，INFO级别如下日志按照比例进行随机采样，WARN以上日志所有保留。
log agent接入公司配置中心，采样比例保存在配置中心，能够动态生效。
有个细节额外说明下：因为要获取日志内的app_id字段，若是直接进行json解析， cpu消耗将很是之高。后续咱们改进为字符查找（bytes.Index ），解决了这个问题。

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

data node硬件瓶颈解决

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

hot node出现了较多bulk request rejected，同时logstash收到了不少的429响应。尝试调大了thread pool size和 queue_size，可是问题依然存在。

hot node机器长时间出现io wait现象，同时SSD Disk io Utiliztion 100% 。

经过以上现象，怀疑是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也有一些不足之处：

rule存储在文件中，不可靠而且没法进行分布式扩展。
rule配置比较复杂，不够友好和易用。
程序单点，高可用没法保证。
监控规则顺序执行，效率低（若是全部规则执行时间大于执行间隔，单条规则的按期执行将没法保证）。

针对上述不足和自身须要，咱们对于elastalert进行了二次开发：

主要的改进点包括：

将全部的rule存储在elasticsearch中，即增长了rule存储的可靠性，也为elastalert的分布式实现作好准备。
全部类型的日志监控rule使用模板进行封装，以下降配置复杂度。例如限制使用query string过滤日志，屏蔽某些配置项等等。
封装出一套Restful api进行监控规则的增删改查。
与公司现有监控系统（Bili Moni）结合：基于web配置日志监控，经过报警平台发送报警。
利用全局锁解决单点问题：两个进程一热一冷，热进程故障后冷会自动接手，并进行报警。
对于报警内容进行了调整（格式调整，汉化），表述更加清晰。

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

最新Billions的架构以下：

现有问题和下一步工做

目前日志系统还存在不少不足的地方，主要有：

缺少权限控制：目前权限控制缺失，后续须要实现统一认证、基于index的受权、操做审计等功能，类比xpack。
缺少全链路监控：日志从产生到能够检索，通过多级模块，目前监控各层独立实现，未进行串联，所以没法对堆积和丢失状况进行精准监控。
日志监控性能瓶颈：目前日志监控为单节点（一个热节点工做）而且规则顺序执行，后续须要优化为分布式架构+规则并行执行。
日志切分配置复杂：对于非标准格式日志，基于logstash实现日志切分，每一种日志须要单独的logstash实例进行消费，配置和上线过程复杂，后续须要平台化的系统进行支撑。

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