金融级应用性能监控系统的自研探索与实践 - 运维 - dbaplus社群：围绕Data、Blockchai...

刘洋，石良生，杨洋 2024-01-13 11:14:00

随着微服务框架在公司内的逐步推广落地，对分布式架构下的产线可观测性提出了新的挑战。业务的复杂化，给性能监控的内容和方式也提出了新的要求。同时，为数众多的外采的烟囱式的信息系统，使得应用的性能监控更加困难。本文针对公司现状，对应用性能监控系统的解决方案进行探讨，通过自主研发一套全新的应用性能监控系统，在传统的分布式链路跟踪技术的基础之上，实现丰富的接入方案，灵活的监控配置，动态的指标拉取，边缘化的数据存储，解决了公司产线观测的问题，在大量自研及外采系统中进行实践，取得了良好的效果。

关键字：性能监控；自主可控；边缘存储

一、建设背景

业务的复杂化和上层技术的升级是推动监控手段不断发展的原动力。企业级监控体系要面对众多信息化系统拓扑组成的复杂IT经营服务，其实际运行工作更为复杂，再加上微服务、云原生、函数计算等新技术的不断涌现，传统的日志加系统监控的手段已经难以充分地满足企业的监控需求。

系统监控领域由于其复杂性和普适性，是各类技术服务商和开源组织竞相角逐的战场，流行方案层出不求、创新不断。通过开源或商用工具快速构建监控能力是小型团队的常规路径，但对于有大量存量系统、或自研与外购混合、或多中心、或多技术栈的中型以上企业来说，明确监控体系建设质量目标，通过目标倒推监控工具和管理流程规划相比较而言更加具有长期成效。无论技术如何发展更迭、企业业务特性如何包罗万象，抛开层出不穷的新潮概念和流行方案，从主要监控步骤（日志采集->发送告警->故障定位）来看，衡量企业监控体系健壮性的关键指标依然是：监控覆盖度、告警有效性和可观测性。

图1  监控系统关键指标 1.监控覆盖度

具体包括监控目标的覆盖度和监控指标的覆盖度。监控目标包括：应用、系统（运行环境）、数据库、中间件、硬件（机房、服务器、空调）、网络等。监控指标可以分为系统指标、应用性能指标、日志、业务指标等。通过设置标准化的监控管理流程和角色来保障监控覆盖度是非常有必要的。与之相反的是运动式、缺乏监督和检查点、缺乏针对性评估。

对于存量系统，打通CMDB（Configuration Management Database，配置管理数据库）与监控系统，将CMDB系统清单和监控系统的指标清单匹配整合，通过日志有无采集来判断覆盖度是一种比较理想化的存量覆盖度检查手段。

2.告警有效性

当完成监控覆盖度后最重要的工作便是维持告警的有效性，包括去除无效日志、告警降噪、触达审计等。告警有效性保障是监控体系最容易忽略的一环，有效性的缺失会导致整个监控机制的失灵。因此，通过管理机制和协同工具来保障每条告警的有效触达和被充分重视是至关重要的监控工作之一。

3.可观测性

不同于狭义监控侧重于观察特定指标，可观测性则是强调通过分析系统生成的数据理解推演出系统内部的状态。可观测性是面向复杂分布式系统的现代监控理念，以应对云原生、大规模分布式协同等现代技术场景，同时，可观测性也是产线排障的重要支点。

可观测性内容非常多，是监控体系中最具技术挑战性的部分。大致可以分类为日志（Logging）、指标（Metrics）和追踪（Tracing）。全链路的可观测建设牵涉到诸多方面，易入门难完善，同时也间接反映企业整体IT研发实力水平。

4.金融类企业其他要求

1）多技术栈、多外购系统

不同于一个技术栈撸到底的互联网公司，大多数券商非常依赖技术供应商，其技术栈容易发散，同时还存在大量的外购黑盒系统，部分还自带监控子系统。对自研和外购的分层支持、对于不同技术栈系统保有一致性的监控水准需要一个系统性解决方案。

2）数据脱敏与研发协同

对于瀑布类的项目和外购系统，运维团队掌控力较强。但敏捷交付项目往往更需要开发人员参与稳定性的维护。因此，在开发和运维两类角色中进行数据隔离同时保证高效协同也是完善监控体系的重要内容。

3）系统的健壮性

金融类企业的信息系统，涉及交易、资金等许多环节。对于监控系统的引入，需要非常谨慎。必须要保证监控系统不能对原有系统的正常运行造成影响。

二、建设思路

企业监控体系的搭建可以分为监控接入管理、监控服务、监控平台三项工作。良好的监控体系需要依赖可靠的平台系统和有效的工作制度，系统与制度缺一不可。

图2  项目建设思路 1.监控接入管理

监控接入管理是指通过清晰有效的工作机制，在研发交付流程环节保障监控覆盖面，避免死角。具体包括健全开发侧相关规范，在架构评审环节增加监控评估内容等。

1）监控接入规范

监控接入规范旨在指导开发人员在应用设计阶段就考虑监控方面的需求。从日志、异常、探活和业务事件等方面着手主动适配企业监控体系。因此，我们需要制定可行的相关规范，包括日志输出规范、异常处理规范、应用探活规范、事件上报规范。

2） 监控覆盖评估

• 监控基线

针对各类监控对象建立监控配置基线，由监控探针按照配置进行日志采集。基线的目的是面向常规系统监控和基础应用监控而设，可以满足绝大多数监控需求。基线往往由系统运维设立并打入交付设施中，与交付系统打通往往可以支持全自动化生效。同时，监控基线应该能自然支持市面上主流的中间件、基础设施。

• 监控评估

监控评估主要在架构评审、采购评审等阶段开展，面向的是非基线约定的监控角度。除了复核常规监控配置基线外，主要评估内容为高可用自动切换等变更告警、关键Transaction监控、可观测性评估等，具有较大的自主性和主观性。因此有必要建立专人专岗，在研发交付的流程中设定专门评估环节来保障有效落地。

2.监控服务

监控服务描述的是应用接入企业监控体系后，将监控告警和观测平台打包提供给项目人员的一系列标准化服务的集合，是由监控团队提供给开发和应用运维人员。

1）告警工单服务

告警与工单的结合不但标准化了异常处理过程，同时也可以作为项目的应急处置能力的评估指标。自动化告警工单在监控体系中的价值包括：

• 对告警进行归纳和分类

• 无干扰地统计处理时长

• 度量IT团队的异常处置能力

• 在制度上有助于收敛无效告警

2）观测支撑服务

监控团队集中建设的观测平台是面向项目组提供合规、脱敏的产线运行状况的观测通道。观测支撑服务支持开发工程师、应用运维两类角色，分别提供不同程度的数据查看权限。同时，也支持应用运维即时授权给开发查看更多内容。可观测的数据包括：

3）监控平台

当下市场上流行的监控平台层出不穷，对于金融企业需要重点兼顾的需求包括有：

• 多语言支持

• 多中心支持

• 与IT资产管理、交付工具、工单系统、成效分析系统的打通和集成

抛开各类流行监控产品的上层能力图谱的影响，从监控工具的运行流程来看，监控平台可以拆分为如下阶段性子系统或模块。

图3  监控平台链路

图4  监控平台功能细分

三、技术方案

1.产品定位

目前公司拥有包括Zabbix、Prometheus、APM（Application Performance Management，应用性能管理）、服务治理以及其他专项监控设施共同组成的多方案企业监控体系。监控不同于通信框架，可以适度冗余，通过有限交错的监控工具可以增加容错率。目前公司在应用层监控采用以Prometheus为主，以自研的APM、服务治理为补充的整体结构。

图5  产品边界

2.系统设计

1）整体设计

兴业证券APM是一个主要基于Java开发而成的分布式系统集，其包括多个子系统。系统设计的整体目标为高吞吐、海量存储，但在数据一致性、备份冗余方面需求不高。除了支持异地部署外，还需要强调对业务监控的支撑力度，同时在企业监控体系的定位上做了下沉，APM新增的事件处理编排能力旨在构建灵活的业务监控能力，与其他监控设施做差异化服务。

图6  产品整体设计

2）事件分析与存储

APM以灵活配置事件消息处理流程为目的，基于Kafka流式处理能力自主设计了的可编排日志分析器。对于上报的事件消息，根据事件的“type”关键字，区分不同的事件类型。对不同的事件类型，可以配置一个或多个有序的事件消息处理器。分析器服务将会根据配置的分析器，按需对事件消息进行处理。链条处理器目前定义了6种基础的处理器。

图7  事件分析处理器

图8  日志分析流程

表1  分析器功能说明

处理后的事件消息，如需要持久化，则最终会通过特定类型的分析器落入到3类存储设施中。其中，BitCask是我们基于Riak分布式数据库论文，结合边缘存储的理念做的自主实现。存储结构为Key->Value List，具有较高的吞吐能力。目前我们测试数据结果为：单机4核8G的机械硬盘下QPS为10K/S左右。

我们针对APM事件消息详情数据写入频率远高于查询，且写入后不会修改的特点，将调用链详情数据写入本地BitCask，运用边缘存储的方式，极大地节约了网络带宽资源，同时提高了数据的安全性和隐私保护。

3）数据查询服务

APM数据查询服务是实现了类似MyBatis的在线模板录入生成数据查询能力的服务，是APM重要的子系统。其查询脚本存储在Zookeeper中，同时脚本采用Velocity模板，有很强的灵活性，可以根据模板及传入参数形成复杂的数据检索逻辑。同时对外开放了检索的RPC服务与HTTP接口，周边系统开发人员可以通过接口提取采集到的Metrics数据。

图9  数据查询服务执行流程

通过灵活的事件分析存储、数据查询配置，我们就可以将业务与能力解耦。将业务交给接入方，使得他们在享受APM基础能力的同时，能够根据自己的需求，定义特殊的事件，做定制化的事件分析和分析结果查询，形成完整的自闭环。这种方式能极大提升系统的数据权限隔离和隐私保护能力，使之在金融行业内，能发挥更大的能动性。

图10  事件消息数据流图

4）跨中心同步

公司系统有多个数据中心，有的系统仅部署在一个数据中心，有的系统部署在多个数据中心，就会导致我们有跨数据中心的请求。而数据中心间的网络资源，往往是比较紧缺的，APM的数据量又是比较大的，因此，我们设计了一种跨数据中心的调用链存储和查询方式，能够极大地减少跨中心请求时伴随着的跨中心调用链数据上报。

图11  跨中心同步部署架构

四、成果及展望

本文主要介绍了兴业证券在应用性能管理系统上的建设思路和实践。不同于外购和开源方案，系统在复杂模块使用开源组件的基础上，自主研发底层存储和事件分析查询能力，使系统对公司技术栈和潜在技术变更有着更好的兼容性和适应能力。

该系统在公司内上线运行以来，经过反复地迭代升级，对特殊业务、协议、中间件的陆续支持，已取得了良好的效果，为应用性能管理提供了有力的抓手。

1.监控体系

兴业证券自研的APM系统自2018年上线以来，经过不断地完善和优化，在性能上和兼容性上持续提升，目前已成为应用性能监控的标准方案，配合Prometheus的中间件监控和Zabbix的主机监控，共同构成了我司完整的监控体系。

2.减少带宽占用

基于新中心网络规划进行技术攻关解决跨中心海量数据同步和传输网络带宽占用问题。在今年的新中心搬迁工作中，对于新中心的两地三中心网络规划，自研APM发挥了完全自主可控的优势，攻关了应用运行数据集中存储与异地网络带宽限制，满足数据就近存储，减少跨机房数据同步，禁止应用跨机房数据上报的需求，实现多中心部署并支持弹性伸缩，避免对机房间网络带宽的占用。

3.支持自研与外购系统

APM凭借多语言支持，目前已成为中台、集团CRM等几大自研产品线运行观测和生产排障的主要工具，外购系统接入率也在持续提升，极大提高开发运维人员性能监测、故障感知与定位的效率。

4.未来展望

未来，我们会持续深耕，探索现场还原、风险预判、自动剖析等更前瞻的观测能力，探索边缘存储方案和应用场景，持续沉淀和输出相关的通用方案，提供更加丰富的观测指标和能力，为产线系统稳定运行保驾护航。

作者丨刘洋，石良生，杨洋（兴业证券股份有限公司 金融科技部） 来源丨选自《交易技术前沿》第51期  公众号：上交所技术服务（ID：SSE-TechService） dbaplus社群欢迎广大技术人员投稿，投稿邮箱：[email protected]