奇虎360scribe日志采集系统

最新推荐文章于 2024-08-06 16:38:50 发布

转载最新推荐文章于 2024-08-06 16:38:50 发布 · 1.7k 阅读

文章标签：

#scribe #大数据

日志采集专栏收录该内容

2 篇文章

订阅专栏

本文介绍了Scribe日志收集系统及其在奇虎360的应用。Scribe由Facebook开源，支持容错和可扩展性，适用于大规模日志数据收集。文章详细阐述了Scribe的架构、特点及与Flume的对比。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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

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

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

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

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

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

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

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

　　日志服务器：为了收集日志，每一台日志服务器上都会部署一个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上即可。