运维改革探索(一)：用多层级监控实现可视化运维

《运维改革探索(一)：用多层级监控实现可视化运维》要点：
本文介绍了运维改革探索(一)：用多层级监控实现可视化运维，希望对您有用。如果有疑问，可以联系我们。

作者介绍
朱祥磊,山东移动BOSS系统架构师,负责业务支撑系统架构规划和建设.获国家级创新奖1项、通信行业级科技进步奖2项、移动集团级业务服务创新奖3项,申请发明专利13项.

一、背景

当前运营商业务支撑系统正向云化发展,以某移动公司为例,近年先后进行了经分系统云化、大数据系统建设、BOSS云化,现正在进行CRM云化,同时构建企业级资源池.经过几年的探索,深刻感受到云化给业务支撑系统带来高效低成本的优点,但同时也对运维能力带来了更高的要求,针对传统架构下的运维管理模式已经越来越不适合云化下的要求,主要表现在：

1)监控问题：所管理的机器和进程数量越来越多,呈现几十倍增长,传统运维由于机器数量小,监控都是基于点的,但是云化后,点变为一个个集群,且集群内机器数量庞大,基于点的监控方式越来越难以满足大量机器运维管理需要.

2)工具问题：随着机器数量增加,基于脚本或基于传统的发布变更工具难以适应集群内大量机器运维的需要,无论在自动化程度、效率、灵活性、便捷性、安全管控等方面均存在问题,迫切需要改变,引入新的工具.

3)分析问题：数据助力运维,但是由于云化后,针对运维的有价值数据或日志分散在大量的机器集群上,难以像传统架构一样实现集中化分析和呈现,需要研究解决在分布式云化架构下的运维数据集中分析问题.

4)服务问题：“IT即服务”,随着云化的演进,对敏捷运维能力也提出了更高的要求,现有ITIL基于流程、按照不同专业展开的运维服务模式,难以适应云化资源池所需的跨专业运维模式,需要改变.

二、解决方案

为应对云化后运维模式带来的挑战,我们进行了积极的探索,参考互联网企业做法,引入相关开源和商用软件以及互联网企业的运维理念,结合运营商实际,初步构建了一套面向云化架构的可视化运维体系,并初步进行了落地运行,取得了较好的效果.

整体架构图如下：

下面将一一展开论述.

可视化运维的核心要点之一是要解决可视化业务监控度量的问题,我们经过近几年对云架构下各种监控手段和措施持续不断的摸索、改造、优化和完善,逐渐建成一套基于平台故障监控,平台性能监控,应用代码级诊断,应用端到端和业务体验监控于一体的多层级集群式监控系统,如下图：

第一级：业务体验监控.是直接面向一线用户感知的体验监控,通过对用户终端到服务端整条链路各个关键环节性能指标(如网络时延等)和各类错误进行全流程跟踪、监控,及时发现用户感知相关的各类问题.

第二级：应用端到端监控.通过构建业务支撑系统自身整体架构视图,并对每个节点部署监控元素,利用聚合、分组机制,能直接发现系统各个环节各个渠道的问题,便于快速定位问题和影响面,能支持上千台机器的集群规模.

第三级：应用代码级诊断定位.在发现应用性能、故障需要进一步深入定位时,可通过代码级诊断定位手段实现代码跟踪,快速确定真正问题点.

第四级：分布式平台性能监控.针对成千上万台机器集群规模的平台性能实现快速部署,实时监控手段,针对集群内平台性能相关的各个指标实现直观的判断和监控.

第五级：云平台故障监控.针对成千上万台基础设备,如小型机、x86、虚拟机等,构建统一的云监控平台,实现系统故障级别的管控.

通过构建上述五级监控,基本全涵盖了从“一线用户感知到后端运维”,从“应用整体视图到程序代码内部”,从“平台故障监控到平台性能监控”,各个维度的监控.

第一级：业务体验监控

目前支持业务体验监控的方式有很多,如镜像方式、代理方式、插件方式等,我们经过测试验证,最终选择用户端浏览器注入、服务端插件捕捉方式实现云化后的用户体验监控.相较其他方式,数据无丢失,度量更加真实可靠.

1、主要做法

上图是整体架构图,分布式代理负责向用户浏览器下发监控插件、收集用户感知数据；扩展引擎负责对用户感知数据处理和分析,最后在控制台集中展现.

以实体厅为例,监控组网和实现原理如下图所示.在Web服务器或应用程序服务器中启动用户体验功能,会改变服务器向用户返回的具体内容,主要包括在响应用户的页面头部增加了浏览器插件脚本的引用路径,便于用户在访问任何页面时均会加载浏览器插件,这个过程称为浏览器注入.该插件的主要作用是：捕捉用户行为及与服务器的关联关系、用户行为的响应时间及可以量化的性能指标(Apdex).

浏览器插件实现了对页面元素事件处理过程的抽象,首先,通过jQuery捕捉界面元素的单击、滚动及键盘敲击等具体行为,及该行为对应的服务器请求；其次,对每一次用户操作,插件会记录用户真实的响应时间,响应时间再进一步细分为客户端时间、网络时间和服务器处理时间等.与网络流量解码不同的是,代理方式无法获取数据包在网络上传输的精确时间,而只能通过带宽的实际评估计算出来,实现原理是：每5~10分钟会从用户浏览器自动发送1~10k大小不等的文件给服务端,根据响应时间评估带宽大小,再按照实际页面大小估算网络时间.

用户体验监控界面如下,以用户访问作为最小统计单位,得出用户每一次访问的感知情况,是满意、可容忍还是失望.对于每一次失望的访问可以呈现出具体原因,失望是因为哪一步操作而失望的.

（编辑：ASP站长网）