FinPoints 是一家位于新加坡全球领先的金融交易科技提供商，目前主要面临的挑战是确保交易系统的高可用性（99.9%）和低延迟（50ms）。为此，FinPoints 引入了 DeepFlow 可观测性平台，实现零侵扰的全栈监控，快速定位和解决问题，显著提升了运维效率。通过构建 SRE 黄金指标视图，团队能够实时监控和分析服务运行状态，确保系统的高性能和可靠性。

01｜FinPoints 业务运维挑战

与一般行业不同，金融交易行业每时每刻都在处理实时的行情报价和交易订单执行，对稳定性及延迟着苛刻的要求。通常情况下，金融交易系统等核心服务需要保证 99.9% 的可用性和 50ms 内的延迟，以确保交易的准确性和及时性。基于这样的市场需求下，如何保证 99.9% 的可用性和极低的响应时延对于运维和开发人员来说，是一个巨大的挑战。

• 快速定位和恢复故障是降低停机时间的关键因素。对于 FinPoints 来说，目前最大的挑战在于全栈（应用、系统、网络）问题的快速定位。如果不能迅速定位问题，就无法及时找到相关负责人进行处理。以网络问题为例，如何能快速介入并解决问题，我们需要提供详细的数据和诊断信息。这种数据驱动的方法能够加速问题的解决，确保系统的高可用性和稳定性。
• 核心服务对极低延迟的需求。目前，FinPoints 的后台服务采用微服务架构，并部署于 Kubernetes 容器环境中，缺乏调用链追踪、东西向流量监控等能力，使得快速定位异常服务变得极为困难。虽然我们已经有服务日志数据，但这些日志主要用于在明确服务或接口存在异常后进行根因分析。插入代码以获取可观测数据的方法无法采用，因为它会显著增加时延。为应对这些挑战，我们引入了 DeepFlow 可观测性平台。DeepFlow 能够以零侵扰的方式提供业务的全栈可观测性数据。这种方法不仅可以快速定位应用协议解析、调用链追踪、进程 CPU 性能剖析、操作系统响应时延及网络传输质量的问题，还能在不影响业务的情况下迅速识别异常的服务和接口。

02｜SRE 黄金指标视图

为了满足服务 99.9% 的可用性要求和 50ms 响应时延的服务级别目标（SLO），我们构建了一个 SRE 黄金指标视图。这一视图帮助团队聚焦于关键性能指标，可利用服务端异常与建连失败指标量来监测可用性是否达标，利用响应时延指标量监测响应时延是否达标。SRE 黄金指标视图帮助我们实时监控和分析服务的运行状态，确保在任何时候都能迅速识别和处理潜在问题，以维持高水平的服务可用性和性能。

FinPoints 的核心业务已经全面云原生化，通过全球网络服务提供商进行外部访问，同时还需要与全球金融机构进行接口对接。因此，在制定服务水平目标（SLO）时，不仅需要对核心业务的关键性能指标进行监控，还必须对网络质量和第三方服务的关键性能指标进行监控。这样才能在发生故障时，快速识别并明确责任归属。

业务访问关系图

接下来深入解读下，FinPoints 基于 DeepFlow 构建的零侵扰的 SRE 黄金指标视图，视图由 Core Business、 K8s Services 的服务性能指标及关键 Network 性能指标组成。

• Core Business 服务性能指标：主要监控核心服务及接口的请求速率、响应时延及服务端异常指标量。配置相应的告警策略，告警触发内部研发优先处理。

Core Business 服务性能指标

• K8s Services 服务性能指标：主要监控核心服务提供对外服务的请求速率、响应时延及服务端异常指标量。配置相应的告警策略，告警触发第三方服务团队优先处理。

K8s Services 服务性能指标

• Network 性能指标：主要监控客户端访问核心服务、核心服务之间以及核心服务访问第三方服务的网络质量，主要关注网络流量、网络重传率，建连时延及网络异常四个指标量。配置相应的告警策略，告警触发网络服务商优先处理。

Network 性能指标

03｜服务问题如何快递定位？

2024年x月x号22点10分，运维团队收到告警，前端业务出现访问异常。经过约3小时的人工日志分析，发现约 5个服务存在异常。问题的根本原因是流量突增导致线程池占满，进而引发服务响应异常。通过紧急扩展线程池容量，成功恢复了业务的正常访问。在此过程中，问题定位依赖日志分析。在微服务架构下，需要逐个服务翻查日志，导致耗时过长，严重影响了制定的 SLO。

服务定位过程对比

经过与 DeepFlow 售后工程师就此现象沟通，可利用 SRE 黄金指标视图中 Core Business 模块快速发现异常服务。分析请求速率，发现在 22:04 分（早于报障时间）请求速率开始突增，且在 22:04 分开始部分服务的响应时延也开始增加，在此时间段客户端及服务端都出现了异常。整个数据观测下来，快速找到了 p**p 及 p**f等服务存在问题，然后快速调出这些服务的日志，可明确为线程池异常导致。

SRE 黄金指标视图

DeepFlow 零侵扰外部黑盒方式采集的各项指标，是的 SRE 团队能够利用黄金指标在报障时间之前观测到问题，并且可以在分钟级别内定位到根因，从而确保 99.9% 的系统可用性。这种监控和分析能力极大地提升了故障检测和响应的效率，帮助团队在问题影响用户体验之前进行干预和解决。

04｜异常客户端如何快速锁定？

2024年x月x号17点40分监控告警中心反馈一台中间件 Redis 所在的服务器异常，通过基础设施监控平台发现服务器带宽被打满，以及通过 ethtool 或者 ip -s 等基础命令工具只能查看网卡的访问流量带宽情况。需要快速找到是哪个客户端将带宽打满，恢复环境。接下来分享下利用 DeepFlow 平台是如何快速锁定打流的客户端。

带宽使用情况

在网络-路径分析搜索的服务端输入访问的 Redis 的服务 IP，将立马可见在所查询时间范围内客户端访问 Redis 的流量情况。通过流量速率折线图，可以直观的看到在 17:38，一个 sync 服务流量开始突增。

流量速率

进入右滑框，利用知识图谱能快速知道 sync 服务所属的区域、集群、命名空间、容器节点、POD 等服务相关信息，对于锁定服务及服务负责人有明显提效。

知识图谱

放在过去，该类问题我们需要层层排查每个环节的监控，并且需要用抓包等工具确认流量的具体来源，再通过 K8s 排查 IP 与应用的对应关系，排查过程繁琐且需要消耗大量的人力。在使用 DeepFlow 后，对于该类场景，仅需要输入一个 IP，30秒完成问题的排查定位，非常的高效。

05｜单笔业务如何快速追踪？

一般业务中曾经使用 APM 插桩的方式，利用插桩，应用程序可以暴露非常丰富的观测信号，包括指标、追踪、日志、函数性能剖析等。然而插桩的行为实际上改变了原始程序的内部状态，从逻辑上并不符合可观测性「从外部数据确定内部状态」的要求。并且 Finpoints 考虑到 Skywalking 对现有环境的性能消耗比较大，因此使用 DeepFlow 这种基于 eBPF 和 Wasm 技术实现零侵扰（Zero Code）、全栈（Full Stack）的指标、追踪、调用日志、函数剖析数据采集的工具，能更加适配于 Finpoints 的落地实践。

追踪效率对比

了解到 DeepFlow 目前自动化追踪机制，在跨线程的时候会存在链路的情况，但可利用全局 ID 解决这个问题，在此之前研发为了方便查询问题，在针对单笔业务代码里面增加过一个全局 ID 透传给了所有服务，DeepFlow 正好利用此 ID 追踪出单笔业务经过的所有系统及网络位置。此外，DeepFlow 通过 eBPF 技术将未携带 traceid 等中间件、数据库的调用请求补足，实现任意调用的分布式追踪。通过如下火焰图可快速发现一次调用的瓶颈是哪个服务、哪个进程、哪个网络节点。

全栈调用链追踪

06｜价值总结：实现 SRE 99.9% SLO

通过引入 DeepFlow，FinPoints 成功实现了 SRE 99.9% SLO，显著提升了系统的稳定性和可靠性。DeepFlow 的零侵扰可观测性、全栈监控、快速问题定位和分布式追踪能力，使得 FinPoints 能够在分钟级别内发现并解决问题，确保了系统的高可用性。同时，DeepFlow 的自动化监控和分析功能，大大提高了运维效率，使团队能够专注于更具战略性和创新性的工作。

FinPoints 的成功案例表明，现代金融交易行业对技术的依赖日益增加，通过引入先进的监控和分析平台，如 DeepFlow，企业能够显著提升系统性能和客户满意度。实现 SRE 99.9% SLO 不仅是技术上的突破，更是 FinPoints 对客户承诺的体现，为全球金融交易行业树立了新的标杆。

DeepFlow 的引入不仅帮助 FinPoints 实现了高效的故障定位和恢复，还为其提供了全面的性能监控和安全保障。在未来，FinPoints 将继续依托 DeepFlow 等先进技术，持续优化系统性能，提升客户体验，推动金融科技的创新与发展。通过这些努力，FinPoints 不仅达成了 SRE 99.9% SLO，还为行业其他企业提供了宝贵的经验和参考，助力全球金融交易行业迈向更高的水平。

欢迎大家报名参与 7月27日·深圳 的《零侵扰、云原生的可观测性工程实践》线下活动，与腾讯、中国移动、ByConity、顺丰、店匠、塞讯验证、云原生社区等可观测性领域中的技术专家一起，探讨行业发展趋势、应用场景、落地路径。