All Products
Search
Document Center

Application Real-Time Monitoring Service:Supported trace propagation protocols

Last Updated:Mar 11, 2026

Trace context propagation passes tracing metadata -- trace IDs, span IDs, and sampling decisions -- between services in a distributed application. This allows all spans within a request to be correlated into a single end-to-end trace.

Application Real-Time Monitoring Service (ARMS) supports five trace propagation protocols.

ProtocolTypeHeader prefix
EagleEyeAlibaba Cloud proprietaryEagleEye-
W3C Trace ContextW3C standardtraceparent, tracestate
Zipkin (B3)Open sourceX-B3-
JaegerOpen sourceuber-trace-id
SkyWalkingOpen sourcesw8

EagleEye protocol

EagleEye is an Alibaba Cloud proprietary protocol developed by ARMS and widely used across Alibaba Cloud services.

Header fields

HeaderDescriptionExample
EagleEye-TraceIDTrace identifier (random 32-bit string).--
EagleEye-RpcIDHierarchical span relationship. 0 is the parent span; 0.1 and 0.2 are child spans of 0; 0.1.1 is a child of 0.1.0, 0.1, 0.2, 0.1.1
EagleEye-SpanIDSpan identifier (random long integer). Compatible with open-source redundant fields.--
EagleEye-pSpanIDParent span identifier (random long integer). Compatible with open-source redundant fields.--
EagleEye-SampledSampling flag.--
EagleEye-pAppNameUpstream application name.--
EagleEye-pRpcUpstream application interface.--
EagleEye-UserDataBaggage data propagated with the trace.k1=v1&k2=v2

W3C Trace Context protocol

The W3C Trace Context specification is a vendor-neutral standard defined by the World Wide Web Consortium (W3C).

Header fields

HeaderFormatExample
traceparent<version>-<trace-id>-<parent-span-id>-<Sampling identifier> (2-bit version, 32-bit trace ID, 16-bit parent span ID, sampling identifier)00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01
tracestateBaggage data propagated with the trace.k1=v1&k2=v2

Zipkin (B3) protocol

The B3 propagation format is used by Zipkin.

Header fields

HeaderDescriptionExample
X-B3-TraceId32-bit trace identifier.0af7651916cd43dd8448eb211c80319c
X-B3-SpanId16-bit span identifier.b7ad6b7169203331
X-B3-ParentSpanId16-bit parent span identifier.b7ad6b7169203331
X-B3-SampledSampling flag. 1 = sampled, 0 = not sampled.1
baggage-Baggage data prefix. Append the key name after the prefix.baggage-k1=v1, baggage-k2=v2

Jaeger protocol

The Jaeger propagation format is used by Jaeger.

Header fields

HeaderFormatExample
uber-trace-id<trace-id>:<span-id>:<parent-span-id>:<flags>0af7651916cd43dd8448eb211c80319c:b7ad6b7169203331:b7ad6b7169203331:1
uberctx-Baggage data prefix. Append the key name after the prefix.uberctx-k1=v1, uberctx-k2=v2

SkyWalking protocol

The SkyWalking propagation format is used by Apache SkyWalking.

sw8 header

The sw8 header consists of eight hyphen-separated fields. All string values must be Base64-encoded. The total header length must be less than 2,000 characters.

FieldPositionDescription
Sample10 = context exists but can be ignored. 1 = sample and send to backend.
Trace ID2Unique trace identifier. Base64-encoded string of three long values separated by periods (.).
Parent trace segment ID3Globally unique segment identifier. Base64-encoded string.
Parent span ID40 or a positive integer.
Parent service5Base64-encoded string. Must exceed 50 UTF-8 characters.
Parent service instance ID6Base64-encoded string. Must exceed 50 UTF-8 characters.
Parent service endpoint7Endpoint of the first entry span in the parent trace segment. Base64-encoded string. Must exceed 50 UTF-8 characters.
Destination URL8URL of the destination service. Format may differ from <IP address><Port number>. Base64-encoded string.

Example:

1-TRACEID-SEGMENTID-3-PARENT_SERVICE-PARENT_INSTANCE-PARENT_ENDPOINT-IPPORT

sw8-x header

The sw8-x header carries extension fields, also separated by hyphens. Fields can be extended as needed.

The tracking mode accepts null, 0, or 1:

  • null or 0 (default): All spans generated in the current context are not analyzed. Context is propagated upstream by default unless changed during tracking.

  • 1: Spans are analyzed.

How it works

The ARMS agent automatically selects a trace propagation protocol based on the headers present in each incoming request.

Selection flow

Consider a trace that passes through services A, B, and C. When each service receives a request, the ARMS agent follows this logic:

  1. Scan request headers for protocol-specific fields. The scan follows a fixed priority order:

    ARMS agent versionPriority order (highest to lowest)
    v4.5.x and laterW3C > EagleEye > SkyWalking > Jaeger > Zipkin
    v4.x to v4.4.xEagleEye > W3C > SkyWalking > Jaeger > Zipkin
    Earlier than v4.xEagleEye > Jaeger > Zipkin > SkyWalking > W3C
  2. If a matching header is found, the agent restores the trace context from the request and uses the same protocol to propagate context to downstream services.

  3. If no matching header is found, the agent creates a new trace context and propagates it using the highest-priority protocol. By default, this is the EagleEye protocol.

Customize protocol priority

To change the default protocol priority, go to Configuration > Custom Configurations and update the Trace context propagation protocol settings section. For details, see Trace context propagation protocol settings.