企业日志架构的4个典型场景

今天，我们从最简单的日志架构开始，介绍各种不同场景下的日志架构，并分析其在不同场景下的特点或问题。

• 1 -
  最简单的日志架构

这种架构是我使用过最简单的架构，我曾经在做一些个人小项目时，在资源不足的情况下曾经这样搭建过日志系统，当时的情况是只有两台需要监控的应用服务器，外加一台管理机，同时服务的访问量很小，每秒只有几十qps，也没有额外预算再加什么队列机和日志解析服务器，所以结合当时的实际情况，我就在应用服务器上使用Rsyslog直接做日志的收集和解析，将解析后的日志发到后端Elasticsearch，并用Kibana作为WebUI，来分析服务日志。总结一下，这种架构比较适合在资源有限的情况下使用，同时对日志的安全性没有太多的要求，另外访问量也不能太大。

• 2 -
  同步传输架构

这种架构是笔者刚到微博工作时，微博日志系统所采用的架构，这是一种典型的同步架构，当然微博在这种架构的基础之上还加入了LVS作为日志解析中转的负载均衡。当时采用这种结构的一个原因是因为rsyslog在当时对比其他组件来讲拥有相当好的性能，以及Rsyslog自身的队列缓冲机制，可以对后端错误进行容错。在早期，由于业务量不是很大，日志解析的需求不复杂，所以有很好的性能，也能基本满足业务需要，但随着后期公司业务不断增长，这种架构就暴露出了问题。

• 3 -
  以Redis作为传输队列的异步日志架构

这种架构就是大家经常在各种文档看到的架构，也是在早期Logstash官网（大约在2013年时Logstash是单独的网站）推荐的架构。这种架构加入了Redis队列将前后端解耦，可以有效的解决后端出现服务抖动等问题时对前端服务造成影响的问题。

当然这种结构也有自身的问题，所以这种架构比较适合规模较小的企业，他可以提供一定的数据安全性，当然这里还需要引入测试，就是要看当后端服务不通时，Redis能装下多长时间的数据，这个时间就是你能保证日志传输的安全时间。在规划Redis资源使用时，就要看这个时间是不是你能接受的，如果不能接受，可以考虑增加redis的资源大小，或者改用其他的队列系统。

• 4 -
  以Kafka作为队列的异步传输架构

这种结构引入Kafka作为日志队列，使用Kafka作为队列目前已经成为各大厂日志系统的标配。目前笔者所在的手机微博也是使用这种结构下面我就说说我们手机微博使用这种结构的好处：

优 势

(1).解决了前后端耦合的问题，后端服务出现问题时不会对前端服务造成影响。
(2).有很好的可扩展性，Kafka天生就支持分布式，写入和消费都可以很好的进行扩展，解决了LVS的各种网络限制，可以任意加入队列节点进行扩展。
(3).良好的数据安全性支持，Kafka本身具有副本的概念，可以进行数据备份，在Kafka自身单个节点出现问题时有很好的副本机制，保证了数据的安全性。
(4).Kafka由于使用磁盘作为主要存储介质，相比于Redis队列，可以节省很多的内存资源。从手机微博的使用的情况来看，Kafka单机的处理能力基本上是可以把双千兆网卡跑满。
(5).支持多消费者消费，一次写入，多个业务方可以同时消费数据，并彼此不干扰。

那么引入Kafka的日志传输架构是不是就十全十美了呢？其实也并不是，我简单说说我们目前使用Kafka作为队列时遇到的一些问题。

缺 点

我们现在日志收集端使用的是Rsyslog（当然fileBeats也存在这个问题），Rsyslog本身的配置要求只能允许配置一组Kafka，如果出现后端kafka整体不可用时，目前只能采用替换日志服务配置的方式进行服务切换。如果在服务器数量较少时还好说，但是对于像微博这样体量的公司的服务器数量来讲，重启一遍服务器还是需要花费一定时间的，这样必然会对服务传输造成影响。同时下游消费方也需要进行数据消费的切换。又会出现上下游的耦合联动。

当然有的读者可能提出可以通过提高Kafka的副本数，并使用多机房冗余的方式解决此问题，但是这又涉及到成本上成倍增加的问题，所以我们团队目前也在尝试解决这个问题，在保证成本尽量少的情况下加入类似代理的方式解决，具体的方式还在开发中，在此就不展开介绍了。

另外还要考虑成本的概念，比如在介绍第一种架构时，只有几台应用服务器的个人项目，如果这个时候就引入Kafka，Zookeeper那么对于后期维护来讲就是一个灾难。所以对处于创业阶段或者是快速成长的企业来讲，架构的快速迭代是很好的选择。

而对于已经处在成熟阶段的大厂同学来讲，在进行日志架构设计时，可能需要更多的考虑上下游的业务关系，尽量做到上下游的业务关系透明，彼此隔离，互不影响，尽量做到传输上的点对点分段治理。还要留好可扩展的“后路”。这一点可能只有当你真正在大厂工作一段时间才会深有体会。

举 例

举个笔者在刚接手手机微博日志系统时的例子，当时微博采用的还是前端Rsyslog到LVS，LVS负载均衡到Rsyslog中转解析集群，中转Rsyslog解析后传输到后端的日志系统或其他数据部门，这种日志架构，经常在晚高峰阶段出现前端的日志堆积，那么到底是LVS部门的问题还是我后端Rsyslog中转解析的问题，又或者是后端数据部门的传输拖慢了整个系统？从现象上看都有可能，由于涉及到第三方部门，排查和沟通就非常的繁琐，问题也比较难于定位，更有甚者，后端的数据部门也采用了LVS的负载均衡方式接收数据，那么在后端数据部门来看，还要分析到底是自身的问题，还是LVS的问题，这又牵扯到第三方业务部门。最后往往难于给出一个结论。

另外一个问题是这种架构采用的是推送数据的方式，而我们的中转日志解析的推送服务都部署在同一组Rsyslog日志解析服务集群上，这就会有另外一个问题，如果一个接受方出现问题，往往会对整体的日志解析造成影响，而排查具体是哪一个业务方拖慢了整体的解析服务就变的非常的困难。

所以在接手不久我们就开启了日志架构的改造之路，逐渐的迁移到了以Kafka为数据总线的架构上。我们负责将数据直接点对点的写入Kafka的topic里，而下游消费方直接消费自己topic的数据，彼此隔离，同时Kafka可以按照topic进行监控，可以看到后端的消费堆积情况。到底是我写入有问题，还是你消费有问题可以一目了然的看到，彼此服务管理的界限也非常的清楚。www.weipaimv.com