系统日志设计方案[系统日志的作用]

　　文 | 陈建伟@中兴大数据

　　日志可以反映应用系统的运行状况和用户行为，并且随着是互联网技术和人工智能的发展，日志的采集分析方式更加多样，采集分析系统的作用越来越大，甚至可以认为日志采集分析是大数据的基石。

　　下面主要介绍一种基于Flume-ng的分布式日志采集分析系统，该系统具有高可用性、可靠性、扩展性等特点。

　　系统结构

　　图1 所示为一种基于Flume的分布式日志采集分析系统整体框架图：

图1 整体框架图

　　整个系统分为三层：Agent层，Collector层和Storage层，下面将逐一介绍。

　　Agent层

　　Agent层每个机器部署一个Flume-ng单节点进程，负责对单机的日志收集整理。

　　为了方便理解，先简单介绍下Flume-ng（下文简称Flume）：

　　Flume以agent为最小的独立运行单位，每一个agent即是一个小的JVM。Flume由不同类型的Source、Channel、Sink 组件组成，不同类型组件之间可以自由组合从而构建复杂性的系统。Source实现对原始日志的采集接收，Channel 负责为Source 和 Sink 的对接提供临时的缓存通道，Sink则负责将收集到的日志下放到存储、分析等系统中，以实现日志的最终交付。如图 2 所示是摘自Flume官网的，是最基础的采集存储系统的架构图：

图 2 Flume基础架构图

　　Flume具备高可扩展性，支持多级流处理，可根据不同业务需求及功能需求对Flume的agent组件进行不同方式的组合，从而构建出耦合度低、可用性高、扩展性强的健壮的采集系统。如图 3 即是摘自Flume官网的复杂的Flume流，通过Channel、Sink 和不同的分析存储系统及Source组合完成复杂的采集分析任务。

图 3 Flume复杂流图

　　本文的分布式采集分析系统的agent层每个节点的框架如图 4 所示：

图 4 Agent层框架图

　　每个节点的使用了最新的1.7.0版本的Flume。下面就每个节点的source，channel，sink配置逐一介绍下：

　　Source

　　选用tailDirSource, 这个是1.7版本新增特性，可以递归地监听配置目录的动态变化的文件。目前采集分析系统应用的大数据管理系统，其中各个组件同类型日志类型差异大，而最后又都需要对应ElasticSearch中field。所以，在每个source都根据日志类型增加了MorphlineInterceptor，定义日志的grok和filed匹配规则，从日志中解析对应filed的字段信息。具体配置信息如下：

　　Source配置：

　　Morphline配置：

　　dictionary配置：

　　Channel

　　选用SpillableMemoryChannel，这种channel优先将evnet放在内存中，一旦内存达到设定的容量就使用file channel写入磁盘。然后读的时候会按照顺序读取：会通过一个DrainOrderQueue来保证不管是内存中的还是溢出(指的是内存channel已满，需要使用file channel存储数据)文件中的顺序。这个Channel是memory channel和file channel的一个折中，虽然在内存中的数据仍然可能因为进程的突然中断而丢失，但是相对于memory channel而言一旦sink处理速度跟不上不至于丢失数据(后者一旦满了爆发异常会丢失后续的数据)，提高了数据的可靠性；相对于file channel而言自然是大大提高了速度，但是可靠性较file channel有所降低。

　　Channel配置：

　　Sink

　　选用avro类型的sink，同时使用Flume的Failover Sink Processor特性，通过它维护了一组collector优先级列表，agent上报上来的日志会发送至优先级别高的collector中，如果优先级别高的collector异常无法提供服务，那么会发送给其他的collector，从而达到故障转移的效果。

　　Sink配置：

　　Collector层

　　Collector层，负责接收Agent层发送的日志，并且将日志根发送到Storage层。通过Agent层的faild voer策略转发到Collector层，大大增加了系统的可靠性。Collector层仍然选择Flume-ng实现。具体框架如图 5 所示：

图 5 collector框架图

　　Collector层每个collector节点都较为简单，avro类型的source 接受各个agent上报上来的日志，通过SpillableMemoryChannel类型的channel，最后由ElasticSearchSink写入到Storage层的ElasticSearch。

　　Collector配置：

　　Storage层

　　Storage层基于ElasticSearch，不仅提供日志存储，还可以提供全文检索、分析聚合等功能。ElasticSearch是一个实时的分布式搜索和分析引擎，功能强大，限于篇幅，不在本文展开。

　　设计考虑

　　系统的可用性

　　可用性(availablity)指固定周期内系统无故障运行总时间。影响采集系统可用性的主要就Agent和Collector宕机两种情况。

　　Agent宕机

　　Agent宕机分为两种情况：主机死机或者Agent进程死掉。

　　对于主机死机的情况来说，由于产生日志的进程也同样会死掉，所以不会再产生新的日志，不存在不提供服务的情况。

　　对于Agent进程死掉的情况来说，确实会降低系统的可用性。对此，我们也做了一些保护来提高系统的可用性。例如，对agent进出增加了看门狗进程，如果进程死掉会被agent立即重启。当然，如果是非常重要的日志，会考虑直接使用FileChannel。

　　Collector宕机

　　由于Collector层每个collector是对等的，都能提供服务，overfaild策略下，当某个Collector无法提供服务时，Agent的重试策略会将数据发送到其它可用的Collector上面。所以整个服务不受影响。

　　系统的可靠性

　　可靠性(reliability)是指Flume在数据流的传输过程中，保证events的可靠传递。

　　根据官方说明，Flume提供数据流中点到点的可靠性保证，当且仅当它们被保存到下一个Agent的Channel中或者被保存到最终的存储服务之后才会删除Channel中的event。

　　系统的扩展性

　　可扩展性(scalability)是指系统能够线性扩展。当日志量增大时，系统能够以简单的增加机器来达到线性扩容的目的。

　　对于本文基于Flume的日志收集系统来说，需要在设计的每一层，都可以做到线性扩展地提供服务。

　　Agent层

　　对于Agent这一层来说，每个机器部署一个Agent，可以水平扩展，不受限制。

　　Collector层

　　对于Collector这一层，Agent到Collector是有Load Balance机制，并且Collector提供无差别服务，所以可以线性扩展。

　　Storage层

　　对于Store这一层来说，ElasticSearch是分布式系统，可以做到线性扩展。

　　总结

　　本文介绍了一种基于Flume-的分布式日志采集分析系统，轻量，并且具有高可用、高可靠、可扩展的特点。分布式日志采集分析系统有多种实现，例如基于ELK(ElasticSearch、LogStack、Kibanna)或者基于Flume、Kafka、Elasticsearch、Storm的采集分析系统，都有各自优缺点和适用场景。针对不同的场景，还是需要具体问题具体分析，本文提供一种思路，仅供参考。

　　大数据时代的思考和洞察

　　长按二维码关注

标签：系统日志作用方案设计