证券交易链路跨十余个系统、延迟敏感、监管要求高。本文分享指标、日志、链路三合一的告警与排障实践，以及一次真实故障 5 分钟定位根因的完整过程。
证券交易链路横跨十几个系统：柜台、报盘、风控、清算、行情、账户，一笔委托从客户端到交易所要过七八道关卡，全程要求毫秒级。三个特点让可观测性特别难做：一是延迟敏感，一个系统的 GC 停顿都可能放大成整条链路的抖动，一个服务的「小抖动」会在另一个系统上变成延迟告警；二是跨系统多，故障点分散，单看某一个系统的日志根本定位不到根因；三是监管要求高，证监会和交易所对系统可用性、数据留痕有明确要求，出了问题要有据可查、能复盘——这意味着你要的是数据，而不只是一堆告警。
三者分工不同。指标（metrics）负责「发现」：错误率、P99 延迟、吞吐这些聚合值最先暴露异常；日志（logs）负责「解释」：指标告警后，用日志看具体是哪个接口、哪条 SQL、哪个参数出了问题；链路（tracing）负责「定位」：把一次请求跨系统的调用关系串起来，直接指出卡在哪个系统、哪个 span。关键动作是把三者用同一个 trace_id 打通：指标告警点进去能跳到对应链路，链路里点 span 能跳到日志。这三个信号的连接点就是同一个 trace_id，缺了这个，三套数据各说各话，排障时只能来回切换窗口手动对时间。
实践上，我们要求所有系统统一在 HTTP 头里透传 trace_id（x-request-id），这样即使某个系统没接 OpenTelemetry，日志里带上这个 id，也能事后把整条链路拼出来。这一条约定比任何一块仪表盘都值钱，因为它让每一行日志和每一个 span 都用同一把钥匙可寻址。
证券系统的告警要「快而不吵」。三个原则：一是分级，交易时段的核心链路错误率、延迟用 P0 级（即时电话/短信），盘后批处理类问题降为 P2；二是收敛，同一个故障引发的上百条告警要归并成一条，按服务维度聚合再通知，否则值班人前五分钟都在关重复告警；三是熔断，告警通道本身要有抑制机制，避免告警风暴把值班通道打爆。给一条具体的阈值参考：核心委托接口 P99 延迟 > 100ms 连续 3 个采样周期、或 1 分钟错误率 > 1%，触发 P0 告警。再加一条恢复策略：告警恢复后设几分钟的观察窗口，避免抖动反复触发，把值班人从连续轰炸里解放出来。
延迟敏感的交易系统值得按关键路径定义 SLO，比如「滚动 30 天内 99.9% 的委托在 100ms 内完成」。基于 SLO 的燃烧率（burn rate）告警比原始阈值告警更稳：够早触发让人来得及处理，又够晚触发不被噪声淹没。炬鲸 OBSERVE 会持续追踪错误预算，团队一眼能看到一次故障消耗了当月多少预算。
合规侧，驱动排障的那个 trace_id 同样驱动留痕：每一笔委托、每一次风控、每一次拒单，事后都能按 trace_id 完整复盘，满足监管对可重放记录的硬要求。保留策略要按监管下限来定——通常是年而不是天——把 trace 归档当证据看待，而不只是排障工具。
某交易日开盘后，委托接口 P99 延迟从 30ms 飙到 800ms，P0 告警触发。排查顺序：先看指标，确认延迟突增只集中在「风控检查」这一个下游；再看链路，抽样几条慢请求，发现慢在风控系统的「黑名单查询」span，耗时 700ms+；最后看日志，按 trace_id 检索，发现黑名单查询走的是数据库全表扫描，因为当天风控规则热更新时索引没建上。定位用时约 5 分钟，建回索引后延迟恢复。整个过程没重启任何系统，靠的就是指标发现问题、链路缩小范围、日志确认根因这三步。教训也简单：三个信号好不好用，取决于把它们串起来的那一个 id。