作者介绍山东移动BOSS系统架构师朱祥磊，负责业务支撑系统架构的规划建设.获得国家创新奖1项，通信行业级科技进步奖2项，移动集团级业务服务创新奖3项，申请发明专利13项。一、背景目前的运营商业务支撑系统正在向云端发展。以某移动公司为例，近年来先后进行了经济子系统的云化、大数据系统的建设、BOSS的云化。企业级资源池。经过几年的摸索，我深切感受到云化给业务支撑系统带来了高效率、低成本的优势，但同时也带来了对运维能力的更高要求。传统架构下的运维管理模式越来越不适应云化的要求，主要表现在：1）监控问题：被管理的机器和进程数量越来越多，呈现几十倍生长。传统运维由于机器数量少，监控以点为单位，但云化后，点变成了集群，集群中的机器数量巨大，基于点的监控方式越来越难以满足大量机器运维管理的需求。2）工具问题：随着机器数量的增加，基于脚本或者传统的releasechange工具很难适应集群中大量机器运维的需求，无论是自动化程度，效率、灵活性、便利性、安全控制等问题，急需改变，引入新的工具。3）分析问题：数据辅助运维，但云化后，对运维有价值的数据或日志分散在大量的机器集群上，难以像传统架构那样实现集中分析和呈现。云化架构下运维数据集中分析。4）服务问题：“IT即服务”，随着云化的演进，对敏捷运维能力提出了更高的要求。现有的基于流程、按不同专业开展的ITIL运维服务模式难以适应云资源池所需的跨专业运维模式需要改变。2.解决方案为应对云化后运维模式带来的挑战，我们积极探索，参考互联网公司的做法，引入相关开源和商业软件以及互联网公司的运维理念，结合运营商的实际情况，初步构建了一套面向云架构的可视化运维系统，并初步投入运行，取得了良好的效果。整体结构图如下：下面将一一讨论。3、监控：实现多级集群业务监控和可视化运维的核心点之一就是解决可视化业务监控和度量问题。经过几年对云架构下各种监控方式和措施的不断探索、改造、优化和改进，逐步构建了基于平台故障监控、平台性能监控、应用代码级诊断、应用端的多层次集群监控体系-到端和业务体验监控，如下图所示：Level1：业务体验监控。是一种直接面向一线用户感知的体验监控。通过跟踪监控用户终端到服务器整个链路中各个关键环节的性能指标（如网络延迟等）和各种错误，可以及时发现与用户感知相关的问题。各种问题。级别2：应用程序端到端监控。通过构建业务支撑系统自身的整体架构视图，并将监控元素部署到各个节点，利用聚合和分组机制，可以直接在系统各个环节的各个通道发现问题，便于快速定位问题和解决问题。影响范围大，可以支持千机集群规模。Level3：应用代码级诊断定位。当应用性能和故障需要进一步深入定位时，可以采用代码级的诊断和定位方法，实现代码跟踪，快速确定真正的问题所在。第4级：分布式平台性能监控。实现对数万台机器集群平台性能的快速部署和实时监控手段，实现对集群内与平台性能相关的各项指标的直观判断和监控。第五层级：云平台故障监控。针对小型机、x86、虚拟机等上千种基础设备，构建统一的云监控平台，实现系统故障级别管控。通过构建上述五级监控，基本涵盖了从“一线用户感知到后端运维”、“应用整体视图到程序代码内部”、“平台故障监控”的各个环节到平台性能监控”。Level1：业务体验监控目前支持业务体验监控的方式有很多，比如镜像、代理、插件等，经过测试验证，我们最终选择客户端浏览器注入和服务端插件抓包实现云化用户体验监控。与其他方法相比，没有数据丢失，测量更真实可靠。1.主要途径上图是整体架构图。分布式代理负责向用户浏览器下发监控插件，收集用户感知数据；扩展引擎负责对用户感知数据进行处理和分析，最终集中展示在控制台上。以实体馆为例，监控网络及实现原理如下图所示。在web服务器或应用服务器开启用户体验功能，会改变服务器返回给用户的具体内容，主要包括在响应用户的页面头部添加浏览器插件脚本的引用路径，所以即用户可以访问加载了浏览器插件的任何页面，这一过程称为浏览器注入。该插件的主要功能是捕捉用户行为与服务器的关系，用户行为的响应时间和可量化的性能指标（Apdex）。浏览器插件实现了页面元素事件处理过程的抽象。首先，通过jQuery捕获界面元素的点击、滚动、键盘敲击等具体行为，以及该行为对应的服务器请求；其次，对于用户的每一次操作，插件都会记录用户的真实响应时间，响应时间进一步细分为客户端时间、网络时间、服务器处理时间。与网络流量解码不同，代理方式无法获取数据包在网络上传输的准确时间，只能通过对带宽的实际评估来计算。实现原理是：每隔5~10分钟会自动向服务器发送1~10k个不同大小的文件，带宽大小根据响应时间估算，网络时间根据实际页面大小估算。用户体验监控界面如下，以用户访问为最小统计单位，获取用户对每次访问的感受，是满意的、可以忍受的，还是令人失望的。对于每一次失望的访问，都可以提出具体的原因，失望是由于哪一步操作造成的。找到导致用户不满意的操作后，就可以分析操作不满意的原因，是网络共享还是服务器共享。对于用户感知较差的接入，可以通过带宽来评估用户可能的带宽大小，如下图：2.效果示例1）建立直观的用户感知评估体系。在用户感知评价体系中，响应速度最为关键。基于用户体验的监控为评估系统提供了有效的数据，例如业务处理操作复杂度、交互速度、业务处理成功率和转化率等，如下图所示。一段时间内的业务体验详情：2）实现对用户访问性能和地市级服务质量的监控：级别2：应用端到端的用户体验监控，重点是对用户行为及相关业务的监控，以深入了解云架构应用各环节的运行状态，提升维护效率，还需要构建全业务、全渠道、端到端的业务整体监控体系监控视图，实现领导视图和运维视图的统一架构。通过引入TAP+开源数据库（Mongodb）+Spark流处理技术，在云服务器上实时动态采集网络流量，根据代码规范和业务对数据进行过滤、去重、解码、分析、计算和交易规则，最终实现基于整体业务视图层面的动态监控，为后端运维提供快速高效的支持。整体架构如下：1.基本原理及实现过程：1)业务配置：从业务通道维度出发，根据业务接入关系，梳理出系统部署图和业务关系视图，包括相互接入能力开放平台的系统部署和应用接入视图：监控云服务器的数据通过自动部署探针，进行初步过滤并汇聚到TAP交换中心，流处理中心根据各个业务组件探针从TAP交换中心抓取数据，并转换成原始数据包。其次，解码器根据TCP会话标识（flowid）将不同组件的原始数据包关联成一个完整的会话流，并根据编码规范对关联的数据包进行协议解码，生成原始交易记录；最后，处理引擎根据配置的业务规则生成原始交易记录，从原始交易记录中提取业务信息（如类型、渠道等关键字），分析生成业务指标记录，并将结果传递给负责人用于存储的网络显示引擎。3）动态监控：指标展示引擎（exporter）获取数据后，将结果实时更新到前端web的相应组件。目前，我们已经实现了NGCRM、客服、线上大厅、商城、短厅、一级老板、渠道的监控便利店、终端管理平台、移动工作台、自助等关键业务渠道的应用级监控-业务终端、能力开放平台：4）指标统计：告警模块（alerter）轮询数据库中的记录，根据业务配置基线和阈值生成趋势报告，并生成告警信息。2.主要特点1)灵活、高效、快速部署应用视图级监控基于网络数据，可以自动发现应用组件（如IP地址、服务端口、应用协议等）之间的连接和访问关系，非常适合云架构下敏捷业务监控部署，整体步骤仅需3步：2）可视化运维，快速定位基于动态运营视图，所有组件指标（如业务量、成功率等）的波动率、响应时间等）和基线可以实时抓取和跟踪告警，相比传统的基于拉网的逐一排查方式，运维人员可以快速准确定位故障，数据指标还可以应用于服务质量评价和变化趋势分析。3）自动关联，端到端跟踪通过不同应用组件之间事务的自动关联，可以深入到业务系统中，详细分析业务中各个应用之间的交互运行轨迹和交互关系，并实现问题回溯和快速定位，可以基于手机号等业务关键词进行深度挖掘和分析：4）智能模拟告警，更精准的告警提供模拟器功能，可以自动调整告警阈值，与历史进行对比问题，最终得到一个比较合理的报警阈值。Level3：代码级问题诊断无论是业务体验监控还是应用端到端监控，都是粗粒度的监控。需要更细粒度的诊断工具。为此，我们引入代码级业务监控方式，解决应用云化后复杂环境下的问题定位和诊断场景。1.总体架构代码级监控系统基于JVMTI（VirtualMachineToolInterface）技术实现。整体架构如下图所示。JVM是迄今为止使用最多的跨平台运行环境。在此基础上，JVMTI接口具备了更好的底层Implantation能力，将JVMTI接口封装成不同业务的sensor，通过agent插件调用，抓取代码级数据。2.用于故障诊断和性能分析基于JVMTI的监控工具可以在服务器端跟踪监控任何用户请求的代码轨迹。通过栈上各层函数的耗时对比，可以快速找出执行热点，定位问题的性能根源。同时，为被调用函数启用传入传出参数的捕获，可以提供对业务执行过程中快照的详细了解，有助于在业务层面定位问题。下图是我们的JVMTI代理插件的部署逻辑图。应用场景示例1：6月份，通过代码级监控定位到智能营销平台的性能问题。通过便利店调用营销平台交易通常需要1~2分钟，消耗了服务器上大量的线程池资源。同时，在业务系统调用便利店流程中，使用了同步阻塞调用，多次影响用户体验。CPU采样分析发现91.6%的性能损失发生在应用服务器层，进一步向下钻取到底层发现程序试图遍历一个非常大的ArrayList，导致执行效率低下。解决方案是：使用更高效的hash集合来代替ArrayList，如下图：应用场景示例2：通过代码级监控，发现是低版本log4j组件导致的线程死锁导致青岛自助终端短时间无法登录，如下图：Level4：集群平台性能监控除了上述服务和应用的监控方式之外，为了直观的进行以及每个集群数百台机器和分区的高效集中监控和告警，引入开源软件Ganglia和Nagios并对其进行定制，构建适合云化系统的集群平台性能监控。目前已实现对大数据集群、北斗集群、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：部署在server端，定时从data_source中拉取gmond收集的数据。在每个集群中选择一个节点，定义为data_source；ganglia-web：部署在服务端，将监控数据下发到网页。2）Nagios系统架构Nagios主要包括nagios守护进程、插件（plugins）和NRPE模块，如下图所示。Nagios按照设定的周期调用插件查看监控对象状态。执行check_nrpe并指定参数（check命令，如check_disk）告诉远程监控节点的NRPE守护进程需要检查哪些指标。NRPE运行各种本地插件进行检测，然后将检测结果返回给check_nrpe。服务器端维护一个队列，所有返回的状态信息都进入队列。状态信息有4种，即0(OK)表示正常状态/绿色，1(WARNING)表示警告/黄色，2(CRITICAL)表示严重错误/红色，3(UNKNOWN)表示未知错误/深黄色。Nagios根据插件返回的值判断监控对象的状态，并通过web显示出来。同时调用报警脚本smswarn发送报警短信。同时还可以配置邮件告警通知。3)已实现的监控节点列表目前云平台性能监控系统监控的节点如下，分为19个集群：3.云平台性能监控效果1)Ganglia效果示例通过建立基于Ganglia的性能监控平台，改变了对平台性能监控的认识，大大提高了监控水平。如下：一个界面就可以实现整个集群运行趋势的概览：下面是云集群中每台机器的运行状态，有几十种指标可选：2）Nagios效果示例Level5：平台故障监控解决业务和平台性能监控问题，还需要解决硬件和OS层面的监控问题。由于云化的不断深入发展，设备种类繁多，尤其是x86。各种设备的快速增长，传统的监控方式、机房巡检等难以维护，规模越来越大，已经不能满足工作要求。为了解决这个问题，我们搭建了一个全新的基于硬件和OS层故障的云监控告警平台。采集、事件解析分析，最终通过与BOMC集成实现业务信息关联和告警展示。下图是硬件报警平台的部署架构图。最底层是硬件层，包含各种被监控对象和各种设备。第二层为硬件MIB层，采用分布式架构，利用分布式采集、分布式SNMP协议等技术实现海量硬件设备的告警数据采集。第三层为故障分析分析层，采用国际标准MIB规范故障分析分析流程。顶层是显示层。具体部署架构如下：以下是几个展示示例：集中故障展示：OS和虚拟机层面的详细展示：hypervisor层的存储池监控：
