Facebook Scribe 日志聚合

随着云计算时代的到来，我们的互联网系统服务端越来越庞大，一个大型系统通常由成百上千台机器集群而成，我们的系统会部署在这数千台机器中，此时需要时刻监控每一个系统运行的数据。我们可能会需要了解各个系统每天进行了多少交易，并进行汇总、分析、统计、报表。典型的应用就是：收集上千个系统产生的日志，并进行分析统计里面的数据，挖掘、预测。

简单的方式可以是：同步每个机器上的日志到离线服务器，定时分析离线的日志，将离线分析结果报告存储起来，同时完成备份日志的工作。这样无法做到实时分析、监控，另外我们需要关注所有的系统。

但还有一种简单的方式：将每个系统的日志实时报告给中心服务器，在中心服务器使用大的磁盘存储或分布式存储，管理、分析、挖掘、报告，怎么折腾都可以。而这些需求都已经由Facebook发现了(Facebook每天log上百亿条信息,每秒log上百万条)，并实现了，实现的结果就是Scribe系统。

 在分布式计算环境下，工作中要求对各Node进行监控，监控分了系统级和服务级监控，系统级监控保证系统服务器稳定性，如CPU、内存、网络、数据库等；服务级监控是比较细粒度的监控，如一段时间内服务出现多少次错误、警告，则报警等。对于集群中的系统进行服务级监控，主要想对各系统产生的日志进行聚合，对日志进行监控。

 

下面是Facebook Scribe的一些简介：

Scribe是用来收集日志的服务器。它具备很强的扩展能力，并且网络故障及服务器节点故障，都不会对日志收集造成影响。大规模集群系统中每个节点上都运行了一个Scribe服务器，这个Scribe服务器可以收集信息然后将信息发送到一个中央Scribe服务器(也可以是多个中央Scribe服务器)，如果中央Scribe服务器(或中央服务器组)出现故障不可用的话，各个节点的Scibe服务器就会将日志信息写到本地磁盘，待中央Scribe服务器恢复正常时再发送。中央Scribe服务器会将这些信息写文件保存到最终的磁盘地址，一般是nfs文件系统或者一个分布式文件系统中，有时也会把这些日志文件传输到其他层的Scribe服务器组中. Scribe的独特之处是客户端日志实例包含两个字符串：类别和信息(a category and a message)。类别(category)是对预期目标信息的高层次描述，可以在Scribe服务器中进行配置，这样就允许我们可以通过更改配置文件的方式转移数据而不需要更改代码。Scribe服务器也允许基于类别前缀(category prefix)进行配置，缺省状态下可以在文件路径中插入类别名称。灵活性和可扩展性，可通过“存储(store)“抽象。Stores可以通过一个配置文件静态配置，也可以在运行时无需停止服务器进行更改。 Scribe是对一个使用非阻断C++服务器的thrift服务的实现。Facebook在上千台服务器上运行了Scribe服务，每天收集传输数十亿的信息。Scribe本身由C++实现， 其客户端与服务端的RPC通信默认实现为Python 实现。为了Scribe能够为多种语言所用，它采用了Thrift框架来进行通信，服务端已经由它实现了，客户端它只实现了Python版，我们可以根据Thrift框架很容易的导出Java实现版本，并在各种语言的系统中应用。

 

下面来学习一下Scribe，国内资料太少了，想办法FQ吧！