3 分钟诊断 金融分布式核心交易系统 概率性交易失败

摘要：某银行分布式核心交易系统运行过程中，遇到了偶发性、无规律的交易失败，由于交易请求海量、通信关系复杂、应用实例动态等系统特点，传统监控工具的诊断能力受限，此类故障诊断极其困难。但在本篇案例中，您将看到 DeepFlow 可观测平台提供的 Full Stack（全栈）、End to End（全链路）、Any Request（每一次应用调用）观测能力，精细化分析每一次失败交易的端到端过程，用 3 分钟时间、5 步操作，通过可观测性数据客观诊断出故障根因。

01｜故障背景

某银行分布式核心交易系统中的 XX 子系统，在常态交易压力下偶发性出现交易失败，发生时间无规律，并且返回交易失败的节点动态变化，难以从失败的规律中找到故障点和故障根因。

分布式核心交易系统 XX 子系统的业务端到端访问过程如下：

• 1）基本路径：Client—>F5—>Ingress—>App的接口；
• 2）Ingress采用分布式架构，分布在 K8s 集群中的 3 个 Master 节点；
• 3）App（内置 Tomcat）采用分布式架构，动态扩缩容，常态下保持 40 个以上的 Pod；
• 4）Ingress与App之间形成 3*N 的网状架构。

分布式核心交易系统 XX 子系统的端到端访问结构

此类故障诊断的困难点在于：

• 海量的交易请求：生产业务系统中，实时发生的海量交易请求导致锁定单笔失败交易并观察其微观过程是一件极其困难的事情，难度无异于大海捞针。
• 复杂的通信关系：Kubernetes 为分布式系统提供了良好的负载均衡体系，但带来的是复杂的通信关系，由于Ingress与App实例间存在上百对（3*N）的通信交互关系，在通信对中找出问题路径犹如迷宫穿行。
• 动态的应用实例：Kubernetes 为分布式系统提供了快速扩缩容的能力，但 Pod 的动态性也导致后端App实例的分布节点动态变化，这使得在几十个App实例中捕获某一笔交易的过程犹如捉迷藏一般。

但进入可观测性时代，DeepFlow 可观测性平台提供了 Full Stack（全栈）、End to End（全链路）、Any Request（每一次应用调用）的数据采集和观测能力，便可精细化分析每一次失败交易的端到端过程，用 3 分钟时间、5 步操作，通过可观测性数据客观诊断出故障根因。

02｜DeepFlow 故障诊断过程

DeepFlow 全链路观测点示意图

DeepFlow Agent 以 Daemonset 的形式在容器集群的每一个节点运行，在 ARM + 麒麟 V10 的环境中，通过 eBPF 可观测性数据采集技术，实现了每一次应用调用在如下观测点的性能数据采集：

• 观测点 1：Ingress的入向网卡
• 观测点 2：Ingress的入向进程
• 观测点 3：Ingress的出向进程
• 观测点 4：Ingress的出向网卡
• 观测点 5：App所在 Node 的入向网卡
• 观测点 6：AppPod 的入向网卡
• 观测点 7：AppPod 的入向进程

3 分钟、5 步快速诊断

Step 1：监测 Ingress 服务入口指标，发现服务响应异常（请求返回码成功率低于 100%）。

Step 2：调阅 Ingress 服务入口应用调用日志，从应用调用中过滤发现 HTTP 502 错误响应。

快速诊断中的 Step 1-2

Step 3：过滤 Ingress —> App 的 HTTP 调用日志，发现 Ingress 到某个 App Pod 实例的 Request 未被响应（响应状态显示“未知”）。

Step 4：一键调阅异常 HTTP 调用的 TCP流日志，发现 TCP 连接 “服务端异常”。

Step 5：一键调阅异常 TCP 流的包时序，发现服务端（即 App Pod 实例）在 15 秒内未收到任何新的交易请求，因此发送 FIN 关闭 TCP 流，但几乎同时收到 Ingress 发送的一次新的交易请求，已无法处理，只能再次 RST 提醒 Ingress。

快速诊断中的 Step 3-5

根因分析

服务端主动发送 FIN 关闭 TCP 连接，说明 App 端触发了 TCP 超时机制。

检查 App 端 Tomcat 的 TCP 连接超时参数，发现超时时间设置为 15s，因此出现请求与 FIN 冲突事件，整个冲突发生过程复盘如下：

• App实例中的 Tomcat 在 15s 内未收到任何请求后达到 TCP 连接超时条件，发送 FIN 消息，主动关闭超时的 TCP 连接；
• 在 FIN 消息到达 Ingress之前，Ingress仍然认为 TCP 连接正常；
• 此时若刚好有交易请求需要转发，则有可能将交易请求发送至处于半关闭状态的 TCP 连接，出现交易请求与 FIN 冲突，产生概率性交易失败。

请求与 FIN 冲突数据包交互过程

解决方案

在该业务场景下，仅需将服务端 Tomcat 的 “TCP 连接超时参数” 取值大于客户端的 “KeepAlive 超时参数”，即可确保在服务端超时前客户端主动发起 TCP KeepAlive 保活 TCP 连接，消除此类交易失败的可能性。

补充说明

开启 DeepFlow 的 TCP 包时序数据采集开关的方法：

1）打开 DeepFlow Server 的 Web 页面

2）进入 系统 —> 采集器 —> 配置 —> 采集器组配置 —> 高级配置 中添加如下内容：

static_config:
  packet-sequence-flag: 255

03｜总结

DeepFlow 通过 eBPF 技术实现的 Full Stack（全栈）、End to End（全链路）、Any Request（每一次应用调用）的数据采集和观测能力，精细化分析每一次调用的端到端过程，每一次请求的全链路得以纤毫毕现，监控时代的疑难杂症在进入可观测性时代后将变得简单易解、手到擒来。

04｜什么是 DeepFlow

DeepFlow 是云杉网络开发的一款可观测性产品，旨在为复杂的云原生及 AI 应用提供深度可观测性。DeepFlow 基于 eBPF 实现了应用性能指标、分布式追踪、持续性能剖析等观测信号的零侵扰（Zero Code）采集，并结合智能标签（SmartEncoding）技术实现了所有观测信号的全栈（Full Stack）关联和高效存取。使用 DeepFlow，可以让云原生及 AI 应用自动具有深度可观测性，从而消除开发者不断插桩的沉重负担，并为 DevOps/SRE 团队提供从代码到基础设施的监控及诊断能力。

GitHub 地址：
​​https://github.com/deepflowio/deepflow​​

访问 DeepFlow Demo[1]，体验零侵扰、全栈的可观测性。

参考资料

[1]DeepFlow Demo: ​​https://deepflow.io/docs/zh/ce-install/overview/​​

eBPF 零侵扰可观测性 Meetup · 上海站即将开启，本次活动主题为《大模型全生命周期管理与 AI 应用的全栈可观测性》，精彩议程大咖云集，欢迎扫描二维码锁定席位～