主稿专家：
武玉森 中原银行 资深运维开发工程师
负责行内运维体系规划及“监·管·控”工具体系化建设，带领团队构建运维中台以及各类运维需求场景化建设。近年来重点开展云原生环境下的监控及AIOps方面相关工作，以提升行内可观测成熟度。
参与分享同行：
朱海江 某证券单位
马海明 某银行单位
李正宁 某银行单位
汪照辉 某金融企业
金融业可观测性建设思路
（一）明确建设目标及建设路径
“业务连续性”在金融业是老生常谈的问题，也是监管机构重要考察点。业务系统无论是版本升级还是日常运行维护，都要在保障“业务连续性”的前提下开展，所以个人认为保障业务连续性仍是我们开展业务系统可观测性建设的最主要目标。
当生产出现业务异常时，一般是快速找到故障节点，辅以常规应急操作手段（如重启、隔离等），来确保业务连续性。然而金融业的业务系统间调用关系错综复杂，当出现业务异常时往往多系统多节点同步告警，很难快速找到故障根因节点。通过交易链路抽丝剥茧，找到故障节点，是当前常用的故障分析手段。针对交易监控，传统环境目前主要是通过旁路的BPM方案进行覆盖，云分布式环境主要是通过埋点的APM方案进行覆盖。以下是各自数据示例：
摘自旁路数据的部分字段：{……"ret_code":{"RC":"000","RET_MSG":"交易执行成功"},"start_at_ms_real":1721817551.886,"trans_ref":{"TT":"C400","probe_vlan_id":1703,"ANSID":"CXXX24072407XXXXXX003","SEQ_NO":"CXXX24072407XXXXXX003","SOURCE_TYPE":"CXXX","USER_ID":"SYMBOLS","TRAN_CODE":"C400"},"dst_ip":"10.20.190.142","src_ip":"10.20.40.21","dport":9999,"sport":47485,……}
APM数据一般遵从OpenTelmetry数据规范，部分字段如下：{"name": "/v1/sys/health","context": {"trace_id": "7bba9f33312b3dbb8b2c2c62bb7abe2d","span_id": "086e83747d0e381e"},"parent_id": "051581bf3cb55c13","start_time": "2021-10-22 16:04:01.209458162 +0000 UTC","end_time": "2021-10-22 16:04:01.209514132 +0000 UTC","status_code": "STATUS_CODE_OK","status_message": "","attributes": {"net.transport": "IP.TCP","net.peer.ip": "172.17.0.1","net.peer.port": "51820","net.host.ip": "10.177.2.152","net.host.port": "26040","http.method": "GET","http.target": "/v1/sys/health","http.server_name": "mortar-gateway","http.route": "/v1/sys/health","http.user_agent": "Consul Health Check","http.scheme": "http","http.host": "10.177.2.152:26040","http.flavor": "1.1"},"events": [{"name": "","message": "OK","timestamp": "2021-10-22 16:04:01.209512872 +0000 UTC"}]}
分析以上数据，要在以上两类数据的基础上实现交易链路的串联追踪，只能通过源目IP地址与端口，也就意味着只能实现节点级的链路追踪。所以以节点级交易链路为核心，辅以指标、告警、日志数据，构建可观测平台是金融业当前可行性方案。当然，如果有更好的数据基础，也可实现更多高阶能力。
1、具备统一的流水号。
可实现单笔交易的全链路追踪，而且在APM数据覆盖的部分可实现代码层面的故障根因分析。
2、具备一定的AI算法能力。
结合故障链根因推断算法，可实现故障节点快速智能化分析定位。
（二）实时数据清洗
可观测平台主要实现业务运行情况的实时观测，对数据实时性要求很高，一般是秒级的延迟要求，所以科学的数据模型以及高效的大数据实时处理能力是业务系统可观测性建设的前提。
1、数据模型
不同的链路数据如何清洗成相同的数据标准，就需要一个统一的数据模型方案。一般是结合需求和当前数据现状，并在业内现有数据模型基础上进行修订而产生。
a) 链路数据
建议以OpenTelemetry数据规范为基础进行定制化调整，过程中请考虑一定的字段扩展能力。
b) 指标数据
建议参考Prometheus数据规范，通过指标名+维度实现指标数据的标准化。
c) 日志数据
日志数据的标准化可能随所用产品有一定差异，具有一定的数据关联性能力即可满足需要。另外，为提升日志数据检索效率，可考虑采用clickhouse作为后端支持库。
d) 告警数据
告警数据一方面考虑关联资产（CMDB中CI）能力，另一方面需要考虑关联分析能力（如指标名、告警标签等字段）。
2、实时处理能力
目前我行采用的flink实现运维数据的实时处理，大家可根据单位现行基础采用合适的实时处理方案。
（三）可视化呈现
金融业业务系统数量往往较多，建议提供分场景分级的可视化呈现能力。
1、运行态场景
以业务系统运行状态和业务系统关系呈现业务系统级应用墙，并提供“业务系统-子系统-节点”多级交易链路的下钻呈现能力，并提供多维数据（指标、日志、告警等）关联查询分析能力。另外，具备快速检索跳转能力，便于业务系统日常运行情况观测。
2、故障态场景
基于告警跳转至相关CI节点的交易链路图，并提供多维度（如性能分析、历史告警分析、链路分析、变更分析及预案推荐等）故障分析能力，重点提供故障点的快速分析定位。
热点问题整理
针对金融行业业务系统现状，开展可观测性建设大家也遇到了很多问题，整理了部分热点问题以及多位社区技术专家的问题解答以供参考。
【问题1】实现核心异构交易系统可观测性使用了哪些数据源，这些数据源是如何整合利用的？
某银行单位同行：
1.日志数据：包括系统日志、应用程序日志、访问日志等。
整合利用方式：通过集中式的日志管理工具，如ELK（Elasticsearch、Logstash、Kibana）堆栈，对海量的日志数据进行收集、存储和分析。可以设置关键字搜索、过滤条件和可视化展示，以快速发现异常和问题。
2.指标数据：
如CPU 使用率、内存使用率、网络吞吐量、磁盘 I/O 等系统指标。
利用方式：使用监控工具（如Prometheus、Zabbix 等）定期采集这些指标数据，并将其存储在时序数据库中。通过设置阈值和告警规则，当指标超过正常范围时及时发出警报。
3.链路追踪数据：
用于跟踪请求在系统中的流转路径和耗时。
整合方式：借助像Jaeger 或 Zipkin 这样的链路追踪工具，将各个服务之间的调用关系和性能数据进行关联和展示。
4.事件数据：
例如系统的启动、停止、配置变更等事件。
可以通过事件总线（如Kafka）进行收集和分发，相关的处理组件根据事件类型进行相应的处理和分析。
5.业务数据：
如交易金额、交易类型、用户信息等。
通常与其他技术数据结合分析，以了解业务层面的趋势和异常。
武玉森 中原银行：
数据类型上面有同事已经回答，主要有指标、日志、链路、告警等，业务层面数据可按需求进行扩展（但其不具备通用性，一般为定制化观测）。以上数据的产生往往产生自多个不同监测工具，要想整合这些数据，一般要做以下工作：
1.制定正确的数据标准，可以参考厂商或同业较好的数据标准实践，然后加入本单位关注的数据元素，形成各观测类据标准，注意数据的目的是为了应用，要把可观测场景充分考虑进去。
2.高效的数据处理工具：一般借助大数据的flink或spark构建数据清洗、治理的ETL工具，当然前提是根据数据标准进行数据治理，将非标数据标准化。
3.具备完善的数据服务接口：对于治理后的数据，一般通过kafka或API对外提供。
4.观测数据的可视化呈现：根据可观测需求，将可观测数据可视化呈现。以上前三步也常用于构建运维数据中台，以上内容可根据本单位运维开发情况采用何种方式建设，一般运维数据中台通过厂商实现，场景需求的可视化呈现自研实现。
朱海江 某证券单位：
除了日志、指标、链路以外，从实践经验来看还需要与CMDB（配置管理数据库） 、服务治理、告警等系统数据整合与打通，调用链拓扑生成后如果想要变得可读，上述数据缺一不可，可以考虑将上述数据统一加工后存储到数据湖仓中，实现数据的集中管理和分析。
同时如果考虑异常链路监控推送、故障定位等应用场景，还需要与ITSM（IT服务管理） 系统进行对接，以及结合智能算法，实现更为精准的故障预测和根因分析 。
【问题2】企业中的可视化链路追踪是否有覆盖到类似普通委托交易这样跨系统比较多的业务场景？
朱海江 某证券单位：
交易、登录、综合查询等业务流程涉及的业务系统很多，其调用链路也会很复杂且冗长，并且这些系统往往运行在异构环境中，所使用的开发框架跟开发语言也有非常大的差异。一般交易系统在采用插码的方式通常会比较谨慎，建议可以通过日志、网络旁路等方式来实现可视化链路。而对于交易覆盖系统多，链路长的复杂情况可以考虑采用先易后难的方式：即优先将终端、中台系统之间的调用链路打通，最后再通过日志等方式打通最后一条链路。
武玉森 中原银行：
如果交易跨度比较长且涉及第三方，要实现单笔交易链路追踪比较困难，主要是涉及系统多（甚至部分系统是外采或第三方）、技术栈差异大，很难采用单一的埋点方案实现交易链路追踪。实现这类业务场景的可视化链路追踪，建议采用以下方式实现：方案一 ：通过旁路流量实现总体交易链路质量的监测，并在重要节点设置业务数据层面的自定义监控，实现总体可观测的。该方案不涉及单笔交易的全链路追踪，故实现起来较为简单，主要保障业务连续性。方案二 ：先梳理好这类业务场景的相对固定的交易链路，采用专业APM产品进行埋点，这样埋点范围相对较小，成本可控、工作量可控，且可实现单笔交易链路追踪。
李正宁 某银行单位：
1.长业务流的选择关键节点进行取样比对吧，毕竟太多的数据也难以处理 其中重要关键节点可以包括：1）进出口节点；2）重要的交易系统；3）支付系统；4）核心逻辑系统；5）其他问题较多或者重要的系统。
2.这类长业务流程应该会有专业的业务、技术专家，分别深入了解业务流程和系统构造，以便在问题出现时迅速缩小根因范围。同时可以组织人员进行协查。
3.工具的使用最终目的是为了解决人们在工作中遇到的问题。
马海明 某银行单位：
一般的普通委托交易的链路比较长从周边交易到柜台以及到交易所，中间的跨系统比较多，做的可视化链路追踪是否覆盖了类似这种业务场景，结合这块我谈谈我的理解认识：越是长、复杂的服务调用业务场景，链路追踪才能发挥它的价值。我们属于银行，我们优先做的就是对客类系统和交易系统，内部管理类这种偏简单的系统优先级反而不高。我们直接在我们的统一研发框架中，定义了接口规范以及链路日志规范，规范中包含了traceid、parentid、errerource等关键的信息，用于链路追踪及错误定位。
【问题3】大家企业中做的链路追踪是否要侵入代码或者sdk形式？当交易系统是外部厂商开发时，如何与厂商协调？
李正宁 某银行单位：
1.现在的链路追踪的有两种形式，其一为日志监控，需要大量系统对输出日志格式做改造，成本高，但效果好，而且可以形成良好的开发模式。其二为APM链路监控，APM会通过transtraction ID关联交易链路。日志是在制定了规范之后，在开发时候调整的， APM是放在JVM中运行的，这两种形式都不会涉及到代码入侵。
2. SDK一般是用在手机端或前端JSP中，一般对应用主体本身没啥影响。
3.如果是日志改造，可以要求所有的厂商按照格式调整日志，不过因为是新需求，会产生额外的成本。如果是APM只要放到JVM里，没多少工作量，厂商都会配合的。
4.既然是核心系统，尽量不要做代码入侵，风险太大。就算做日志改造，也会是基于核心调整的。
马海明 某银行单位：
我们单位走过了这么一条从大部分靠外购到大部分自研的路，也走过了从一开始服务调用链路推不动到快速推进的阶段。这也说明了一个企业统一研发框架的重要性。如果你的企业大部分应用都是外购产品，那服务调用链是非常难推的，倒不是厂家不愿意改，但沟通成本特别高，周期特别长，资金成本有时候也很高。不过，如果是在产品首次购置的时候谈，难度是会低很多。从2018年起，我们单位统一了研究框架，也逐步把相关应用用这套框架来重构。在这套框架内，我们对应用进行了服务化改造，并且统一了链路日志，统一了交易流水号。对于无法用这套框架的系统，我们也提供了SDK，其他项目组可以把这个SDK集成到自己应用内，就可以按照规范生成链路日志。
武玉森 中原银行：
如实现单笔交易的全链路追踪，目前最好的方式还是通过APM插桩方式实现。对于你说到的这个问题，其实现在有些监控厂商（如听云）可以提供较好的解决方案：部署独立的agent，在java的类加载前做字节码增强，agent与业务应用程序相对独立，便于厂商间的协调兼容。另外链路追踪也并不是必须要采用插桩埋点这种模式，主要是看你所需要的链路追踪需求，我了解到的主要有以下几种方式：
1.基于流量旁路解码的链路追踪：优点就是完全无侵入、且能覆盖各类技术组件（如F5、防火墙、交换机、数据库等），但对网络镜像流量要求较高，在云原生环境内实现成本较高，而且对链路的观测粒度主要在IP级别的整体链路上。
2.基于日志的链路追踪：优点也是无侵入，但对日志规范性要求高，对于银行、证券等行业相对复杂的多系统组合的交易场景，实现难度很大。
3.第三个就是基于插桩埋点这种模式了，我就不再赘述。
朱海江 某证券单位：
首先核心交易系统要做侵入式代码的话本身应该是比较谨慎的事情，从我们的经验来看的话c++类插码后对性能影响还是挺大的。一般核心交易系统建议还是通过日志、或程序内部打点等方式实现可观测。从目前新一代交易系统的发展来看，可观测基本是各家供应商都会考虑的功能，这一块还是比较容易与供应商沟通的。
Steven 某金融企业：
1.自身是否有相应的要求和规范，比如是否有架构治理要求 。
2.厂商产品是否具备可观测能力，最好的方式是选一家具备可观测能力的厂商产品 。
3.自身技术实力和积累，基于实际选择合适方案 。
4.如果啥都没有，听厂商的，至少能用 。
【问题4】链路追踪系统部署问题，插码类agent如何防止阻断交易？
朱海江 某证券单位：
APM工具无论是植入agent还是字节码增强的方式，其实都会对应用系统产生一定影响。交易作为系统核心功能必须优先保障，尤其是系统的稳定性和交易性能不能受影响。因此在投产前必须在测试环境进行充分的功能验证和性能比对测试。测试的方法有很多，功能测试可以在UAT等环境部署后运行一段时间，主要是看应用插码后的稳定性以及功能是否受到影响。性能测试可以选择全真等环境进行核心功能压力测试，重点比对插码或agent部署前后的性能差异。
李正宁 某银行单位：
1.首先监管工具无论使用插码类，还是使用旁路追踪，不能影响生产业务使用为最基本的要求。作为辅助性工具，如果影响了业务，那么这款工具就不能作为成熟产品使用。
2.目前成熟的监控工具一般都不会对业务产生阻断，出现的问题一般都是应用本身。
3.工具一般还是使用postman等模拟工具，压力测试，回归测试一般就足够满足测试需要了。
4.考虑到APM 出现问题一般是性能问题，例如在某种场景下资源使用率过高，因此现在主流的监控都会在资源使用到百分之三左右，触发熔断机制。而且熔断可以精确的线程级别：既在保障应用正常使用前提下，只熔断APM 服务。
5.问问该产品别的公司使用的情况，真实的用户体验才是最值得信赖的。
武玉森 中原银行：
目前我们还没遇到这个问题，一般情况我们会对agent进行自我限制其资源使用情况避免对正常交易产生影响。如果真是阻断了交易，这笔交易异常也是可以监测到的。如果在测试环境验证，建议结合A/B测试和压测，对比agent部署前后交易阻断情况，查看是否存在这类情况。
Steven 某金融企业：
如果agent阻断交易，这个agent实现应该是有问题的。因此这个问题的假设可能是不成立的，特别使用成熟的apm工具。另外需要强调的是：可观测性并不是依赖于外部工具，可观测性指的系统本身具备可观测，因此如果代码没有问题，不会出现交易阻断的情况；依赖外部工具实现的是监控能力 。
有任何问题可点击“阅读原文”到社区原文下留言
觉得本文有用，请转发、点赞或点击“在看”，让更多同行看到
资料/文章推荐：
欢迎关注社区 “智能化运维”技术主题 ，将会不断更新优质资料、文章。地址：https://www.talkwithtrend.com/Topic/125353
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区立场
