运维改革探索(二)：构建可视化分布式运维手段(3)

分析篇：利用大数据实时分析助力运维

数据是金矿,随着云化的深入,价值数据之间分散到海量机器中,需要采用大数据技术进行集中化处理,并助力运维.我们公司进行了积极尝试,引入flume+kafka+spark+分布式内存库redis等开源技术自主进行大数据运维分析,取得了一定的效果.

整体架构如下图所示.考虑到来自业务系统的数据是多元化的,既包括了软、硬件基础设施日志数据,也包括各类应用服务的日志数据,这两类日志数据通过主机和分布式软件代理服务、分布式消息采集服务和分析服务处理后,以流数据的方式转给大数据平台和报表平台：

分布式数据(应用日志等)采集

整个分布式采集分为如下四个部分：

• 数据采集：负责从各个节点上实时采集日志数据,可以指定目录或文件,通过flume实现,仅增量采集数据.
• 数据接入：由于上述采集数据的速度和数据处理的速度不一定同步,增加分布式消息曾作为缓冲,防止丢失数据,采用kafka.
• 流式处理：对采集的数据进行实时分析,选用spark-streaming+redis实现.
• 数据输出：对分析结果存储在mysql数据库中,并进行告警展示.

以往,业务支撑网中的日志分布在各服务器上,每次检索要逐一登陆到各服务器操作,严重影响效率；同时,日志留存于操作系统本地,会受到存储空间限制而循环覆盖,导致重要数据丢失；由于对关键日志缺乏保护,也给监控、审计带来诸多困难.

随着业务发展,来自硬件、操作系统和中间件的日志量不断膨胀,独立而分散的日志管理模式已不能满足日益增长的维护需求,特别在事件回溯、问题分析及报表统计相关工作中,其基础数据均源自这些纷繁芜杂的日志单元,亟需形成统一管理、综合分析、集中展现的新型一体化管理机制.为此一直进行着日志集中化改造的尝试.

起初,以HTTP服务器日志统计为例,传统解决方式是定期(按5分钟、小时或天)截断日志,然后通过FTP上传到一台服务器统一处理,在有些日志的计算处理前需要考虑日志排序问题.这样的日志同步可以支持几台到几十台规模的并发服务,但当管理的服务器达到几十台,而有大量的服务器中间会有下线、上线或变更时,集中的日志定期同步更显得难于管理,且日志同步要避开白天的高峰,往往需要用凌晨的低峰时段同步,24小时下来,上G的日志同步也是风险很高的操作.而成为瓶颈的日志排序合并操作也会妨碍其他后续计算的周期.其逻辑架构如下所示.

目前实现了应用分布但日志集中的远程存储模式,通过UDP协议实现小局域网内的日志广播,然后在多台汇聚服务器上实现各种日志的并发计算.如图所示：

为保证日志流传输的可靠性,对整个传输链进行了改造,实现了多个特性：非阻塞的适配器、网络划分、负载均衡、传输高可用性、传输监控能力及可以动态调整的Push/Polling模式.

无论是网络设备、应用服务器还是中间件,其日志需要与Flume节点对接,这就涉及到协议适配的问题,为此专门针对企业总线(eBus、UAP)、前端Web容器及交易中间件配置协议适配驱动,将日志以流的方式传输给Flume代理,协议适配层提供了较丰富的协议适配驱动,能够支持来自各层面基础设施的日志数据对接,目前已成功接入的基本组件有交换机、负载均衡器、各刀片服务器操作系统及应用程序,如图所示：

当采用适配器连接Flume代理时,应用服务会调用异步附加组件AsyncAppender输出日志流,如果Flume代理宕机,且无备份节点时,会导致应用服务器阻塞,我们针对一些适配器配置了non-Blocking特性参数,当启用此参数时,即使日志流写入失败,不会影响正常业务运行.

为确保基于UDP广播的传输模式不会形成网络风暴,我们按照不同的业务范畴、不同的组件类型划分子网,同一子网内的应用服务器仅与当前子网的Flume代理通信.在高可用性方面,应用服务器以UDP协议在子网内广播日志数据,UDP包被多个Flume代理节点截获,某一时刻仅有一个Flume Agent处于Active状态,其他为Standby,当Flume节点宕机时,其他节点可以无缝接替继续工作,所有Flume Agent通过Flume Master节点管理,实现主备接管和配置同步功能.如图所示：

(灰色框为备机)

为便于维护人员及时了解日志传输的工作状态,对Flume的相关命令进行了封装,在统一界面上展现来自Flume不同端口的数据接收情况.

对于超大规模的营业厅前端用户交互日志采集,采用UDP、FTP方式可能会导致过高的网络、磁盘I/O资源消耗,因此首先保证整个架构过程中,除在汇聚服务器和日志中心外的Flume节点上均不产生文件落地,仅在汇聚服务器中实现了对来自多个Flume代理的数据聚合和排序.同时在业务高峰时段,日志采集处理能力有限,Flume代理会从Pushing模式切换为Pulling模式,即从采集转为采样.

2、实时数据聚合+分组

利用大数据集中处理平台的处理流程主要分两部分,通过消息队列处理Flume采集的日志,再通过ElasticSearch建立索引,最终将数据、索引导入在mysql集群.如下：

大数据平台主要分析营业厅与用户交互日志,其中包括实时的用户体验、服务器请求记录.用户体验日志是用户在浏览器中每一步操作的性能评估,主要包括用户每一步操作的名称(如点击按钮、键盘录入、下拉框的选择、复选框的勾选及页面刷新等)；用户操作整体响应时间及其构成部分：客户端响应时间(包括页面元素渲染时间、页面JavaScript脚本执行时间)、网络耗时(包括网络中的传输时延及第三方内容服务CDN的处理时间)、服务器运行时间.通过用户体验日志可以了解到用户每一步操作的感知状况,准确了解性能故障对用户操作的影响；此外,用户操作和用户请求是相互关联的,通过关联关系可以找到每一步用户操作的具体含义,如(某一步操作是在缴费业务的录入用户号码操作).

（编辑：ASP站长网）