WMS、TMS 系统跨仓、跨运力、跨系统，出问题难定位。本文用订单号贯穿整条链路，统一采集库内作业、接口调用与设备日志，配分层告警与留存策略，落地一套物流可观测方案。
物流系统的一个订单要穿过下单、WMS 库内作业、TMS 运输调度、结算对账十几个系统。订单超时、库存对不上、运单状态卡住，这些故障往往是多个系统交互导致的，单看某一个系统的日志定位不了。方案的核心思路：让订单号成为贯穿所有系统的 trace_id。
在网关和 RPC 层统一做上下文透传：订单号、运单号、仓库编码写进 trace 的 baggage，各服务上报链路时带上。这样在 OBSERVE 里按订单号一搜，能看到这个订单走过的所有服务和每一步耗时。落地关键是约定透传字段名（比如 orderNo、waybillNo），并在公共 SDK 里默认注入，别让每个团队各写一套。对于没改造成链路的老系统，至少在日志里统一打 orderNo= 前缀，靠日志关联兜底。检索时直接按 orderNo: 订单号 过滤，一次就能拉出该订单相关的库内、接口、设备三类日志。
一是库内作业日志：PDA 扫描、上架、拣选、复核、打包，每步的作业单号和货位号写进日志，作为库存对账的依据。二是接口调用日志：WMS 和 TMS、和上游电商平台的对接，记录出入参摘要、耗时、返回码，接口超时最常在这层暴露。三是设备日志：AGV、分拣线、电子秤的异常。三类日志统一进 OBSERVE，用 warehouse、orderNo 做标签，排障时一层层下钻。
物流链路环节多，告警要分层：基础设施层（CPU、磁盘、GC）用固定阈值；业务层（订单处理延迟、拣选超时率、接口失败率）用动态基线和同环比；链路层（某服务 P99 突变、依赖超时）用 SLO 燃烧率告警。关键是抑制：同一仓库的连环告警合并成一条，值班一次只看一个根因，而不是几十条刷屏。大促期间再临时调低阈值、缩短窗口，把敏感度拉上去。日常则保持较宽窗口，避免夜间批量作业的正常波动被误报成故障。
物流日志既是排障数据也是审计证据。建议业务日志留存 30 天、对账与签收类留存 90 天以上，并按仓库隔离权限，防止跨客户数据泄露。上线顺序上，先接链路追踪再铺日志，两周内就能从「不知道卡在哪」到「按订单号 5 分钟定位」，三个月后这套数据还能支撑库存盘点和运力结算的对账。