面向证券交易、行情等核心系统的可观测性方案，覆盖低延迟链路追踪、聚合行情监控、交易日志留痕与合规审计，并给出交易链路告警阈值的设计。
交易链路是分秒必争的：委托、成交、回报的每一跳延迟都以毫秒计，超时意味着可能错单。同时，监管要求交易日志完整留痕，出问题能回溯到单笔委托。这两点决定了交易系统的可观测性不能只看"有没有告警"，要看"能不能精确到一笔单"。
通用监控关注"系统整体健康"，交易系统则必须回答"这笔委托在第几跳慢了 30ms"。目标不同，方案也要跟着变，从采样到存储，每一层都要按交易的特点重新设计。
交易链路通常分委托、成交、回报三段，中间还要穿过风控、清算等十几个系统，一次委托的调用关系远比普通 Web 服务复杂，链路追踪的价值在这类系统里最直接。
低延迟和高采样天然冲突，所以交易系统要按业务分级采样：核心委托、成交路径 100% 采样，行情推送和查询类接口按比例采样。用 parentbased_traceidratio 配合自定义采样器，把策略按接口前缀区分。
关键是把业务标识（委托编号、证券代码、客户编号）注入 span 属性，这样在链路视图里能直接按"委托编号"检索一笔单的完整路径。埋点本身要轻，只加必要属性，避免给交易线程增加额外序列化开销。对交易线程来说，采样器本身的开销同样要控制，别为了观测反而拖慢交易。
行情数据量巨大，逐条上报不现实。做法是采集端本地聚合，按分钟上报各证券的推送延迟、丢包率、快照不一致数，再在平台侧按市场、板块聚合。异常通常表现为"某个证券代码的快照延迟突增"，这比看整体平均更早暴露问题，也方便定位到具体行情源。
交易链路建议用多级阈值而非单一红线：
分级的好处是：预警级可以只进工作群，严重级才升级到 on-call，避免凌晨被低级别告警刷屏。
交易日志按监管要求保留 15 年以上，用冷热分层存储：热数据保留 30 天供实时检索，冷数据归档到对象存储，需要时再解冻查询。归档日志同样带委托编号和 trace_id，保证可回溯。分层策略要在采集端就打好标签，否则归档后没法按委托编号检索。冷数据解冻后仍可按委托编号检索，处理监管调阅从数天压缩到数小时。