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

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

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

一、背景

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

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

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

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

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

二、解决方案

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

整体架构图如下：

下面将一一展开论述.

三、监控篇：实现多层级集群式业务监控

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

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

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

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

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

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

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

第一级：业务体验监控

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

1、主要做法

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

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

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

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

在找到引起用户失望的操作后,可以分析导致操作失望的原因,是网络份额还是服务器份额.对于用户感知较差的访问,可以通过带宽评估出用户可能的带宽大小,如下图：

2、效果举例

1)建立直观的用户感知评价体系.在用户感知评价体系中,响应速度最为关键,基于用户体验的监控为评价体系提供了有效数据,如业务办理操作复杂度、交互速度、业务办理成功率和转化率等,如下图所示,某时段内业务的体验详细情况：

2)实现用户访问性能和地市服务质量的监控：

第二级：应用端到端监控

用户体验偏重用户行为和相关业务的监控,为深入了解云化架构下的应用各个环节的运行情况,提升维护工作效率,还需要构建一套面向全业务、全渠道、端到端的业务监控系统,用于整体业务监控视图,实现领导视图和运维视图合一的架构.

我们通过引入TAP+开源数据库(Mongodb)+Spark流处理技术,对云服务器上网络流量进行实时动态采集,根据代码规范和业务规则对数据进行过滤、排重,解码,分析、计算和交易关联,最终实现基于业务整体视图级动态监控,为后端运维提供了快速、高效支撑.整体架构如下：

1、基本原理和实现过程：

1)业务配置：从业务渠道维度出发,根据业务访问关系,梳理出系统部署图和业务关系视图,包括系统内部相互之间访问关系、访问端口,组件属性,协议解码等,如下面是能力开放平台系统部署和应用访问视图：

2)数据采集和流处理：首先、系统通过自动部署探针捕获所有监控云服务器端原始数据后进行初次过滤后统一汇聚到TAP交换中心,流处理中心会根据每个业务组件探针从TAP交换中心捕获数据并转换为原始数据包.其次、解码器根据TCP会话标识(flowid)将不同组件的原始数据包关联成一个完整的会话流,并根据编码规范对关联后数据包进行协议解码生成原始交易记录；最后、处理引擎根据已配置的业务规则对原始交易记录进行业务信息(如类型、渠道等关键字)提取、分析生成业务指标记录并将结果传给负责web展现引擎后入库.

3)动态监控：负责指标展现引擎(exporter)获取到数据后,将结果实时更新到前台web相应组件,目前我们已经实现实现对NGCRM、客服,网厅、商城,短厅,一级BOSS,渠道便利店,终端管理平台,移动工作台,自助终端和能力开放平台等关键业务渠道应用级监控：

4)指标统计：告警模块(alerter)轮询数据库中记录根据业务配置基线和阀值生成趋势报告和告警信息.

2、主要特点

1)灵活、高效快速部署

应用视图级监控以网络数据为依托,能够自动发现应用组件之间连接性和访问关系(如IP地址,服务端口,应用协议等),非常适合云架构下的敏捷业务监控部署,整体步骤只需3步：

2)可视化运维,快速定位

基于动态运行视图可以实时捕捉并跟踪所有组件指标波动(如业务量、成功率、响应时长等指标)和基线告警,相比传统拉网式逐个排查方式,运维人员能够快速、准确定位故障,数据指标还可以应用于服务质量评测和变化趋势分析.

3)自动关联,端到端跟踪

通过不同应用组件间交易自动关联,可以跟踪深入到业务系统内部,详细分析业务内部各应用之间交互运行轨迹和交互关系,实现问题回溯和快速定位,可基于手机号等业务关键字做深入挖掘分析：

4)智能模拟告警,告警更准确

提供模拟器功能,可自动调整告警阈值,和历史上发生问题的情况对比,最终得到比较合理的告警阈值.

第三级：代码级问题诊断

无论是业务体验监控,还是应用端到端监控,都是粗粒度监控,在很多情况下,如出现应用性能等,尽管能及时发现问题,但是如何解决定位,还需要更加细粒度的诊断手段.为此,我们引入基于代码级的业务监控手段,用于解决应用云化后复杂的环境下的问题定位诊断场景.

1、整体架构

代码级监控系统基于JVMTI(虚拟机工具接口)技术实现,整体架构如下图所示,JVM是目前为止使用最多的跨平台运行环境,在此基础上构建JVMTI接口具有较好的底层植入能力,针对不同业务将JVMTI的接口封装成传感器,并由代理插件调用来捕获代码级数据.

2、用于故障诊断及性能剖析

基于JVMTI的监控工具可以追踪和监控任何一笔用户请求在服务器端的代码轨迹,通过对比堆栈上各层函数耗时,可以迅速找出执行热点,并定位到性能问题的根因.同时,对调用的函数启用出入参数捕获,可以详细了解业务执行时的快照,帮助定位业务层面的问题.下图为我们JVMTI代理插件部署逻辑图.

应用场景举例一：

在6月份通过代码级监控定位到智能营销平台性能问题,通过便利店调用营销平台交易通常在1~2分钟时间,消耗服务器大量线程池资源,同时在营业系统调用便利店过程中,采用了同步阻塞式调用,多次对用户体验造成影响.CPU采样分析发现91.6%的性能损耗发生在应用服务器层,进一步深入到最底层调用找到程序试图对一个超大的ArrayList进行遍历导致执行效率低下,解决方案是：采用更高效的哈希集合取代ArrayList,如下图：

应用场景举例二：

通过代码级监控发现低版本的log4j组件引发的线程死锁,导致青岛自助终端短时间无法登录,如下图：

第四级：集群式平台性能监控

除了上述业务和应用监控手段外,为了对各集群中成百上千台机器和分区进行直观高效的集中监控并告警,我们引入开源软件Ganglia和Nagios并进行定制,构建了一套适合云化的集群式平台性能监控系统.目前已经实现了对大数据集群、BDS集群、CRM共约520个节点的集中监控和告警,内容包括节点和服务状态、资源利用率、网络、IO流量等指标,以及Hadoop和HBase的各项性能指标.通过个性化定制,还可以方便地增加其他需要关注的指标项.

1、云化平台性能监控系统的优势

相比传统的网管监控,以及其他诸如nmon等性能监控手段,我们构建的分布式云平台性能监控系统具有以下几大优势：

• 图形化web界面,通过曲线对整个集群中设备的各项性能指标进行直观的展示,便于分析问题,发现性能瓶颈.而不是单点的展示.
• 层次结构清晰,通过定义对节点和服务分组、分类,逐级检查,适合大规模服务器集群.
• 存储性能指标数据,方便统计分析、生成和导出报表.
• 扩展性强,支持多种开发语言(shell、C++、Perl、Python、PHP等),用户可以方便的根据需要定制监控项目.

2、性能监控系统架构

我们构建的云化平台性能监控系统采用开源软件Ganglia(版本3.7.1-2)和Nagios(版本4.1.1).前者主要负责收集、展示性能指标数据,后者则侧重于告警机制.

1)Ganglia系统架构

ganglia主要有三个模块,如下图所示.

• gmond：部署在各个被监控节点上,定期收集节点数据,并进行广播或单播；
• gmetad：部署在服务器端,定时从data_source中拉取gmond收集的数据.在每个集群中选择一个节点定义为data_source；
• ganglia-web：部署在服务器端,将监控数据投递到web页面.

2)Nagios系统架构

Nagios主要包括nagios daemon、插件(plugins)和NRPE模块,如下图所示.

Nagios按照设置的周期调用插件来检查监控对象状态.执行check_nrpe,并指定参数(检查命令,比如check_disk),告诉远端被监控节点的NRPE daemon需要检查哪些指标.NRPE 运行本地的各种插件进行检测,然后把检测的结果返回给check_nrpe.服务器端维持一个队列,所有返回的状态信息都进入队列.共有4种状态信息,即 0(OK)表示状态正常/绿色、1(WARNING)表示出现警告/黄色、2(CRITICAL)表示严重错误/红色、3(UNKNOWN)表示未知错误/深黄色.Nagios根据插件返回来的值,判断监控对象的状态,并通过web展示.同时调用告警脚本smswarn,发送告警短信,同时,也可以配置邮件告警通知.

3)已实现的被监控节点列表

目前云化平台性能监控系统共监控如下节点,分为19个集群：

3、云化平台性能监控效果

1)Ganglia效果示例

通过建立基于Ganglia的性能监控平台,改变了对平台性能监控的认识,大大提升了监控水平.

如下：一个界面内可以实现整个集群的运行趋势概况：

下面是云集群内每个机器的运行情况,超过几十种指标可选：

2)Nagios效果示例

第五级：平台故障监控

解决了业务和平台性能的监控问题,还有硬件和OS层面的监控问题需要解决,由于云化的不断深入发展,各类设备很多,各种设备特别x86快速增长,传统监控方式、机房巡检等方式维护难度越来越大,已无法满足工作要求,为解决该问题,我们新建一套基于硬件和OS层故障的云监控告警平台,该告警平台基于国际MIB标准,通过SNMP协议方式实现海量设备故障数据自动采集,事件解析、分析,最终通过和BOMC融合实现业务信息关联和告警展现.

下图是硬件告警平台部署架构图,最底层是包含各类被监控对象,包含各类设备的硬件层面,第二层是硬件mib层,采用分布式架构,利用分布式采集、分布式snmp协议等技术实现海量硬件设备的告警数据采集,第三层为故障解析和分析层,利用国际标准MIB进行故障解析、分析流程标准化,最上一层为展示层.

具体部署架构如下：

下面是几个展示实例：

• 集中的故障展示：

• OS和虚拟机层面详细展示：

• hypervisor层存储池监控：

文章出处：DBAplus社群(订阅号ID：dbaplus)

转载请注明本页网址：
http://www.vephp.com/jiaocheng/4396.html