运维改革探索(二):构建可视化分布式运维手段
分析篇:利用大数据实时分析助力运维数据是金矿,随着云化的深入,价值数据之间分散到海量机器中,需要采用大数据技术进行集中化处理,并助力运维.我们公司进行了积极尝试,引入flume+kafka+spark+分布式内存库redis等开源技术自主进行大数据运维分析,取得了一定的效果. 整体架构如下图所示.考虑到来自业务系统的数据是多元化的,既包括了软、硬件基础设施日志数据,也包括各类应用服务的日志数据,这两类日志数据通过主机和分布式软件代理服务、分布式消息采集服务和分析服务处理后,以流数据的方式转给大数据平台和报表平台: 分布式数据(应用日志等)采集整个分布式采集分为如下四个部分:
以往,业务支撑网中的日志分布在各服务器上,每次检索要逐一登陆到各服务器操作,严重影响效率;同时,日志留存于操作系统本地,会受到存储空间限制而循环覆盖,导致重要数据丢失;由于对关键日志缺乏保护,也给监控、审计带来诸多困难. 随着业务发展,来自硬件、操作系统和中间件的日志量不断膨胀,独立而分散的日志管理模式已不能满足日益增长的维护需求,特别在事件回溯、问题分析及报表统计相关工作中,其基础数据均源自这些纷繁芜杂的日志单元,亟需形成统一管理、综合分析、集中展现的新型一体化管理机制.为此一直进行着日志集中化改造的尝试. 起初,以HTTP服务器日志统计为例,传统解决方式是定期(按5分钟、小时或天)截断日志,然后通过FTP上传到一台服务器统一处理,在有些日志的计算处理前需要考虑日志排序问题.这样的日志同步可以支持几台到几十台规模的并发服务,但当管理的服务器达到几十台,而有大量的服务器中间会有下线、上线或变更时,集中的日志定期同步更显得难于管理,且日志同步要避开白天的高峰,往往需要用凌晨的低峰时段同步,24小时下来,上G的日志同步也是风险很高的操作.而成为瓶颈的日志排序合并操作也会妨碍其他后续计算的周期.其逻辑架构如下所示. 目前实现了应用分布但日志集中的远程存储模式,通过UDP协议实现小局域网内的日志广播,然后在多台汇聚服务器上实现各种日志的并发计算.如图所示: 为保证日志流传输的可靠性,对整个传输链进行了改造,实现了多个特性:非阻塞的适配器、网络划分、负载均衡、传输高可用性、传输监控能力及可以动态调整的Push/Polling模式. (编辑:开发网_新乡站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |