深层次分析美团根据Flume的网站系统日志搜集系统

2021-02-21 14:44 admin

美团的系统日志搜集系统软件负责美团的全部业务流程系统日志的搜集,并各自给Hadoop服务平台出示线下数据信息和Storm服务平台出示即时数据信息流。美团的系统日志搜集系统软件根据Flume设计方案和构建而成。

《根据Flume的美团系统日志搜集系统软件》将分两一部分给读者展现美团系统日志搜集系统软件的构架设计方案和实战演练工作经验。

第1一部分构架和设计方案,将关键着眼于系统日志搜集系统软件总体的构架设计方案,和为何要做这样的设计方案。

第2一部分改善和提升,将关键着眼于具体布署和应用全过程中遇到的难题,对Flume做的作用改动和提升等。

1 系统日志搜集系统软件简介
系统日志搜集是绝大多数据的基石。

很多企业的业务流程服务平台每日都会造成很多的系统日志数据信息。搜集业务流程系统日志数据信息,供线下和线上的剖析系统软件应用,更是系统日志搜集系统软件的要做的事儿。高能用性,高靠谱性和可拓展性是系统日志搜集系统软件所具备的基础特点。

现阶段常见的开源系统系统日志搜集系统软件有Flume, Scribe等。Flume是Cloudera出示的1个高能用的,高靠谱的,遍布式的大量系统日志收集、汇聚和传送的系统软件,现阶段早已是Apache的1个子新项目。Scribe是Facebook开源系统的系统日志搜集系统软件,它为系统日志的遍布式搜集,统1解决出示1个可拓展的,高容错机制的简易计划方案。

2 常见的开源系统系统日志搜集系统软件比照
下面将对普遍的开源系统系统日志搜集系统软件Flume和Scribe的各层面开展比照。比照中Flume将关键选用Apache下的Flume-NG为参照目标。另外,美团将常见的系统日志搜集系统软件分成3层(Agent层,Collector层和Store层)来开展比照。

3 美团系统日志搜集系统软件构架
美团的系统日志搜集系统软件负责美团的全部业务流程系统日志的搜集,并各自给Hadoop服务平台出示线下数据信息和Storm服务平台出示即时数据信息流。美团的系统日志搜集系统软件根据Flume设计方案和构建而成。现阶段每日搜集和解决约T级別的系统日志数据信息。

下图是美团的系统日志搜集系统软件的总体架构图。

a. 全部系统软件分成3层:Agent层,Collector层和Store层。在其中Agent层每一个设备布署1个过程,负责对单机版的系统日志搜集工作中;Collector层布署在管理中心服务器上,负责接受Agent层推送的系统日志,而且将系统日志依据路由器标准写到相应的Store层中;Store层负责出示永久性或临时性的系统日志储存服务,或将系统日志流导向性其它服务器。

b. Agent到Collector应用LoadBalance对策,将全部的系统日志平衡地发到全部的Collector上,做到负载平衡的总体目标,另外并解决单独Collector无效的难题。

c. Collector层的总体目标关键有3个:SinkHdfs, SinkKafka和SinkBypass。各自出示线下的数据信息到Hdfs,和出示即时的系统日志流到Kafka和Bypass。在其中SinkHdfs又依据系统日志量的尺寸分成SinkHdfs_b,SinkHdfs_m和SinkHdfs_s3个Sink,以提升写入到Hdfs的特性,实际见后边详细介绍。

d. 针对Store来讲,Hdfs负责永久性地储存全部系统日志;Kafka储存全新的7天系统日志,并给Storm系统软件出示即时系统日志流;Bypass负责给其它服务器和运用出示即时系统日志流。

下图是美团的系统日志搜集系统软件的控制模块溶解图,详解Agent, Collector和Bypass中的Source, Channel和Sink的关联。

a. 控制模块取名标准:全部的Source以src开始,全部的Channel以ch开始,全部的Sink以sink开始;

b. Channel统1应用美团开发设计的DualChannel,实际缘故后边详细描述;针对过虑掉的系统日志应用NullChannel,实际缘故后边详细描述;

c. 控制模块之间內部通讯统1应用Avro插口;

4 构架设计方案考虑到
下面将从能用性,靠谱性,可拓展性和适配性等层面,对上述的构架做细腻的分析。

4.1 能用性(availablity)
对系统日志搜集系统软件来讲,能用性(availablity)指固定不动周期限内系统软件无常见故障运作总時间。要想提升系统软件的能用性,就必须清除系统软件的多点,提升系统软件的冗余度。下面看来看美团的系统日志搜集系统软件在能用性层面的考虑到。

4.1.1 Agent死掉
Agent死掉分成两种状况:设备死机或Agent过程死掉。

针对设备死机的状况来讲,因为造成系统日志的过程也一样会死掉,因此不容易再造成新的系统日志,不存在不出示服务的状况。

针对Agent过程死掉的状况来讲,的确会减少系统软件的能用性。对此,美团有下面3种方法来提升系统软件的能用性。最先,全部的Agent在supervise的方法下起动,假如过程死掉会被系统软件马上重新启动,以出示服务。其次,对全部的Agent开展生存监管,发现Agent死掉马上警报。最终,针对十分关键的系统日志,提议运用立即将系统日志写硬盘,Agent应用spooldir的方法得到全新的系统日志。

4.1.2 Collector死掉
因为管理中心服务器出示的是对等的且无区别的服务,且Agent浏览Collector做了LoadBalance和重试体制。因此当某个Collector没法出示服务时,Agent的重试对策会将数据信息推送到其它能用的Collector上面。因此全部服务不会受到危害。

4.1.3 Hdfs一切正常停机
美团在Collector的HdfsSink中出示了电源开关选项,能够操纵Collector终止写Hdfs,而且将全部的events缓存文件到FileChannel的作用。

4.1.4 Hdfs出现异常停机或不能浏览
倘若Hdfs出现异常停机或不能浏览,此时Collector没法写Hdfs。因为美团应用DualChannel,Collector能够将所收到的events缓存文件到FileChannel,储存在硬盘上,再次出示服务。当Hdfs修复服务之后,再将FileChannel中缓存文件的events再推送到Hdfs上。这类体制相近于Scribe,能够出示较好的容错机制性。

4.1.5 Collector变慢或Agent/Collector互联网变慢
假如Collector解决速率变慢(例如设备load太高)或Agent/Collector之间的互联网变慢,将会致使Agent推送到Collector的速率变慢。一样的,针对此种状况,美团在Agent端应用DualChannel,Agent能够将收到的events缓存文件到FileChannel,储存在硬盘上,再次出示服务。当Collector修复服务之后,再将FileChannel中缓存文件的events再推送给Collector。

4.1.6 Hdfs变慢
当Hadoop上的每日任务较多且有很多的读写能力实际操作时,Hdfs的读写能力数据信息常常变的很慢。因为每日,每周都有高峰期应用期,因此这类状况十分广泛。

针对Hdfs变慢的难题,美团一样应用DualChannel来处理。当Hdfs写入较快时,全部的events只历经MemChannel传送数据信息,降低硬盘IO,得到较高特性。当Hdfs写入较慢时,全部的events只历经FileChannel传送数据信息,有1个较大的数据信息缓存文件室内空间。

4.2 靠谱性(reliability)
对系统日志搜集系统软件来讲,靠谱性(reliability)是指Flume在数据信息流的传送全过程中,确保events的靠谱传送。

对Flume来讲,全部的events都被储存在Agent的Channel中,随后被推送到数据信息流中的下1个Agent或最后的储存服务中。那末1个Agent的Channel中的events何时被删掉呢?当且仅当它们被储存到下1个Agent的Channel中或被储存到最后的储存服务中。这便是Flume出示数据信息流中点到点的靠谱性确保的最基础的单跳信息传送词义。

那末Flume是怎样保证上述最基础的信息传送词义呢?

最先,Agent间的事务管理互换。Flume应用事务管理的方法来确保event的靠谱传送。Source和Sink各自被封裝在事务管理中,这些事务管理由储存event的储存出示或由Channel出示。这就确保了event在数据信息流的点对点传送中是靠谱的。在多级别数据信息流中,以下图,上1级的Sink和下1级的Source都被包括在事务管理中,确保数据信息靠谱地从1个Channel到另外一个Channel迁移。

其次,数据信息流中 Channel的长久性。Flume中MemoryChannel是将会遗失数据信息的(当Agent死掉时),而FileChannel是长久性的,出示相近mysql的系统日志体制,确保数据信息不遗失。

4.3 可拓展性(scalability)
对系统日志搜集系统软件来讲,可拓展性(scalability)是指系统软件可以线形拓展。当天志量增大时,系统软件可以以简易的提升设备来做到线形扩容的目地。

针对根据Flume的系统日志搜集系统软件来讲,必须在设计方案的每层,都可以以保证线形拓展地出示服务。下面将对每层的可拓展性做相应的表明。

4.3.1 Agent层
针对Agent这1层来讲,每一个设备布署1个Agent,能够水平拓展,不会受到限定。1个层面,Agent搜集系统日志的工作能力受到限制于设备的特性,一切正常状况下1个Agent能够为单机版出示充足服务。另外一层面,假如设备较为多,将会受到限制于后端开发Collector出示的服务,但Agent到Collector是有Load Balance体制,使得Collector能够线形拓展提升工作能力。

4.3.2 Collector层
针对Collector这1层,Agent到Collector是有Load Balance体制,而且Collector出示无区别服务,因此能够线形拓展。其特性关键受到限制于Store层出示的工作能力。

4.3.3 Store层
针对Store这1层来讲,Hdfs和Kafka全是遍布式系统软件,能够保证线形拓展。Bypass属于临时性的运用,只对应于某1类系统日志,特性并不是短板。

4.4 Channel的挑选
Flume1.4.0中,其官方出示常见的MemoryChannel和FileChannel供大伙儿挑选。其好坏以下:

MemoryChannel: 全部的events被储存在运行内存中。优势是高吞吐量。缺陷是容量比较有限而且Agent死掉时会遗失运行内存中的数据信息。
FileChannel: 全部的events被储存在文档中。优势是容量较大且死掉时数据信息可修复。缺陷是速率较慢。
上述两种Channel,优缺陷相反,各自有自身合适的情景。但是,针对绝大多数运用来讲,美团期待Channel能够同出示高吞吐量和大缓存文件。根据此,美团开发设计了DualChannel。

DualChannel:根据 MemoryChannel和 FileChannel开发设计。当堆积在Channel中的events数小于阀值时,全部的events被储存在MemoryChannel中,Sink从MemoryChannel中载入数据信息; 当堆积在Channel中的events数超过阀值时, 全部的events被全自动储放在FileChannel中,Sink从FileChannel中载入数据信息。这样当系统软件一切正常运作时,美团可使用MemoryChannel的高吞吐量特点;当系统软件有出现异常时,美团能够运用FileChannel的大缓存文件的特点。
4.5 和scribe适配
在设计方案之初,美团就规定每类系统日志都有1个category相对性应,而且Flume的Agent出示AvroSource和ScribeSource两种服务。这将维持和以前的Scribe相对性应,降低业务流程的变更成本费。

4.6 管理权限操纵
在现阶段的系统日志搜集系统软件中,美团只应用最简易的管理权限操纵。仅有设置的category才能够进到到储存系统软件。因此现阶段的管理权限操纵便是category过虑。

假如管理权限操纵放在Agent端,优点是能够较好地操纵废弃物数据信息在系统软件中运转。但缺点是配备改动不便,每提升1个系统日志就必须重新启动或重载Agent的配备。

假如管理权限操纵放在Collector端,优点是便捷开展配备的改动和载入。缺点是一部分沒有申请注册的数据信息将会在Agent/Collector之间传送。

考虑到到Agent/Collector之间的系统日志传送并不是系统软件短板,且现阶段系统日志搜集属內部系统软件,安全性难题属于主次难题,因此挑选选用Collector端操纵。

4.7 出示即时流
美团的一部分业务流程,属实时强烈推荐,反爬虫服务等服务,必须解决即时的数据信息流。因而美团期待Flume可以导出来1份即时流给Kafka/Storm系统软件。

1个十分关键的规定是即时数据信息流不可该遭受其它Sink的速率危害,确保即时数据信息流的速率。这1点,美团是根据Collector中设定不一样的Channel开展防护,而且DualChannel的大容量确保了系统日志的解决不会受到Sink的危害。

5 系统软件监管
针对1个大中型繁杂系统软件来讲,监管是必不能少的一部分。设计方案有效的监管,能够对出现异常状况立即发现,要是有1部手机上,便可以了解系统软件是不是一切正常运行。针对美团的系统日志搜集系统软件,美团创建了多维度度的监管,避免未知的出现异常产生。

5.1 推送速率,拥挤状况,写Hdfs速率
根据推送给zabbix的数据信息,美团能够绘图考虑送数量、拥挤状况和写Hdfs速率的图表,针对超预期的拥挤,美团会警报出来搜索缘故。

下面是Flume Collector HdfsSink写数据信息到Hdfs的速率截图:

下面是Flume Collector的FileChannel中拥挤的events数据信息量截图:

5.2 flume写hfds情况的监管
Flume写入Hdfs会先转化成tmp文档,针对非常关键的系统日志,美团会每15分钟上下查验1下各个Collector是不是都造成了tmp文档,针对沒有一切正常造成tmp文档的Collector和系统日志美团必须查验是不是有出现异常。这样能够立即发现Flume和系统日志的出现异常.

5.3 系统日志尺寸出现异常监管
针对关键的系统日志,美团会每一个小时都监管系统日志尺寸周同比为否有较大起伏,并给予提示,这个警报合理的发现了出现异常的系统日志,且数次发现了运用方系统日志推送的出现异常,立即给予了对方意见反馈,协助她们尽早修补本身系统软件的出现异常。

根据上述的解读,美团能够看到,根据Flume的美团系统日志搜集系统软件早已是具有高能用性,高靠谱性,可拓展等特点的遍布式服务。

改善和提升
下面,美团可能讲述在具体布署和应用全过程中遇到的难题,对Flume的作用改善和对系统组件做的提升。

1 Flume的难题总结
在Flume的应用全过程中,遇到的关键难题以下:

a. Channel“水土不服情况”:应用固定不动尺寸的MemoryChannel在系统日志高峰期经常报序列尺寸不足的出现异常;应用FileChannel又致使IO忙碌的难题;

b. HdfsSink的特性难题:应用HdfsSink向Hdfs写系统日志,在高峰期時间速率较慢;

c. 系统软件的管理方法难题:配备升級,控制模块重新启动等;

2 Flume的作用改善和提升点
从上面的难题中能够看到,有1些要求是原生态Flume没法考虑的,因而,根据开源系统的Flume美团提升了很多作用,改动了1些Bug,而且开展1些调优。下面将对1些关键的层面做1些表明。

2.1 提升Zabbix monitor服务
1层面,Flume自身出示了http, ganglia的监管服务,而美团现阶段关键应用zabbix做监管。因而,美团为Flume加上了zabbix监管控制模块,和sa的监管服务无缝拼接结合。

另外一层面,净化Flume的metrics。只将美团必须的metrics推送给zabbix,防止 zabbix server导致工作压力。现阶段美团最为关注的是Flume能否立即把运用端推送过来的系统日志写到Hdfs上, 对应关心的metrics为:

Source : 接受的event数和解决的event数
Channel : Channel中拥挤的event数
Sink : 早已解决的event数


2.2 为HdfsSink提升全自动建立index作用
最先,美团的HdfsSink写到hadoop的文档选用lzo缩小储存。 HdfsSink能够载入hadoop配备文档中出示的编号类目录,随后根据配备的方法获得应用何种缩小编号,美团现阶段应用lzo缩小数据信息。选用lzo缩小而非bz2缩小,是根据下列检测数据信息:

其次,美团的HdfsSink提升了建立lzo文档后全自动建立index作用。Hadoop出示了对lzo建立数据库索引,使得缩小文档是可分割的,这样Hadoop Job能够并行处理解决数据信息文档。HdfsSink自身lzo缩小,但写完lzo文档其实不会建数据库索引,美团在close文档以后加上了建数据库索引作用。

Java Code拷贝內容到剪贴板
  1.   /**  
  2.    * Rename bucketPath file from .tmp to permanent location.  
  3.    */  
  4.   private void renameBucket() throws IOException, InterruptedException {   
  5.       if(bucketPath.equals(targetPath)) {   
  6.               return;   
  7.         }   
  8.   
  9.         final Path srcPath = new Path(bucketPath);   
  10.         final Path dstPath = new Path(targetPath);   
  11.   
  12.         callWithTimeout(new CallRunner<Object>() {   
  13.               @Override  
  14.               public Object call() throws Exception {   
  15.                 if(fileSystem.exists(srcPath)) { // could block   
  16.                       LOG.info("Renaming " + srcPath + " to " + dstPath);   
  17.                      fileSystem.rename(srcPath, dstPath); // could block   
  18.   
  19.                       //index the dstPath lzo file   
  20.                       if (codeC != null && ".lzo".equals(codeC.getDefaultExtension()) ) {   
  21.                               LzoIndexer lzoIndexer = new LzoIndexer(new Configuration());   
  22.                               lzoIndexer.index(dstPath);   
  23.                       }   
  24.                 }   
  25.                 return null;   
  26.               }   
  27.     });   
  28. }  


2.3 提升HdfsSink的电源开关
美团在HdfsSink和DualChannel中提升电源开关,当电源开关开启的状况下,HdfsSink已不往Hdfs上写数据信息,而且数据信息只写向DualChannel中的FileChannel。以此对策来避免Hdfs的一切正常停机维护保养。

2.4 提升DualChannel
Flume自身出示了MemoryChannel和FileChannel。MemoryChannel解决速率快,但缓存文件尺寸比较有限,且沒有长久化;FileChannel则恰好相反。美团期待运用二者的优点,在Sink解决速率够快,Channel沒有缓存文件过量系统日志的情况下,就应用MemoryChannel,当Sink解决速率跟不上,又必须Channel可以缓存文件下运用端推送过来的系统日志时,就应用FileChannel,由此美团开发设计了DualChannel,可以智能化的在两个Channel之间切换。

其实际的逻辑性以下:

Java Code拷贝內容到剪贴板
  1. /***  
  2.  * putToMemChannel indicate put event to memChannel or fileChannel  
  3.  * takeFromMemChannel indicate take event from memChannel or fileChannel  
  4.  * */  
  5. private AtomicBoolean putToMemChannel = new AtomicBoolean(true);   
  6. private AtomicBoolean takeFromMemChannel = new AtomicBoolean(true);   
  7.   
  8. void doPut(Event event) {   
  9.         if (switchon && putToMemChannel.get()) {   
  10.               //往memChannel中写数据信息   
  11.               memTransaction.put(event);   
  12.   
  13.               if ( memChannel.isFull() || fileChannel.getQueueSize() > 100) {   
  14.                 putToMemChannel.set(false);   
  15.               }   
  16.         } else {   
  17.               //往fileChannel中写数据信息   
  18.               fileTransaction.put(event);   
  19.         }   
  20.   }   
  21.   
  22. Event doTake() {   
  23.     Event event = null;   
  24.     if ( takeFromMemChannel.get() ) {   
  25.         //从memChannel中取数据信息   
  26.         event = memTransaction.take();   
  27.         if (event == null) {   
  28.             takeFromMemChannel.set(false);   
  29.         }    
  30.     } else {   
  31.         //从fileChannel中取数据信息   
  32.         event = fileTransaction.take();   
  33.         if (event == null) {   
  34.             takeFromMemChannel.set(true);   
  35.   
  36.             putToMemChannel.set(true);   
  37.         }    
  38.     }   
  39.     return event;   
  40. }  


2.5 提升NullChannel
Flume出示了NullSink,能够把不必须的系统日志根据NullSink立即抛弃,不开展储存。但是,Source必须先将events储放到Channel中,NullSink再将events取下丢掉。以便提高特性,美团把这1步移到了Channel里边做,因此开发设计了NullChannel。

2.6 提升KafkaSink
为适用向Storm出示即时数据信息流,美团提升了KafkaSink用来向Kafka写即时数据信息流。其基础的逻辑性以下:

Java Code拷贝內容到剪贴板
  1. public class KafkaSink extends AbstractSink implements Configurable {   
  2.         private String zkConnect;   
  3.         private Integer zkTimeout;   
  4.         private Integer batchSize;   
  5.         private Integer queueSize;   
  6.         private String serializerClass;   
  7.         private String producerType;   
  8.         private String topicPrefix;   
  9.   
  10.         private Producer<String, String> producer;   
  11.   
  12.         public void configure(Context context) {   
  13.             //载入配备,并查验配备   
  14.         }   
  15.   
  16.         @Override  
  17.         public synchronized void start() {   
  18.             //原始化producer   
  19.         }   
  20.   
  21.         @Override  
  22.         public synchronized void stop() {   
  23.             //关掉producer   
  24.         }   
  25.   
  26.         @Override  
  27.         public Status process() throws EventDeliveryException {   
  28.   
  29.             Status status = Status.READY;   
  30.   
  31.             Channel channel = getChannel();   
  32.             Transaction tx = channel.getTransaction();   
  33.             try {   
  34.                     tx.begin();   
  35.   
  36.                     //将系统日志按category分序列储放   
  37.                     Map<String, List<String>> topic2EventList = new HashMap<String, List<String>>();   
  38.   
  39.                     //从channel中取batchSize尺寸的系统日志,从header中获得category,转化成topic,并储放于上述的Map中;   
  40.   
  41.                     //将Map中的数据信息根据producer推送给kafka    
  42.   
  43.                    tx.commit();   
  44.             } catch (Exception e) {   
  45.                     tx.rollback();   
  46.                     throw new EventDeliveryException(e);   
  47.             } finally {   
  48.                 tx.close();   
  49.             }   
  50.             return status;   
  51.         }   
  52. }  


2.7 修补和scribe的适配难题
Scribed在根据ScribeSource推送数据信息包给Flume时,超过4096字节的包,会先推送1个Dummy包查验服务器的反映,而Flume的ScribeSource针对logentry.size()=0的包回到TRY_LATER,此时Scribed就觉得错误,断掉联接。这样循环系统不断尝试,没法真实推送数据信息。如今在ScribeSource的Thrift插口中,对size为0的状况回到OK,确保后续一切正常推送数据信息。

3. Flume系统软件调优工作经验总结
3.1 基本主要参数调优工作经验
HdfsSink中默认设置的serializer会每写1行内行尾加上1个换行符,美团系统日志自身带有换行符,这样会致使每条系统日志后边多1个空行,改动配备不必全自动加上换行符;
lc.sinks.sink_hdfs.serializer.appendNewline = false
调大MemoryChannel的capacity,尽可能运用MemoryChannel迅速的解决工作能力;
调大HdfsSink的batchSize,提升吞吐量量,降低hdfs的flush次数;
适度调大HdfsSink的callTimeout,防止无须要的请求超时不正确;


3.2 HdfsSink获得Filename的提升
HdfsSink的path主要参数指明了系统日志被写到Hdfs的部位,该主要参数中能够引入文件格式化的主要参数,将系统日志写到1个动态性的文件目录中。这便捷了系统日志的管理方法。比如美团能够将系统日志写到category归类的文件目录,而且按天宇按小时储放:

lc.sinks.sink_hdfs.hdfs.path = /user/hive/work/orglog.db/%{category}/dt=%Y%m%d/hour=%H
HdfsS ink中解决每条event时,都要依据配备获得此event应当写入的Hdfs path和filename,默认设置的获得方式是根据正则表达式表述式更换配备中的自变量,获得真正的path和filename。由于此全过程是每条event都要做的实际操作,耗时很长。根据美团的检测,20万条系统日志,这个实际操作要耗时6⑻s上下。

因为美团现阶段的path和filename有固定不动的方式,能够根据标识符串拼接得到。然后者比正则表达式配对快几10倍。拼接定符串的方法,20万条系统日志的实际操作只必须几百毫秒。

3.3 HdfsSink的b/m/s提升
在美团原始的设计方案中,全部的系统日志都根据1个Channel和1个HdfsSink写到Hdfs上。美团看来1看这样做有甚么难题。

最先,美团看来1下HdfsSink在推送数据信息的逻辑性:

Java Code拷贝內容到剪贴板
  1. //从Channel中取batchSize尺寸的events   
  2. for (txnEventCount = 0; txnEventCount < batchSize; txnEventCount++) {   
  3.     //对每条系统日志依据category append到相应的bucketWriter上;   
  4.     bucketWriter.append(event);   
  5. }   
  6.   
  7. for (BucketWriter bucketWriter : writers) {   
  8.     //随后对每个bucketWriter启用相应的flush方式将数据信息flush到Hdfs上   
  9.     bucketWriter.flush();   
  10. }  

假定美团的系统软件中有100个category,batchSize尺寸设定为20万。则每20万条数据信息,就必须对100个文档开展append或flush实际操作。

其次,针对美团的系统日志来讲,基础合乎80/20标准。即20%的category造成了系统软件80%的系统日志量。这样对绝大多数系统日志来讲,每20万条将会只包括几条系统日志,也必须往Hdfs上flush1次。

上述的状况会致使HdfsSink写Hdfs的高效率极差。下图是单Channel的状况下每小时的推送量和写hdfs的時间发展趋势图。

鉴于这类具体运用情景,美团把系统日志开展了尺寸分类,分成big, middle和small3类,这样能够合理的防止小系统日志跟随大系统日志1起经常的flush,提高实际效果显著。下图是分序列后big序列的每小时的推送量和写hdfs的時间发展趋势图。

4 将来发展趋势
现阶段,Flume系统日志搜集系统软件出示了1个高能用,高靠谱,可拓展的遍布式服务,早已合理地适用了美团的系统日志数据信息搜集工作中。

后续,美团将在以下层面再次科学研究:

系统日志管理方法系统软件:图型化的展现和操纵系统日志搜集系统软件;
跟进小区发展趋势:跟进Flume 1.5的进展,另外回馈小区;