金融交易系统可观测性方案：全链路追踪、分层告警与监管留存

交易系统的可观测性难点

证券、银行的交易链路有两个特点：一是链路长，从 App 到网关、风控、订单、撮合、清算，一次请求要穿过十几个服务；二是对时延和一致性极敏感，毫秒级抖动就可能造成对账差异。传统的「出问题再查日志」在这里行不通，需要全链路追踪和事前告警。

全链路追踪：一次下单的完整视图

在炬鲸 OBSERVE 里，一个 order_id 能串起整条链路。排查时输入订单号，直接看到它在各服务间的耗时分布：

SELECT service, sum(duration_ms) AS total_ms, count(*) AS spans
FROM spans
WHERE order_id = '20261022001234'
GROUP BY service
ORDER BY total_ms DESC

哪个服务是瓶颈一目了然。配合火焰图定位到具体方法，再下钻到该 span 关联的日志和 SQL 慢查询，定位时间从小时级压到分钟级。

告警要分层，不能一锅端

金融系统的告警最怕「要么不响、要么狂响」。建议分三层：

1. 基础层：CPU、内存、磁盘、连接池等资源指标，阈值告警；
2. 业务层：下单成功率、委托响应时延 P99、对账差异金额，用环比和同环比告警；
3. 链路层：错误率突增、某服务 P99 抖动，结合 trace 采样自动诊断。

三层分别对应不同的通知渠道和升级策略：基础层推给值班运维，业务层推给交易团队并同步风控，链路层在深夜自动静默、白天才通知。核心是隔离爆炸半径，嘈杂的基础告警绝不能淹没真正动钱的业务告警。

业务与基础设施联动

交易失败的瞬间，两个问题会同时冒出来：代码改了什么、基础设施坏了什么。让一个 order_id 同时返回 span、日志、刚上线的部署版本和宿主机 CPU 曲线，排查就从「很慢，正在查」变成「撮合服务 14:03 的发布让 P99 退化 300ms，正在回滚」。这就是分钟级和小时级故障的区别。

监管合规与数据留存

金融行业对日志留存和审计有硬性要求。炬鲸 OBSERVE 支持按监管要求配置分级留存：交易类日志保留 5 年、一般运行日志 1 年、告警记录 3 年，冷数据自动转存对象存储。所有查询操作留审计痕迹，谁在什么时间查了什么数据、导出了什么，都能追溯。

落地节奏建议

分两步走：先用两周把交易核心链路（下单、撤单、撮合）接上 trace 和基础告警，跑通后逐步扩展到账户、清算等周边系统。上线前做一次演练：给撮合服务注入一个合成延迟，看告警多久触发、值班多久定位到 span。若「抖动到确诊」超过十分钟，先把告警收紧再信任它。用 MTTR 作为衡量标准，工具没把它降下来，埋点就是装饰。