WMS and TMS span warehouses, carriers, and back-ends, so failures are hard to localize. This plan threads an order ID through every system's trace, unifies warehouse, API, and device logs, and layers tiered alerting with retention and compliance so any order is localizable in minutes.
A single logistics order travels through a dozen systems: order placement, WMS warehouse operations, TMS transport scheduling, settlement and reconciliation. Timeouts, inventory mismatches, and stuck waybill states are usually the product of several systems interacting — no single system's logs can localize them. The core idea of this plan: make the order number the trace_id that runs through every system, so the unit of troubleshooting is the order itself rather than some abstract service boundary.
Do context propagation at the gateway and RPC layer: write the order number, waybill number, and warehouse code into the trace baggage so every service reports its span with them attached. Then in OBSERVE, searching by order number shows every service that order touched and how long each step took, in one waterfall. The key to landing this is agreeing on the propagation field names (e.g. orderNo, waybillNo) and injecting them in a shared SDK by default, rather than letting each team roll its own. For legacy systems that can't adopt tracing yet, at least standardize on an orderNo= prefix in their logs so correlation still works as a fallback; you lose the waterfall view, but you keep the one-keyword search that finds the order everywhere it touched. Keep the baggage small: a handful of identifiers (order, waybill, warehouse, customer) is enough, and bloated baggage inflates every span on the wire, which on a high-throughput warehouse shows up as measurable overhead. A good rule is to carry no more than five short string fields, and never put free-form text or large payloads in baggage.
First, warehouse operation logs: PDA scans, putaway, picking, review, packing — each step carries its job number and bin code, which becomes the basis for inventory reconciliation and dispute resolution. Second, API call logs: integrations between WMS, TMS, and upstream e-commerce platforms, recording request/response summaries, latency, and return codes — interface timeouts usually surface here first. Third, device logs: AGVs, sorting lines, and scales. Send all three into OBSERVE, tagged with warehouse and orderNo, so troubleshooting drills down from a business symptom to the exact scan that failed, in the same interface. For device logs, don't try to parse AGV or scale protocols by hand — forward them as structured JSON at the source where you can, and where you can't, write one Grok pattern per device model and version it, so a firmware change doesn't silently break your parsing.
With so many links in the chain, alerts must be layered. Infrastructure (CPU, disk, GC) uses fixed thresholds; business metrics (order processing delay, picking timeout rate, API failure rate) use dynamic baselines and period-over-period comparison; the trace layer (a service's P99 jump, dependency timeouts) uses SLO burn-rate alerts. The critical part is suppression: collapse cascading alerts from the same warehouse into one, so on-call chases a single root cause instead of dozens of pages. During promotions, temporarily lower thresholds and shorten windows for a few days to raise sensitivity where it matters. A concrete incident shows how this pays off: when a sorting line's PLC started throwing intermittent errors, the first signal was not an application error but a spike in the AGV device logs plus a small rise in the picking timeout rate. With the three layers wired together, on-call traced the affected order numbers, confirmed the line was the common dependency, and isolated it before a single customer noticed — instead of grepping three systems by hand for an afternoon.
Logistics logs are both troubleshooting data and audit evidence. Keep business logs 30 days and reconciliation/sign-off records 90 days or more, and isolate permissions by warehouse to avoid cross-customer data leaks. For rollout order, wire up tracing before broad log collection — within two weeks you go from "no idea where it's stuck" to "localize any order in five minutes by order number." Start with order-ID propagation and one warehouse, prove the five-minute localization on a real incident, then roll out to the rest of the network. The payoff isn't just faster incidents — it's that inventory disputes and carrier claims now have a single, auditable trail you can hand to the business instead of a stack of disconnected logs.