交易系统对时延和稳定性敏感，出错要能秒级定位，还要能追溯审计。这篇讲毫秒级接口监控、撮合链路追踪、tick 数据与日志关联、操作审计留痕与收盘后复盘，面向券商技术团队。
证券交易系统有个特点：白天是分秒必争的生产线，盘后是必须经得起审计的账本。可观测平台在这里要同时回答两个问题——出故障能不能秒级定位，以及出了事能不能说得清。这篇讲我们在券商交易系统上的落地做法。
交易系统的核心接口（下单、撤单、查询）对时延极度敏感，P99 延迟几十毫秒和几百毫秒是两回事。监控不能只看平均延迟，要看分位数：P50、P95、P99 分开监控，平均延迟会被少量慢请求拉偏，掩盖真正的毛刺。
阈值还要动态。开盘和尾盘是委托高峰，成交量、并发数比盘中高几倍，固定阈值要么高峰误报、要么低谷漏报。我们按时段分段设阈值，或按"时延相对昨同期"的偏离比例告警，而不是死盯一个绝对值。行情接口本身的延迟也要纳入监控，因为"行情慢了"往往会连锁导致"策略和委托慢了"。
一笔委托从客户端到网关、到风控、到撮合引擎、再到回报，中间要过七八个系统。故障定位最大的痛苦是"委托卡在哪一步了"。我们用链路追踪给每笔委托打一个贯穿全程的 ID，每个环节记录进出时间戳，整条链路串起来后，卡点一目了然。
关键是把委托 ID 定义成统一的关联字段：网关、风控、撮合、清算各系统日志里都带上同一个委托 ID，配合 trace_id，就能从"某个委托超时了"直接下钻到"是撮合引擎在 10:02:03 处理慢"，而不是逐个系统翻日志。对高频场景，采样要谨慎，委托链路建议全量保留或至少对超时、拒绝的委托强制保留。
交易故障里有一类特别难查：行情波动时出现的偶发错误。tick 数据和日志本是两套数据，分开看不出来关系。我们把 tick 时间戳和日志时间戳对齐，让检索时能按"这段行情剧烈波动的时间窗"去筛日志，快速判断一次报错是不是由行情突变触发的。
做法上，行情网关把 tick 数据以结构化指标形式发到平台，检索侧支持按时间窗交叉过滤日志和行情指标，配合可视化把行情曲线和错误日志画在同一时间轴上，一眼看出相关性。
交易系统的操作必须留痕：谁改了风控参数、谁手动干预了委托、谁导出了数据，全部记录。操作审计日志独立存储、只追加、不可删除，给合规和审计角色只读权限。盘后复盘时按"人、时间、动作、对象"四要素检索，几分钟出报告。
除了合规审计，我们建议每天盘后做一次自动化复盘：把当天的告警、慢请求、错误日志汇总成一份报告，标出最值得关注的事件，第二天开盘前负责人扫一遍，把隐患在开市前清掉。
交易系统的可观测性，核心是"快"和"准"：故障定位要快，审计追溯要准。把这两个字做实，比堆功能有用得多。