应用监控是整个监控体系的重要组成部分，面对各个应用系统之间的差异性和复杂性特点，如何全面有效的实施应用监控是应用运维人员和监控管理员共同面临的难题。G行通过多年的实践证明，应用监控标准化是解决复杂IT环境下应用系统有效监控的一柄利剑，也是实现监控数字化和智能化的基础。G行从监控标准化方法论、监控标准化模型、监控对象模型、指标定义及接入规范等多个层面进行探索，有效促进应用监控工作在组织层面的融合和打通，确保“三早”原则的落地执行，保障了应用系统平稳运行。本文对G行应用监控标准化演进之路进行了回顾和介绍。
应用监控标准化的内容和意义
1. 应用系统的定义
应用系统一般由计算机硬件系统、系统软件、应用软件组成。硬件系统和操作系统、数据库、中间件等软件系统的标准化程度较高，具有相对通用的监控指标和监控手段。应用软件基于通用的开发语言和开发框架，编写应用程序满足不同的业务需求，具有差异性和复杂性，需要建立统一的监控标准变不确定为确定，保障应用系统业务连续性。因此应用监控标准化的管理对象主要是应用软件。
2.应用监控标准化内容
标准化，实质上就是为标准制定、发布和实施过程而进行的一切活动。应用监控标准化重点是Metric监控相关的指标集、监控对象、监控工具等标准模型以及由此产生的闭环和量化管理活动。对于应用监控中可能涉及到的日志和Tracing规范，有单独的技术标准进行阐述，不包含在本次监控标准化范围内。
3.应用监控标准化的意义
确保“三早”原则落地：通过部署标准化的监控指标体系，全面掌控应用系统运行状态，对于生产故障的发现，确保“监控工具早于运维人员、科技部门早于业务部门、银行早于客户”的“三早”原则的有效落地。
提升监控管理水平：沉淀和固化运维经验，将运维工作中积累的监控手段归纳总结后进行组织级推广部署，从全局角度提升监控管理水平。
组织内监控工作融合：通过监控标准化中的指标接入规范、指标测试规范、应用监控策略部署规范以及生产事件跟踪机制，将监控工作前移至应用开发和测试环节，形成管理闭环。
传统环境应用监控标准化
监控系统建立之初一切都是从零开始，每个应用系统都是单独进行对接，单独梳理监控指标、监控策略，部署监控后再根据运行情况进行调整。随着监控系统不断完善，接入的应用也越来越多，应用类型五花八门，依赖人工经验单打独斗的方式已经捉襟见肘，具体表现在：
指标不明确：每个类型的应用应该有什么样的监控指标不明确。
策略不明确：每个指标需要如何设置阈值、报警级别不明确。
接口不明确：指标需要采用哪种接口、如何接入监控系统不明确。
现状不明确：应用的监控策略实际应用情况如何，这些问题在过去都要依赖手工查询核实，很难快速回答。
为了全面提升应用监控覆盖率，规范应用监控工艺，提升监控实施效率，迫切需要进行应用监控标准化。
1.应用监控标准化模型：
图1监控标准化模型
监控对象：从监控角度需要关注其状态和性能指标的应用对象。
监控指标：用来识别监控对象状态的相关数据。
监控策略：用来度量和判断监控指标优劣的标准。
监控工具：实现从应用监控对象上采集监控指标所采用的技术手段，是监控策略运行的载体。
监控规则：监控团队参考各专业团队日常运维经验结合业内最佳实践总结的监控对象和监控策略的对应规则，用于指导监控策略的部署和对策略运行情况进行事后审计。
2.应用监控对象模型
监控对象标准化：除了常规的操作系统、数据库、中间件外，以监控视角对一个应用服务的组件进行拆分和建模。
图2应用监控对象模型图
3. 主要应用监控组件和指标
基础环境层
网络
TCP长连接监控：该指标主要用于对Established状态的TCP长连接进行监控。一般通过固定端口号作为筛选条件统计连接数量，同时可对该连接的缓冲区队列深度进行监控，以此发现网络连接中断或应用处理瓶颈的异常。
文件
产生异常文件：该指标主要用于对应用进程是否产生错误文件或未处理文件进行监控。C语言应用常见错误文件为bin目录下产生coredump，或应用程序自定义生成的.err文件。此外对于应用目录下超时未处理的文件，也可视同为发现异常文件而需要监控和报警。
缺失关键文件：该指标主要用于对应用目录下的数据文件存在性进行监控，通常结合时间段条件进行综合判断，可提前发现数据文件未生成、未传输、文件名不符等异常现象。
内存
GC次数/分钟：该指标用于对Java虚拟机每分钟的FullGC次数进行监控，用于发现Java虚拟机堆内存不足的问题。相比于对Heap空间使用率的监控，通过对持续的、多次FullGC更加能够准确的发现应用程序运行中潜在的内存问题。
直接内存使用率：该指标用于对Java直接内存（堆外内存）的使用率进行监控，用于发现Java直接内存空间使用的容量问题。
应用组件层
●API调用
API调用异常：该指标用于对应用程序调用外部API接口存在的错误和超时进行监控。常见的通用外部接口可能包括加密机API、RedisAPI、MQAPI等，通过对调用接口的系统级错误信息进行实时监控，能够更早、更明确的提示故障根因。
●队列
队列深度：该指标用于对应用程序内部自定义队列的深度进行监控。队列深度的单位可能是队列内消息数量、队列内超时待处理消息的数量等，用于发现应用程序可能存在的性能瓶颈。
功能服务层
●定时任务
批量任务失败/批量任务超时：该指标用于对批量任务的运行状态/运行时间进行监控。尤其对关键批量任务（影响系统开门、客户服务、监管报送）设定高报警级别，确保及时通报和处理。
●应用功能
系统换日状态：该指标用于对各交易类系统的账务日期更换状态进行监控。
秘钥交换状态：该指标用于对联机交易类系统和加密平台之间秘钥交换的结果进行监控。
应用健康检查：该指标用于对应用服务的存活状态进行外部探测检查，用于及时发现服务夯死的情况，检查方式通常为通过监控工具发起http探测或模拟交易探测。
●业务服务
交易成功率/响应率/交易量/响应时间：此类指标为联机交易类应用系统的通用指标，通过从容量、延迟、错误3个维度度量应用服务健康状态。需要关注的是可细分为多个维度，如全局指标/单交易码、渠道、商户、系统返回码/业务返回码等，通过维度+指标组合分析发现和定位应用系统交易的异常。
4.监控工具标准化
监控工具的标准化，核心思想是根据各类工具的特性合理运用工具，充分发挥工具特长。根据监控需求，监控工具的选取因素包括：有代理/无代理采集、监控主动采集/监控被动接收、带内采集/带外采集等。
自定义监控指标：具有周期性和灵活性的特点，适合使用有代理、主动采集方式，如Zabbix、Prometheus等。
关键通知消息：具有实时和精准的特点，适合使用应用主动推送、监控被动接收的采集方式，如syslog、trap、webhook等。
交易数据指标：具有数据量大、数据原始程度高的特点，适合采用旁路/带外方式将原始数据进行采集后送入专用的监控工具进行分析和处理，减少采集和分析对原有系统的影响。适用的工具包括BPC工具、CDC类工具（变更数据捕获）等。
5.监控策略标准化
监控策略标准化的重要内容是报警级别。G行从两个维度来定义报警级别：
按照管理员视角来定义的级别：根据技术人员是否需要立即展开处置动作来定级，1级表示需技术人员立即处置的报警，2级表示需进一步判断分析的报警，3级表示暂无需处理的报警。
按照业务人员/管理层的视角来定义的级别：根据业务影响的大小来定义报警级别，从高到低分别为重大影响、较大影响、一般影响、轻微影响、潜在影响和无影响。
按照上述规则配置应用监控报警策略，当报警发生时分别从两个维度进行展示、通报和升级等后续处理，满足技术人员和管理层的差异化运维需求。
6.智能运维技术的应用
AIOps技术的推广使用，为应用监控标准能力带来了以下提升：
动态阈值丰富了监控策略的管理模式：基于大数据、实时计算和无监督算法的智能运维技术，对于各项运行指标的历史数据生成预测基线，实时计算生产运行数据的偏差程度，及时发现运行指标的异常情况。在原有的基于固定阈值监控策略模式基础上，动态阈值丰富了监控标准化策略，成为应用系统交易监控必须部署的标准监控策略。
多维分析技术提升故障根因定位能力：基于交易码、返回码、渠道码、商户码以及服务处理节点信息等多维度的交易分析，在应用系统联机交易关键指标发生异常时，能够快速推算出导致异常的组合因子，便于科技人员迅速定位故障原因，同时通过支持黑白名单机制预先固化运维经验，提升故障告警准确性。
分布式应用监控标准化
随着容器技术、微服务以及分布式应用的兴起和部署，G行原有的面向传统环境的应用监控面临着巨大挑战，包括大量开源软件的使用、应用弹性扩缩容常态化、CI/CD带来的开发投产模式的变更等。G行在传统环境监控标准化的基础上进一步优化了标准化工作模型，支持分布式应用的监控管理。
1.监控标准化工作模型
图3监控标准化方法模型图
2.分布式监控指标参考
面对分布式环境下大量开源产品/组件的使用，监控标准化的牛鼻子是监控指标标准化。
在监控指标选取方面，G行参考Google提出了黄金指标概念，具体内容如下图所示：
图4黄金指标模型图
3.分布式监控指标制定原则
分层分类：监控指标进行分层、分类，由专业团队和监控团队合力丰富监控标准。
标准统一：无论传统平台还是容器云平台，对于同一类对象的监控标准要统一，确保指标全覆盖。
同类对标：对于相同类型的监控对象，需对标原有相似类型的监控对象。
敏捷迭代：通过主动分析和监控未达事件分析机制，持续补充和完善原有监控规范。
4.分布式应用监控模型
图5分布式监控模型图
在传统的应用服务监控模型基础上，增加了微服务组件，如注册中心、配置中心、API网关等，增加了分布式应用组件，如分布式缓存、分布式批量、分布式消息、分布式数据库的监控标准化。
5.分布式指标接入
通过监控标准化中的指标接入规范、指标测试规范、应用监控策略部署规范以及生产事件跟踪机制，将监控工作前移至应用开发和测试环节，形成管理闭环。
监控指标的接口格式统一采用Prometheus采集规范，即应用程序通过http协议主动暴露数据，监控工具采用pull模型定期拉取监控数据。接口格式为：
<指标名称>{<标签名称>=<标签值>,...}数据
指标名称：反映了被监控样本的含义。
标签：大括号中的标签反映了当前样本的特征维度，用于对样本数据进行过滤，聚合等。
数据：采集到的具体值。
应用指标暴露方式主要分为以下两种：
基于G行通用研发平台开发的应用程序：平台已内置了监控SDK包，默认支持暴露应用或SpringBoot框架，按照要求进行配置即可暴露监控指标。
非G行通用研发平台开发的应用程序：需要应用程序基于Prometheus的clientsdk或SpringBootActuator开发监控接口，按照监控标准暴露应用监控指标。
6.基于标签的监控自动化部署机制
针对每类监控对象我们都设计了监控标签，监控标签与一组标准监控指标和标准监控策略对应，我们称之为标准化监控规则。监控标签主要用于以下三个场景：
图6监控标签应用场景
监控标签的工作机制如下：
通过指定标签查询指定数据
通过标签实现丰富的聚合和查询
监视具有特定服务发现注解的监控目标
向目标抓取请求添加HTTP查询参数
仅存储从指定目标中提取样本的子集
将抓取序列的两个标签值合并为一个标签
平台已有的应用类型新接入时只需要使用制品库提供的带监控基础镜像生成应用镜像，同时在容器云平台通过图形化方式生成带有监控标签的Service.yaml文件，后续基于该yaml文件的应用发布投产后，监控系统采集到的数据同步打上了监控标签，自动匹配对应的监控策略，实现了全自动监控对象发现和监控策略对接，无需人工干预，确保监控标准化全覆盖。
7.量化监控评价
通常监控系统运行效果评价的指标是监控发现率、报警压缩率、报警根因定位率等，这些指标都偏向于通过事后的量化统计体现监控系统的效能。除了这些指标外，G行还定义了监控覆盖率和监控标准化率两个指标。
监控标准化率的计算公式为：
监控标准化率=监控档案/监控标准*100%
监控档案=∑监控对象*已部署标准监控策略
监控标准=∑监控对象*应部署标准监控策略
按照上述公式对应用系统的所有组件进行监控标准化的度量，可获得每个应用系统的监控标准化率。
图7应用监控量化评价效果图
通过上述排名机制，可以获知各个应用系统的监控策略和基线的偏差情况，对于缺失的监控项需及时进行补充部署监控策略，对于非标准的监控项（如个性化阈值、报警级别降低等情况）需进行应用系统的整改以满足标准化要求。
目前G行已完成对全局类系统的应用监控标准化评分，后续还将持续优化和推广量化反馈机制，持续提升监控效能。
小结与展望
通过多年探索与实践，G行逐步建立了应用监控标准化的实施方法模型、应用服务模型、监控指标体系以及闭环量化管理机制，逐步完善了传统应用与分布式应用的监控手段，提升了监控系统整体效能。面对日益复杂的应用系统环境，G行后续将持续进行监控系统优化，通过持续丰富应用监控指标集、引入非侵入监控数据采集方式、支持自助式监控配置管理模式等工作，提升应用监控能力。
