Keeping trace context intact across every hop you own

Overview

An insurance services provider runs a mix of vendor agents and OpenTelemetry instrumentation. Traces regularly ended at the boundary between them. AceMQ provides continuous support keeping propagation working as services change.

Challenge

Different services propagated context using different header formats, and services on either side of a boundary were configured to accept only one. Where a request crossed from a vendor-agent service to an OpenTelemetry one, the incoming context was ignored and a new trace started. Asynchronous hops through the message broker lost context entirely because nothing was injecting it into message headers. Every new service that joined the estate reintroduced the problem in a new place.

Environment

Hybrid estate with Java and .NET services, mixed vendor-agent and OpenTelemetry instrumentation, message-driven integration between tiers.

Approach

Support covers the instrumentation the customer owns, not the vendor's ingest platform. We standardized on a single propagation format accepted everywhere, made context injection on messaging hops part of the shared library rather than each team's responsibility, and added a synthetic end-to-end trace check that fails when propagation breaks.

Solution

• 24/7 support with a 15-minute emergency SLA and named senior engineers who hold the estate's trace topology
• Single propagation format standardized across vendor-agent and OpenTelemetry services, with both accepted during transition
• Message broker context injection and extraction moved into a shared library so async hops propagate by default
• Synthetic end-to-end transaction running continuously and alerting when a trace fails to span the full path
• Sampling configuration reconciled across services so upstream and downstream decisions agree
• Instrumentation review built into the customer's new-service checklist so each addition arrives already correct

Outcome

Technologies