Working With Distributed Tracing with OpenLegacy: Propagating Trace ID and Span ID

Introduction: Distributed Tracing Support in OpenLegacy

OpenLegacy enables seamless integration of legacy systems with modern applications and microservices architectures. For organizations looking to achieve end-to-end observability, OpenLegacy supports distributed tracing by recognizing and propagating trace IDs and span IDs via HTTP request headers.

What Does OpenLegacy Support?

• OpenLegacy APIs automatically extract tracing information from incoming HTTP headers using widely adopted formats (B3, W3C Trace Context).

• These trace IDs and span IDs are then included in logs and traces, making it possible to visualize, monitor, and debug complete transactions—from the user interface to the mainframe.

Why Does OpenLegacy Support Distributed Tracing?

• Visibility: In a microservices world, requests often traverse dozens of services and legacy backends. Distributed tracing shows how requests propagate across services.

• Diagnostics: Tracing context enables correlation of logs and error events, drastically reducing time to resolution for issues that span both cloud-native and legacy environments.

• Interoperability: Supporting standard propagation formats ensures OpenLegacy solutions fit smoothly into a company’s existing observability stack (e.g., Zipkin, Jaeger, Datadog, OpenTelemetry).

How Do You Use Tracing with OpenLegacy?

Clients or upstream services should add the appropriate tracing context headers to HTTP requests sent to OpenLegacy APIs. OpenLegacy then consumes and propagates these IDs:

• If trace and span IDs are provided in the headers, OpenLegacy uses them in all related logs and traces.

• If they are not present, OpenLegacy can generate new ones according to the B3 Multi-Header Format standard.

Propagating Trace ID and Span ID: Header Options

OpenLegacy supports all the major tracing propagation standards used across modern distributed systems. Below are the ways to provide trace identifiers to the platform:

B3 Multi-Header Format (Zipkin Style)

X-B3-TraceId: traceId
X-B3-SpanId: spanId

X-B3-TraceId: 12300000000000000000000000000123
X-B3-SpanId: 0000000000000001

B3 Single Header

B3: {traceId}-{spanId}-{samplingState}-{parentSpanId}

W3C Trace Context

traceparent: {version}-{trace-id}-{span-id}-{trace-flags}

traceparent: 00-12300000000000000000000000000123-0000000000000001-01

What Are Trace ID and Span ID?

• traceId: Globally unique identifier for a specific transaction as it travels through various services.

• spanId: Unique identifier for a particular operation (span) within the transaction.

• trace-flags / sampling state: Indicates if tracing is enabled (sampled) or not.

How Should a Trace ID Look?

• 32-character, lower-case, hexadecimal string (0-9, a-f).

• Examples:
  facebabecafebeefdeedfacebeadcafe 00000000000000000000000000000001

Java/Kotlin Example for Generation:

java.util.UUID.randomUUID().toString().replace("-", "")

Broader Context and Practical Implications

• Enhanced Observability: By adopting distributed tracing standards, OpenLegacy bridges modern and legacy workloads under a single, unified monitoring solution.

• Plug-and-Play: You can integrate OpenLegacy APIs into your existing ecosystem—whether using OpenTelemetry, Zipkin, Jaeger, or cloud vendor solutions—by forwarding tracing headers as described.

• Future-Proofing: W3C Trace Context is the industry standard moving forward, but OpenLegacy maintains support for B3 to ease transitions and hybrid architectures.