几种日志收集系统

2016 年 6 月 19 日1,1150

本站主要内容均为原创,转帖需注明出处www.alexclouds.net

        使用flume已经有两年多了,从flume到flumeNG, 变化之大可以见之前写得日志。简单说一下facebook的scribe,apache的chukwa,linkedin的kafka和cloudera的flume等 , 目前国内互联网企业flume用得多,单独使用flume的不多,都是组合使用。现在非常流行 flume 的sink到 kafaka, 然后到HDFS或Strom. 通过Flume集群将agnt的日志收集分发到 Kafka(实时计算)和HDFS(离线计算)。关于Flume集群部署可以参见UserGuide: http://flume.apache.org/FlumeUserGuide.html

       一般都将Flume集群和Kafka集群部署完成,然后来配置Flume的Sink数据流向,示意图如下:

imageimage

 

         举个例子,比如我们要搞日志收集系统负责所有业务日志的收集,那一般就分别给Hadoop平台提供离线数据和Storm平台提供实时数据流。比如我们可以参考美团的案例:

        a. 整个系统分为三层:Agent层,Collector层和Store层。其中Agent层每个机器部署一个进程,负责对单机的日志收集工作;Collector层部署在中心服务器上,负责接收Agent层发送的日志,并且将日志根据路由规则写到相应的Store层中;Store层负责提供永久或者临时的日志存储服务,或者将日志流导向其它服务器。
        b. Agent到Collector使用LoadBalance策略,将所有的日志均衡地发到所有的Collector上,达到负载均衡的目标,同时并处理单个Collector失效的问题。
       c. Collector层的目标主要有三个:SinkHdfs, SinkKafka和SinkBypass。分别提供离线的数据到Hdfs,和提供实时的日志流到Kafka和Bypass。其中SinkHdfs又根据日志量的大小分为SinkHdfs_b,SinkHdfs_m和SinkHdfs_s三个Sink,以提高写入到Hdfs的性能,具体见后面介绍。
       d. 对于Store来说,Hdfs负责永久地存储所有日志;Kafka存储最新的7天日志,并给Storm系统提供实时日志流;Bypass负责给其它服务器和应用提供实时日志流。

flume

        zabbix有个插件可以监控:发送速度,拥堵情况,写Hdfs速度,通过发送给zabbix的数据,就可以绘制出发送数量、拥堵情况和写Hdfs速度的图表,对于超预期的拥堵,需报警查找原因。

        当然上面这个图还是很久以前的,现在到处都是Docker容器,因此底层已经变化,需求也变了:

        比如一个普通的需求描述,这里描述一个目前比较通用的解决方案(资料参考网络)
      明确应用场景、功能需求和非功能需求。

1.1 应用场景
分布式环境下可承载百台服务器产生的日志,单条数据日志小于1k,最大不超过50k,日志总大小每天小于500G。

1.2 功能需求
1)集中收集所有服务日志。
2)可区分来源,按服务、模块和天粒度切分。

1.3 非功能需求
1)不侵入服务进程,收集日志功能需独立部署,占用系统资源可控。
2)实时性,低延迟,从产生日志到集中存储延迟小于4s。
3)持久化,保留最近N天。
4)尽量递送日志即可,不要求不丢不重,但比例应该不超过一个阈值(例如万分之一)。
4)可以容忍不严格有序。
5)收集服务属于线下离线功能,可用性要求不高,全年满足3个9即可。

           下面是个针对Docker的通用解决方案:

Producer层分析
         PaaS平台内的服务假设部署在Docker容器内,那么为了满足非功能需求#1,独立另外一个进程负责收集日志,因此不侵入服务框架和进程。采用Flume NG来进行日志的收集,这个开源的组件非常强大,可以看做一种监控、生产增量,并且可以发布、消费的模型,Source就是源,是增量源,Channel是缓冲通道,这里使用内存队列缓冲区,Sink就是槽,是个消费的地方。容器内的Source就是执行tail -F这个命令的去利用linux的标准输出读取增量日志,Sink是一个Kafka的实现,用于推送消息到分布式消息中间件。

Broker层分析
        PaaS平台内的多个容器,会存在多个Flume NG的客户端去推送消息到Kafka消息中间件。Kafka是一个吞吐量、性能非常高的消息中间件,采用单个分区按照顺序的写入的方式工作,并且支持按照offset偏移量随机读取的特性,因此非常适合做topic发布订阅模型的实现。这里图中有多个Kafka,是因为支持集群特性,容器内的Flume NG客户端可以连接若干个Kafka的broker发布日志,也可以理解为连接若干个topic下的分区,这样可以实现高吞吐,一来可以在Flume NG内部做打包批量发送来减轻QPS压力,二来可以分散到多个分区写入,同时Kafka还会指定replica备份个数,保证写入某个master后还需要写入N个备份,这里设置为2,没有采用常用的分布式系统的3,是因为尽量保证高并发特性,满足非功能需求中的#4。

Consumer层分析
        消费Kafka增量的也是一个Flume NG,可以看出它的强大之处,在于可以接入任意的数据源,都是可插拔的实现,通过少量配置即可。这里使用Kafka Source订阅topic,收集过来的日志同样先入内存缓冲区,之后使用一个File Sink写入文件,为了满足功能需求#2,可区分来源,按服务、模块和天粒度切分,我自己实现了一个Sink,叫做RollingByTypeAndDayFileSink,源代码放到了github上,可以从这个页面下载jar,直接放到flume的lib目录即可。

 

下面这个图:

image

 

         不过上面这些还是需要展示,这里只简单提一下。

 

        2013年董的博客发布了几个日志系统对比图,现在仍然具备参考意义,也有很多人转载:

        典型的日志系统需具备三个基本条件,分别为agent(封装数据源,将数据源中的数据发送给 collector),collector(接收多个agent的数据,并进行汇总后导入后端store),store(中央存储系统,应该具有可扩 展性和可靠性,应支持流行的store如HDFS)。

下面表格对比了这四个系统:

2012052517421116

 

      下面这些资料都来自网上,flume的安装配置,如何传入HDFS我早日志记录过了。至于flume+kafka+HDFS或者Storm,我也不用写了,基本拿起来就可以用。

cloudera的Flume。2009年7月开源日志系统。它内置的各种组件非常齐全,用户几乎不必进行任何额外开发即可使用。
设计目标:
(1) 可靠性
       当节点出现故障时,日志能够被传送到其他节点上而不会丢失。Flume提供了三种级别的可靠性保障,从强到弱依次分别为:end-to-end(收到数据 agent首先将event写到磁盘上,当数据传送成功后,再删除;如果数据发送失败,可以重新发送。),Store on failure(这也是scribe采用的策略,当数据接收方crash时,将数据写到本地,待恢复后,继续发送),Best effort(数据发送到接收方后,不会进行确认)。
(2) 可扩展性
       Flume采用了三层架构,分别问agent,collector和storage,每一层均可以水平扩展。其中,所有agent和collector由 master统一管理,这使得系统容易监控和维护,且master允许有多个(使用ZooKeeper进行管理和负载均衡),这就避免了单点故障问题。
(3) 可管理性
      所有agent和colletor由master统一管理,这使得系统便于维护。用户可以在master上查看各个数据源或者数据流执行情况,且可以对各 个数据源配置和动态加载。Flume提供了web 和shell script command两种形式对数据流进行管理。
(4) 功能可扩展性
       用户可以根据需要添加自己的agent,colletor或者storage。此外,Flume自带了很多组件,包括各种agent(file, syslog等),collector和storage(file,HDFS等)。

 

LinkedIn的Kafka。
         2010年12月份开源的项目,采用scala语言编写,适合异构集群。
设计目标:
(1) 数据在磁盘上的存取代价为O(1)
(2) 高吞吐率,在普通的服务器上每秒也能处理几十万条消息
(3) 分布式架构,能够对消息分区
(4) 支持将数据并行的加载到hadoop

 

FaceBook的Scribe。
       Scribe是facebook开源的日志收集系统,在facebook内部已经得到大量的应用。它能够从各种日志源上收集日志,存储到一个中央存储系统 (可以是NFS,分布式文件系统等)上,以便于进行集中统计分析处理。它为日志的“分布式收集,统一处理”提供了一个可扩展的,高容错的方案。
       它最重要的特点是容错性好。当后端的存储系统crash时,scribe会将数据写到本地磁盘上,当存储系统恢复正常后,scribe将日志重新加载到存储系统中。

 

Apache的Chukwa
       chukwa是一个非常新的开源项目,由于其属于hadoop系列产品,因而使用了很多hadoop的组件(用HDFS存储,用mapreduce处理数据),它提供了很多模块以支持hadoop集群日志分析。
需求:
(1) 灵活的,动态可控的数据源
(2) 高性能,高可扩展的存储系统
(3) 合适的框架,用于对收集到的大规模数据进行分析

 

参考资料
scribe主页:https://github.com/facebook/scribe
chukwa主页:http://incubator.apache.org/chukwa/
kafka主页:http://sna-projects.com/kafka/
Flume主页:https://github.com/cloudera/flume/

0 0