目录
B站的日志系统（Billions）从2017年5月份开始建设，基于elastic stack，面向全站提供统一的日志采集、检索、监控服务。目前集群规模20台机器，接入业务200+，单日日志量10T+。
借此机会跟大家分享一些B站在日志系统的建设、演进以及优化的经历。由于经验尚少，抛砖引玉，欢迎大家一起交流讨论。文章主要分为三个部分： 原有日志系统 ，现有系统演进， 未来的展望 。
原有日志系统
在Billions之前，B站内部并没有统一的日志平台，基本是业务之间各自为战，既有基于ELK的比较前瞻的方式，又有服务器上使用tail/grep比较基本原始的方式，水平参差不齐。在了解各个产品线的情况后，存在的问题和诉求主要有以下几点：
针对上述问题，提出新的日志系统的设计目标如下：
Billions的演进
系统的初建
日志规范
为了解决业务日志格式多样性问题，统一制定了日志格式规范，使用JSON作为日志的输出格式。格式要求：
例如：
"hello billions, write more"
"testapp111"
"instance_id"
"instance1"
"2017-08-04T15:59:01.607483"
|
日志系统技术方案
日志从产生到消费，主要经历以下几个阶段：采集->传输->切分->检索。
日志采集
日志采集针对非落盘和落盘两种方式。
日志采集
公司内部已经有了统一的数据传输平台（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的架构如下：
现有问题和下一步工作
目前日志系统还存在很多不足的地方，主要有：
[转自：
发表评论