一、引言
企业的信息化,离不开各种业务系统的支持。业务系统数量大,系统异构明显。而无论什么系统,要进行有效的监控、维护、优化、改进,都离不开对日志的收集与分析。而一般的日志,都是存放在各自系统所在的服务器上。相关人员每天要进到各种各样的系统后台,查阅海量的日志信息。如果有一套工具,可以实时的将分布在不同节点、机器上的日志进行收集,供离线查阅或在线分析所用,那么就可以极大的减少人力投入,提升工作效率,提升企业的信息化水平。随着大数据技术的兴起,使得这一切都变为可能。
Flume是Apache基金会下的顶级项目。对于Flume,在其官网上有这样的一段描述:“Flume是一套分布式的、可靠的,可用于有效地收集,聚合和搬运大量日志数据的服务架构。它是基于流式数据的简单灵活的架构。它通过一系列可靠性机制和故障转移及恢复机制来实现强大的容错能力。使用简约、可扩展的数据模型,并允许在线分析应用程序”。可以基于Flume,来进行日志收集系统架构的设计。
二、初步设计
2.1、总体设计
该日志收集系统,负责收集所有接入到系统的日志信息,转化为流式数据,或者永久数据,供Storm、Hadoop等工具作为分析源。架构采用了Flume_NG作为基础构建。Agent层从各系统收集日志数据,使用loadBalance策略,将数据sink到中心路由服务器,中心服务器根据事先定义好的路由规则,将缓存在内存中的数据sink到相应的存储服务器中,供离线或在线分析所用。当然也可以不经过中心调度服务器,直接将clientAgent的日志信息持久化到HDFS或生成实时流数据供离线或在线分析。
如图2-1所示:
图2-1总体架构
2.2、模块分解
将整个架构拆分为三层,2-1图中,从左到右依次是源数据接入层,中心路由服务器,存储服务器。存储服务器分为流式存储服务器、HDFS分布式文件存储服务器,当然,也可以使Hbase这类数据库。采集到的存储服务器,最终提供给Hadoop这样的静态数据分析平台,或者Storm这样的流式数据分析平台来使用,抑或是其他平台。
2.2.1、源数据接入层
基于Flume_NG的架构,源数据接入层中的每一个clientAgent都是一个独立的Flume进程,由Source,Channel以及Sink三个组件构成。Source接收传递而来的Event并负责将Event转移到Channel(Channel是一段零时存储的格式化Event数据,根据其存储介质的不同,可以分为FileChannel,JDBCChannel,MemoryChannel等不同类型,其作用可能类似于Java中的PipeLine),Sink组件从Channel中获取数据,一个Sink只能从一个Channel中获取数据,而一个Source的数据可以存入多个Channel,实际上是同时复制了多份数据存入Channel中。
图2-2clientAgent
实际上,包括源数据接入层和中心调度服务器层,无论是clientAgent还是FlumeControllerAgent,主要都是由Source,Channel及Sink三个组件构成。源数据接入层的Sink组件获取到数据后,可以通过配置和编码实现定制化的功能,将数据sink到中心调度服务器的Source组件。基于系统可靠性和稳定性的考虑,需要在源数据接入层和中心调度服务器层之间实现loadBalance和重试机制。实现后,需要处理的各task均衡的负载在各中心调度服务器;同时,当某台中心调度服务器无法服务时,由clientAgent通过Sink组件将数据发送到另一台中心调度服务器。源数据服务层支持线性扩展,理论上,只需要在客户机上安装agent程序并进行相应的配置操作即可将新加的服务器日志加入日志处理队列。
2.2.2中心调度服务器
中心调度服务器层设计为服务器集群,在性能达到瓶颈时,同样可以采用线性扩展的方式对集群进行扩容,而这只需要变更配置文件及少许代码的修改而已。中心调度服务器的主要工作是接收来自数据源接入层的数据,根据路由规则将数据送到不同的存储服务器。
图2-3:FlumeControllerAgent
如图所示,数据从clientAgent传递到FlumeControllerAgent后,Source1、Source2、Source3中的数据将会汇聚到Channel中,作为Sinkhkdf,sinkkafka,sinkbypass的数据来源。当然,一个FlumeControllerAgent中也可以有多个Channel,用以实现不同数据的隔离。
2.2.3存储服务器
存储服务器,设计分为HdfsServer、KafkaServer、ByPassServer。HdfsServer分布式存储所有日志,可供Hadoop进行离线分析使用;KafkaServer可以存储某段时间的日志(可配置),同时为Storm框架提供实时的流数据,供实时在线分析;ByPassServer的本质也是一台Agent,负责为其他的框架提供实时的日志流,可以通过配置和少量编码将日志流sink到其他框架,供分析使用。
三、目前可能存在的问题
目前FLume_NG框架中,主要提供了下面的几种Channel:
Channel |
说明 |
Memory Channel |
Event数据存储在内存中 |
JDBC Channel |
Event数据存储在持久化存储中,当前Flume Channel内置支持Derby |
File Channel |
Event数据存储在磁盘文件中 |
Spillable Memory Channel |
Event数据存储在内存中和磁盘上,当内存队列满了,会持久化到磁盘文件(当前试验性的,不建议生产环境使用) |
Memory Channel的特点是速度快,高吞吐,缺点是容量有限,Agent死掉之后数据丢失;FileChannel的特点是容量高,数据完整性强,即使是Agent死掉,也可以恢复,缺点就是速度慢,单位时间吞吐量较低。JDBC Channel则可以提供持久化支持。Spillable Memory Channel由于是实验性的,不可贸然用于生产环境。
而Memory,JDBC,File三种Channel的任何一种,又不可能同时满足大缓存、高吞吐的系统要求,必须结合公司实际情况,对Channel进行个性化订制。当然,系统运行的初期在对处理速度和稳定性要求不高的情况下可以先使用他们上述三种。
四、预期效果
随着大数据技术的发展,其对于海量数据快速分析和处理的优势进一步显现。可以预期,日志收集系统的运行,将使得以往需要大量人力物力时间成本来完成的工作,可以在短时间内高效达成,至少有以下几点的优势:
1、异构系统海量日志的同时收集处理。
2、发现和预防问题的实时性大幅提升。
3、异常处理速度的大幅提升。
4、系统优化分析速度的大幅提升。
结语:大数据并非高不可攀,最大的拦路虎就是行动的意愿。
参考资料:
欢迎来到这里!
我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。
注册 关于