Scribe是facebook开源的日志收集系统。它能够从各种日志源上收集日志，存储到一个中央存储系统(可以是本地文件系统、NFS、分布式文件系统等)上，以便于进行集中统计分析处理。它具备很强的扩展能力,并且网络故障及服务器节点故障,都不会对日志收集造成影响，它为日志的“分布式收集，统一处理”提供了一个可扩展的，高容错的方案。
scribe架构
图上可以看到Scribe客户端从各种数据源上收集数据，放到一个共享队列上，然后push到后端的中央存储系统上。当中央存储系统的网络或者机器出现故障时，scribe会将日志转存到本地或者另一个位置，当中央存储系统恢复后，scribe会将转存的日志重新传输给中央存储系统。其通常与Hadoop结合使用，scribe用于向HDFS中push日志，而Hadoop通过MapReduce作业进行定期处理。
scribe部署结构
部署起来主要包括三部分：scribe agent、scribe、中央存储系统。
scribe agent实际上是一个thrift client。 向scribe发送数据的唯一方法是使用thrift client， scribe内部定义了一个thrift接口，用户使用该接口将数据发送给server。
scribe接收到thrift client发送过来的数据，根据配置文件，将不同主题的数据发送给不同的对象。scribe提供了各种各样的store，如file、HDFS等，scribe可将数据加载到这些store中。
存储系统实际上就是scribe中的store，当前scribe支持非常多的store，包括file(文件)，buffer（双层存储，一个主储存，一个副存储），network(另一个scribe服务器)，bucket(包含多个store，通过hash将数据存到不同store中)，null(忽略数据)，thriftfile(写到一个Thrift TFileTransport文件中)和multi(把数据同时存放到不同store中)。
需要注意的是，各个数据源须通过thrift传输数据，由于采用了thrift，客户端可以采用各种语言编写的客户端向scribe传输数据(每条数据记录包含一个category和一个message)。可以在scribe配置用于监听端口的thrift线程数（默认为3）。在后端，scribe可以将不同category的数据存放到不同目录中，以便于进行分别处理。
可以看到虽然scribe支持多种日志存储类型，而且日志可以按照大小和时间切分，但是scribe并不是完美的，它也存在单点故障、日志丢失等问题。
以下的错误会导致数据丢失
1）客户端不能连接到本地或中央server，消息则会丢失。
2）一个scribe服务器宕机了，内存中少量的消息会丢失，磁盘上的数据不会丢失。
3）Scribe服务不能连接到中央server，本地磁盘溢出，消息会丢失。
4）超时，导致存在重复的消息
Scribe日志收集服务器只负责收集主动写入它的日志，它本身不会去主动抓取某一个日志，所以为了把日志写入到scribe服务器，我们必须主动向scribe服务器发送日志信息。由于scribe服务器是基于thrift框架实现的，并且thrift支持多种编程语言的通信，所以对于写入scribe服务器的客户端实现也可以使用多种语言，这就为把写入日志的客户端集成到各种应用系统中提供了很好的支持，因为它提供几乎所有的开发语言的开发包。而且也可以作为独立的客户端实现。
scribe集成到应用系统和单独作为客户端收集日志的区别是：
客户端与应用系统集成的方案写入日志的效率更高，因为不再需要通过一个转发的环节，通过应用系统直接写入，而且这种方案降低了出错的可能性，不需要单独去维护一个程序了。但是这种解决方案会对应用系统有一定的影响，还有就是不具有通用性，每一个应用系统需要单独开发一个这样的功能模块。
单独的抓取日志文件的客户端具有很好的通用性，不需要每一个应用系统单独开发日志写入模块，只需要应用系统生成日志文件。而且这种方案对应用系统没有影响。当然这种解决方案的效率会低一些，因为需要通过一个文件来中转日志信息，还会因为单独的程序也可能会挂掉。
参考：
https://github.com/facebook/scribe
http://www.cnblogs.com/brucewoo/archive/2011/12/13/2285482.html
扫一扫
782
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
