基于Scribe的奇虎360日志收集系统架构

前言

日志收集是大数据的基石。许多公司的业务平台每天都会产生大量的日志数据。收集业务日志数据，供离线和在线的分析系统使用，正是日志收集系统的要做的事情。高可用性，高可靠性和可扩展性是日志收集系统所具有的基本特征。

一、Scribe简介

目前在互联网公司比较常见日志收集系统有Flume和Scribe。

Scribe是Facebook开源的一个基于thrift的日志收集框架，它为日志收集提供了一种容错且可扩展的方案。scribe可以从不同数据源，不同机器上收集日志，然后将它们存入一个中央存储系统，以便集中统计分析处理。奇虎360就是用的Scribe来收集业务日志，但是在原生的基础上他们做了很多定制：zookeeper负载均衡、支持写HDFS、支持写Kestrel队列、支持写QBus/Kafka等。

当然，我并不推荐使用Scribe，因为Facebook已经不再更新和维护Scribe，而且原生Scribe有很多功能不完善。如果现在来进行技术选型，我推荐使用Flume。（Flume作为Apache的孵化项目，文档丰富，功能完善，高可靠、高可用、易扩展）。

二、Flume与Scribe框架对比

下面对Flume和Scribe进行了对比。对比中Flume将主要采用Flume-NG为参考对象，Scribe则采用原生的Scribe。同时，分为三层（Agent层，Collector层和Store层）来进行对比。

对比项	Flume-NG	Scribe
使用语言	Java	c/c++
容错性	Agent和Collector间，Collector和Store间都有容错性，且提供三种级别的可靠性保证；	Agent和Collector间, Collector和Store之间有容错性；
负载均衡	Agent和Collector间，Collector和Store间有LoadBalance和Failover两种模式	无
可扩展性	好	好
Agent丰富程度	提供丰富的Agent，包括avro/thrift socket, text, tail等	主要是thrift端口
Store丰富程度	可以直接写hdfs, text, console, tcp；写hdfs时支持对text和sequence的压缩；	提供buffer, network, file(hdfs, text)等
代码结构	系统框架好，模块分明，易于开发	代码简单

三、奇虎360日志收集系统架构

日志收集大致有两种应用场景：

• 离线计算：日志—>Scribe—>离线计算（如HDFS+MapReduce）
• 实时计算：日志—>Scribe—>实时计算（如Kafka+Storm）

下面是日志收集系统的整体架构图：

从架构图可以看出，日志收集系统主要分为三层：

1. 日志服务器：为了收集日志，每一台日志服务器上都会部署一个scribe客户端，它包含两个模块：agent 和 local_server。其中agent的作用就是以 tail 的方式读取本地目录下的日志文件，并将数据写到本地的 local_server，然后local_server通过zookeeper定位到center_server，并将数据发送给远端的center_server。

2. 中心服务器：center_server其实和local_server是同一套程序，只是配置文件不一样，它们通过 thrift 进行通信。center_server收到数据后，根据配置将各个category的数据发向不同的方向，比如写到HDFS、发到Kafka集群、发到Kestrel队列等等。

3. 存储服务器：日志被收集到存储服务器以后，就可以进行离线/实时的统计分析了。比如，HDFS是用来永久存储日志，并给MapReduce提供离线数据的；Kafka/Kestrel则是给Storm集群提供实时数据流，以实时地统计分析。

在Scribe中传输的每个基本数据单元都包含一个category和一个message，category作为message的标识符，用于给message分类，以避免数据在传输过程中混淆在一起。

以上介绍了日志的基本流动路线，但是也存在一些复杂的日志收集。比如，有时候日志存储到Kafka并经过Storm实时处理之后，还不算结束，还需要把Storm的处理结果存到HDFS上 —— 这时只需要在Storm程序里调用 thrift 接口将输出结果往center_server里写，并配置该category保存到HDFS上即可。

注：scribe各模块之间的通信都是通过 thrift 接口。

四、系统的基本特性

4.1 可用性

• agent挂掉：在所有日志服务器上部署了监控脚本，只要发现agent进程挂了，立即重启，以提供服务。重启失败则报警！
• local server挂掉：同上，日志服务器上的监控脚本只要发现local_server进程挂了，会立即重启，保证服务可用。重启失败则报警！
• center server挂掉：在所有中央服务器上部署了监控脚本，只要发现center_server进程挂了，立即重启。重启失败则报警！

4.2 可靠性

Scribe系统设计成能容错：

• 当网络或者机器出现故障时，如果客户端上的一个local_server不能发送消息到center_server，它会将消息保存到本地磁盘（堆积到一定量会报警）。当center_server或者网络故障恢复后，重新发送。
• 为了避免center_server重启时负载过重，重新发送者会等待一个随机事件，再发送。如果center_server接近其处理极限返回TRY_LATER，这就告诉resender间隔几分钟后再试。

以下情况数据可能会丢失：

• 一个center_server异常退出，内存中的消息会丢失。
• local_server不能连接到center_server，本地磁盘溢出，消息会丢失。
• 超时，导致存在重复的消息。

4.3 可扩展性

• 日志服务器：每个机器部署一个Scribe客户端，可以水平扩展，不受限制。Scribe收集日志的能力受限于机器的带宽，正常情况下单机千兆网卡就足够了。

• 中央服务器：从local_server到center_server是通过zookeeper自动负载均衡的，并且每台center_server提供无差别服务，所以可以线性扩展。通常中央服务器只有几台，当日志服务器不断增加导致中央服务器带宽打满时，就需要加机器了。

• 存储服务器：不论是hadoop集群还是kafka集群都是可以线性扩展的.

个人站点：http://songlee24.github.com