写入日志到Scribe的解决方案

774530750

写入日志到Scribe的解决方案

1.概述

Scribe日志收集服务器只负责收集主动写入它的日志，它本身不会去主动抓取某一个日志，所以为了把日志写入到 scribe服务器，我们必须主动向scribe服务器发送日志信息。由于scribe服务器是基于thrift框架实现的，并且thrift支持多种编程语言的通信，所以对于写入scribe服务器的客户端实现也可以使用多种语言，这就为把写入日志的客户端集成到各种应用系统中提供了很好的支持。把写入日志到scribe服务器的功能集成到应用系统是一种可行的解决方案，但是不是唯一的解决方案，我们还可以现实一个单独的客户端，专门用来抓取应用系统生成的日志文件，然后写入到scribe服务器。下面就针对这两种方案具体说明。

2.scribe日志写入与应用系统集成

（1）与java应用系统集成

与java系统集成有两种解决方案，一是通过scribe提供的开发API自己开发，另一种是通过与log4j集成（网上有开源的实现）。

对应用系统的影响：因为这种方式是作为应用系统的一个功能模块加入，所以需要加入额外的jar和需要额外的占用应用系统开销，除了这些还需要考虑scribe服务器不能正常链接时的异常处理。

（2）与C#应用系统集成

与C#系统集成是通过把scribe提供的开发API封装到一个dll文件里面，然后C#应用系统导入dll文件，利用提供的API开发写入scribe日志的功能模块。

对应用系统的影响：需要导入dll文件，增加应用系统的额外执行开销，存在链接scribe服务器的异常处理。

（3）与其他应用系统集成

由于thrift框架支持多做语言，而且scribe是基于thrift实现的，所以只要thrift支持的开发语言都可以与相应的应用系统集成开发。

3.单独的抓取日志文件的客户端

写一个单独的客户端是一种适用于任何应用系统的解决方案，前提是应用系统需要产生相应的日志文件。这个单独的客户端可以用thrift支持的任何一种语言实现，不过通常采用python实现，方便修改、扩展和部署。

这种解决方案实现的方式有两种：一是循环的去检测日志文件或文件夹，如果有新的日志生成就读取日志文件并上传到scribe服务器；二是通过事件响应的机制来监控文件或文件夹。

4.两种解决方案的比较

首先可以肯定的是两种解决方案都能够达到向scribe写入日志的目的。

两者的区别就是：

（1）与应用系统集成的方案写入日志的效率更高，因为不需要在通过一个转发的环节，通过应用系统直接写入，而且这种方案降低了出错的可能性，不需要单独去维护一个程序了。但是这种解决方案会对应用系统有一定的影响，前面以前描述具体的影响，还有就是不具有通用性，每一个应用系统需要单独开发一个这样的功能模块（开发的思路和方法基本相同）。

（2）单独的抓取日志文件客户端：具有很好的通用性，不需要每一个应用系统单独开发日志写入模块，只需要应用系统生成日志文件。而且这种方案对应用系统没有影响。当然这种解决方案的效率会低一些，因为需要通过一个文件来中转日志信息，还会因为单独的程序也可能会挂掉。

5.两种方案都需要解决的问题

（1）单点故障问题

（2）日志丢失问题