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