应用监控架构的实践

摘要：

当前业务系统持续更新完善，对于既有日志管理机制或预警系统而言，能否精确找出故障症结并即时发现细微偏差，对系统运行会造成何种后果？为业务提供完整性能跟踪与评估的需求日益凸显，本文依据《架构即未来》第三十一章“应用监控”所述的架构设计指导方针，并参照实际监控架构构思，提出应用性能监控体系构建方案，同时通过具体实例进行说明。

系统故障给公司带来的影响显而易见，与其把主要精力放在事后的补救措施上，不如在早期阶段就完善整体框架规划，同时建立业务执行情况的实时监测机制。

监控架构的核心思想

企业处于高速发展阶段时，业务系统也在持续进行更新换代，如果无法迅速发现系统扩展的短板，将会长期承受服务中断的困扰，毕竟任何微小的异常或程序错误出现，轻微时会损害用户体验，导致用户不断抱怨，严重时则可能造成系统事故，比如业务系统完全瘫痪这类毁灭性的问题。过往业务系统应急处理经验表明，事后源头分析揭示共性现象，即错误成因深藏不露，事故应对时难以迅速捕捉初始迹象，即便执行严格业务变更审核及DBA细致SQL审查，仍会存在一些难以察觉的问题，这类问题在常规业务回归测试中常被忽略，往往在生产运行一段时间后，才在某种特定条件下暴露出来。要想提前防范或在关键时刻解决潜在风险，保证业务量大幅增长时系统依然稳定，就必须考虑清楚，当前的日志管理工具和告警系统，能否准确找出故障源头，能否自动实时发现运行中的细微异常或偏差，以及这些因素会产生什么后果。

要想准确找到并掌握捕捉那些难以捉摸的目标，就必须借助监控体系的指导。要做成这件事，有行业背景的人或专业人士会说明，这首先需要大量信息进行搜集和查找，例如统一的大数据日志监控系统ELK，其次要有高效的应用性能管理工具，比如云智慧透视宝，进行全天候不间断的实时监控和分析，一旦发生状况能够做到秒级或毫秒级迅速定位问题，借助配套的自动检查分析功能，来筛选并确认一些微小的错误，再通过普遍存在的部分来排查应用代码，深究到底，查明潜在的风险是否是导致灾难的起因。比如设备出现异常，最先想到的是“是不是出故障了”，接着会问“具体是什么故障”，然后会探究“故障发生在哪个环节”，最后会分析“究竟是什么原因造成的”。随着对问题的逐步深入，需要回应和准备的信息也日益增多，这揭示了数据范围与问题精确度之间的密切关系，这也是架构设计者和故障排查人员必须思考的四个关键环节。

图一：数据体量同具体事项处理能力之间的关联性，源自 “《架构即未来》第三十一章 应用监控架构P31.3”

应用监控体系的关键理念在于协助管理人员摆脱当前困境：每当出现系统层面故障，就需要耗费大量时间来查找导致问题的根本原因，例如操作环节的疏漏、程序编写的不当、业务查询语句的违规使用等，这些问题的成因各不相同，必须通过多样化的应急措施加以应对，直至事后进行问题修正，最终实现故障处理的完整流程。看起来很合理，但持续这样循环，轻微的情况是会让商家或客户反复经历失败，正常的交易过程被打断，最终导致对产品失去信任；严重的情况是业务系统出现故障，会提高公司的管理费用，甚至削弱关键的技术部门能力。我们不妨换个角度考虑，首先要解决“问题出现前能否提前发现故障的警示或异常信号？”由此，形成了我们在设计业务应用监控体系时的主要理念，这也是为了向客户做出更优质的服务标准保证（SLA：服务等级协议）而进行规范化体系构建的关键环节。改善使用感受，系统的整体回应时刻与实际达成比率，这两项要素，是针对软件实施监督时，能够明确计算评估的基准条件。

监控系统的设计指导与框架模型

监控设计指导

要明确察觉到哪怕轻微的迟滞或许都指向次日局部中断或系统完全停摆，依照通用监控方案的原则，必须对业务系统进行分解：

针对IaaS平台，涵盖硬件基础设施、系统主机环境、数据存储系统、网络架构设施等，此外还涉及其他相关组件。

针对PaaS平台，涵盖SOA通用架构（包含SOA架构、Dubbo服务等），以及通用模块（例如缓存功能采用Redis模块、消息传递运用RabbitMQ模块等），还有公共服务功能模块或公共服务设施等

针对SAAS服务，例如涉及业务操作的网络连接，包括信息交互的通道，数据传输的接口，程序集成的工具包，移动端的软件应用，以及实时通讯的协议等。

系统架构要按层级划分，公司级监视平台的收集时间间隔，需精确到秒级或毫秒级，监测信息必须完整记录天、周、月、年的时段，过往监测资料必须完整保留三年以上，这也是关键监视系统最基础的必要条件。所设计的监控系统要明确的目标实体必须能真实呈现资源利用情况、运行效率问题、服务承诺标准，包括ART和EST等数据，如果是针对应用场景的监控平台，不仅需要全面展示应用软件或虚拟化环境中的JVM等关键数据，涵盖但不限于GRP:全局请求处理能力、忙碌线程数、JCA:Java连接可用性、最大请求时长、平均响应时长等，还必须能监测到网络服务器在运作时，各个功能模块的效率消耗情况，当系统出现异常时，能够回溯并找到问题根源，甚至能深入到具体函数的调用链，精确到每个数据点，这种业务监控体系构建得相当完备，也就是我们常说的监控系统的精细程度，同时还能对核心系统运行、业务活动、安全防护等关键数据进行前瞻性分析。

图二：通用监控系统设计指导思想

企业监控框架

企业内部的监控体系多会选用行业常见的架构进行搭建，这种架构要求监控功能、分析功能与控制功能三者高度整合，实现紧密衔接。从个人亲身体验来看，一个优秀的监控体系不仅能够依据当前状况和未来规划提供可靠的监测预警支持，还可以借助平台内即时或累积的系统运行或业务监测信息开展联动分析，识别出潜在的薄弱环节或未来的发展机遇，为系统优化提供关键的数据决策依据。

简单来说，监控系统框架分为如下三个部分：

统一监控：

基础层面的监管：选用开源或常用型监控系统，达成公共设施及系统维护的有效监管，例如OpenNMS-Cacti侧重网络方面；Zabbix/Hyerpic HQ侧重IaaS公共领域；监控宝专注网站、API等。任何监控平台都仅是确保系统完整生命周期的合理管理手段，对平台本身的推崇以及平台相关技术方案的选择，最可靠的准则在于全面掌握，触类旁通。没有哪一种监控手段可以满足所有企业的监管要求，必须根据具体情况定制，还要配合当前普遍应用的系统，并且要考虑到未来监控平台数据整合的需要，唯有能和DevOps协作的监控方案，才是最符合自身条件的。

性能监控运用得当：WebServer的基础运行状况各项数据之外，由代码缺陷或程序规划不周所导致的不同程度故障日益增多，企业方面业务代码的改动必须经过全面的覆盖性检测，有时在对外发布之后还要实施整体回归性检测，以及必要时进行性能压力性测试，然而仍有部分问题会逃脱审查，而且公司通常难以实现全天候的业务性能即时检测与分析，特别是在多种业务共享资源的情况下，具体的问题成因无法在短时间内迅速找到并加以解决，这也是以往业务监控的一个不足之处，怎样精确锁定到业务代码层面的故障和异常，获取的资讯能够直接为开发人员提供最原始的反馈信息，保证在业务高峰期到来之前能够准确发现并处理，我将在下文借助透视宝的实际操作来进一步阐述这个方面。

一套整合的运营记录系统：ELK（Elastic+Logstash+Kibana）已确立为业内典范或普遍选择，虽然市面上存在众多主流的商业化方案，但个人更倾向于由内部DevOps团队自主构建一套大数据类日志监察机制，这亦是互联网科技企业的技术基本要求，如此一来既能实现专属化设定与调整，亦可顺畅融入集团或机构的特殊业务监测需求。

开放的接口监控，可以完成业务接口的有效性检测，能够进行接口数据相关的故障解析，有助于实现系统的弹性评估，有助于进行损耗或过期评估，能够实现颗粒度细致的定位。

图三：企业级监控系统框架参考

APM应用性能监控系统介绍

做好代码层面的故障排查，必须借助高效的应用性能管理工具，确保全天候的业务状态监测，这种专业的监控手段对于保障业务成功上线后的稳定运行至关重要。

应用监控

实施监控十分关键，可用来解答具体为何如此的问题。多数情况下，要弄清具体是哪个问题，就必须专门设计监控程序，或者配备能监测代码的设备，若想做好这件事，或许需要把程序融入产品或业务流程中。有些代理会说明具体故障原因，例如磁盘故障引起的I/O系统迟缓，但缺乏能精确指出应用哪个环节出错的工具；成熟业务依赖的子系统，在经历几次业务代码调整后，比如公共组件Redis性能下降，所有使用这些公共组件的业务都会遭遇系统停滞或响应延迟的情况。那些完全自我修复的应用，在现实中几乎不可能实现，从研发周期的角度来看，也并非高性价比的选择，不过，应用能够对普遍发生的故障进行自我检测的想法，是一个值得赞赏且具备可行性的目标。

以Java系统为例，JVM自带了性能监控工具，但这类工具仅能分析Java本身的性能状况，因此必须依照我们的监控方案和框架，另建一套满足企业业务要求的应用性能监控体系，该体系需包含能精确锁定代码层级的监控功能，以及实时捕获异常业务SQL和事务的能力，同时整合可视化分析及预警机制，这样应用性能监控体系就能迅速、直接且高效地定位问题，并将核心信息清晰呈现给开发与运维人员。

比如现在有一个系统涉及A,B,C三个子系统间的交互方式，可能是通过Dubbo服务进行调用，也可能是运用HTTP、Hessian、API等接口，或者是借助Rabbit MQ消息队列，抑或是采用异步线程进行调用。总之，业务系统里的各个子系统之间的关联都借助了当前通行的技术来搭建，那么怎样找出A子系统的应用代码缺陷是如何经由B进而导致C出现故障的根本原因呢？

云智慧透视宝作为APM应用性能管理工具，具备性能监测分析功能，以云智慧透视宝为例，APM能够追踪复杂系统中的服务与代码性能问题，自动识别全局应用拓扑结构，提供端到端的应用分析视角，实现失误监控与问题分析，支持SQL脚本性能评估，代码堆栈捕获，以及事务深度跟踪，从而协助开发等部门提高工作效率。

透视宝APM监控架构思路

APM数据采集架构设计

应用监控结构思路：

通过Sendproxy作为调度中心，透视宝负责收集SmartAgent的数据，这些数据经由Sendproxy统一安排后发送，最终汇集到集中的大数据日志分析平台进行解析。

其主要优势在于：

发送队列保证各插件数据发送的稳定性;

能够充当中介，安装在可以访问外部网络的服务器上，确保在内部网络无法连接互联网的情况下，依然可以传输数据。

APM部署调试

1、客户端简易安装

进入透视宝网页版管理界面，前往系统设定部分，获取适配当前机器系统的智能代理程序，接着开展智能代理的部署工作，并开启其运行状态。

管理员@sjm6-3G-qatest01-30 正在智能代理系统下操作

# ./SmartAgent.sh start

启动SmartAgent守护进程：SmartAgent

重新启动智能代理发送代理守护进程：程序目录下SendProxy

没有服务器在运行，路径为/apps/smart_agent/plugins/SendProxy/bin/SendProxy

启动智能代理发送代理守护进程：程序目录下SendProxy

OK

OK

备注：

SendProxy: 通过SendProxy发送的数据。

2、注册JavaAagent的应用监控服务

要监视Java程序，你须在“插件管理”界面里安装并启用Java插件。

3、提供JavaAagent的部署

按下“安装”键部署JavaAgent附加组件，部署期间会自动将JavaAgent传输至SmartAgent安装路径下的smart_agent/plugins文件夹，传输结束后启动附加组件。配置Java附加组件后，您还能在Java附加组件conf文件夹中的app.conf文档里设定有关数据收集的选项。

将路径分隔成各个组成部分，包含主目录，子目录，文件名，以及特定的文件标识符，文件版本号，设备型号，和唯一序列号，这些元素共同构成了完整的文件访问地址，用于精确定位和调用相应的应用程序组件，确保系统能够高效地执行预定任务，同时维护数据的一致性和安全性。

if

一元等于启动，一元等于运行

; then

设置环境变量JAVA_OPTS, 在原有值基础上追加参数, 参数包括用斜杠分隔的路径, 这个路径指向智能代理插件目录下的Java_1459929876X1002x0的配置文件夹, 另外还要加入一个javaagent参数, 这个参数同样包含路径, 指向智能代理插件目录下的Java_1459929876X1002x0的lib文件夹内名为CAgent-1.0.0.jar的文件, 路径最后以等号和智能代理插件目录下的Java_1459929876X1002x0结尾

fi

在TOMCAT的Catalina.sh启动文件里加入内容，具体位置参考下图所示，

4、透视宝APM监控分析后台管理效果

设置大约需要两分钟时间，完成之后，用户便可在“应用”部分看到相关数据，接下来将针对内部网络测试设备的部署情况，进行效果剖析。

5、APM监控实时发现异常堆栈事务

借助这个工具，能够即时锁定慢速的堆栈事务环节，协助程序员迅速处理程序故障，保障服务的正常开展。

/**感谢Chuck对文章存在的问题提出细致的改进意见。

谨此致谢云智慧透视宝首席架构师Neeke所给予的鼎力相助和精湛的技术支持。

/**感谢NC小伙伴们的环境支持。

作者简介：

黄小龙 (易宝支付CTO)