读者QQ群②:190771709,投稿请发dashuju36@qq.com
我要投稿

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

1

作者:神奕

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

一、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层)来进行对比。

36大数据

 

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

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

离线计算:日志—->Scribe—->离线计算(如HDFS+MapReduce)

实时计算:日志—->Scribe—->实时计算(如Kafka+Storm)

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

36大数据

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

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

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

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

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

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

36大数据

注: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集群都是可以线性扩展的.

End.

转载请注明来自36大数据(36dsj.com):36大数据 » 基于Scribe的奇虎360日志收集系统架构

36大数据   除非特别注明,本站所有文章均不代表本站观点。报道中出现的商标属于其合法持有人。请遵守理性,宽容,换位思考的原则。

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址