[Bug]: Jaeger shows OTLPResourceNoServiceName despite setting service.name resource

[yasin-bozkurt]

What happened?

After upgrading opentelemetry crates from version 0.23 to 0.30, we noticed that the service.name is no longer correctly propagated to Jaeger. Instead of the expected service.name, Jaeger displays the default OTLPResourceNoServiceName.

We define our tracer provider as follows:

use opentelemetry::{global, KeyValue};
use opentelemetry_sdk::{
    trace::SdkTracerProvider,
    Resource,
};
use opentelemetry_semantic_conventions::resource::{CONTAINER_IMAGE_TAGS, HOST_NAME, SERVICE_NAME};

impl<
        Runtime: opentelemetry_sdk::runtime::Runtime
            + opentelemetry_sdk::runtime::RuntimeChannel
            + std::fmt::Debug,
    > MySpanProcessor<Runtime>
{
    fn new<Exporter: SpanExporter + 'static>(
        exporter: Exporter,
        runtime: Runtime,
    ) -> Self {
        Self {
            otel_batch_span_processor: BatchSpanProcessor::builder(exporter, runtime).build(),
        }
    }
}

let exporter = opentelemetry_otlp::SpanExporter::builder()
    .with_tonic()
    .with_endpoint(endpoint)
    .build()?;

let my_span_processor = MySpanProcessor::new(exporter, Tokio);

let tracer_provider = SdkTracerProvider::builder()
    .with_span_processor(my_span_processor)
    .with_resource(
        Resource::builder_empty()
            .with_attributes(vec![
                KeyValue::new(SERVICE_NAME, service_name.clone()),
                KeyValue::new(HOST_NAME, host_name),
                KeyValue::new(CONTAINER_IMAGE_TAGS, image_tag),
            ])
            .build(),
    )
    .build();
let tracer_name = format!("{service_name}-tracer");
let tracer = tracer_provider.tracer(tracer_name);
let _ = global::set_tracer_provider(tracer_provider);

We have tried a couple of alternatives:

• Using Resource::builder().with_service_name(...) instead of a custom attribute list.
• Adding SdkProvidedResourceDetector (and setting the proper env) to the tracer provider builder.
• Explicitly logging the built resource to confirm service.name is present in the final resource.

OpenTelemetry API Version (i.e version of opentelemetry crate)

0.30

OpenTelemetry SDK Version (i.e version of opentelemetry_sdk crate)

0.30

What Exporter(s) are you seeing the problem on?

OTLP

[cijothomas]

service.name is no longer correctly propagated to Jaeger.

If you can verify that the service.name Resource attribute is exported to OTLP, then there is no issue in OTel side of things. (you can use collector's debug output to confirm that the Resource attribute is indeed emitted)
Jaeger product is the one that need to decide how to show service.name.

[yasin-bozkurt]

@cijothomas Thanks for the quick reply!

I did a tcpdump on the Jaeger collector side to compare the payloads sent by the opentelemetry crates version 0.23 and 0.30.

With v0.23, the ExportTraceServiceRequest includes a properly populated resource_spans field. For brevity, I’ve omitted most of the fields and the actual resource values, but all three attributes (service.name, host.name, and container.image.tags) defined in our code are present:

GRPC Message: /opentelemetry.proto.collector.trace.v1.TraceService/Export, Request
Protocol Buffers: /opentelemetry.proto.collector.trace.v1.TraceService/Export,request
    Message: opentelemetry.proto.collector.trace.v1.ExportTraceServiceRequest
        [Message Name: opentelemetry.proto.collector.trace.v1.ExportTraceServiceRequest]
        Field(1): resource_spans  (message)
            ...
            Message: opentelemetry.proto.trace.v1.ResourceSpans
                [Message Name: opentelemetry.proto.trace.v1.ResourceSpans]
                Field(1): resource  (message)
                    [Field Name: resource]
                    [Field Type: message (11)]
                    .000 1... = Field Number: 1
                    .... .010 = Wire Type: Length-delimited (2)
                    Value Length: 101
                    Value: XXX
                    Message: opentelemetry.proto.resource.v1.Resource
                        [Message Name: opentelemetry.proto.resource.v1.Resource]

However, with v0.30, using the same Jaeger collector and identical resource setup in code, the resource_spans field is present but the resource payload is empty (Value Length: 0):

GRPC Message: /opentelemetry.proto.collector.trace.v1.TraceService/Export, Request
Protocol Buffers: /opentelemetry.proto.collector.trace.v1.TraceService/Export,request
    Message: opentelemetry.proto.collector.trace.v1.ExportTraceServiceRequest
        [Message Name: opentelemetry.proto.collector.trace.v1.ExportTraceServiceRequest]
        Field(1): resource_spans  (message)
            ...
            Message: opentelemetry.proto.trace.v1.ResourceSpans
                [Message Name: opentelemetry.proto.trace.v1.ResourceSpans]
                Field(1): resource  (message)
                    [Field Name: resource]
                    [Field Type: message (11)]
                    .000 1... = Field Number: 1
                    .... .010 = Wire Type: Length-delimited (2)
                    Value Length: 0
                    Value: <MISSING>
                    Message: opentelemetry.proto.resource.v1.Resource
                        [Message Name: opentelemetry.proto.resource.v1.Resource]

Let me know if there is anything else I can do to help investigate.

[cijothomas]

docker run --rm --name jaeger \
  -p 16686:16686 \
  -p 4317:4317 \
  cr.jaegertracing.io/jaegertracing/jaeger:2.8.0

use opentelemetry_sdk::trace::SdkTracerProvider;
use opentelemetry::trace::{Tracer, TraceContextExt};
use opentelemetry::KeyValue;
use opentelemetry_otlp::SpanExporter;
use opentelemetry_sdk::Resource;
use std::sync::OnceLock;
use opentelemetry::global;

fn get_resource() -> Resource {
    static RESOURCE: OnceLock<Resource> = OnceLock::new();
    RESOURCE
        .get_or_init(|| {
            Resource::builder()
                .with_service_name("demoapp")
                .build()
        })
        .clone()
}

fn init_traces() -> SdkTracerProvider {
    let exporter = SpanExporter::builder()
        .with_tonic()
        .build()
        .expect("Failed to create span exporter");
    SdkTracerProvider::builder()
        .with_resource(get_resource())
        .with_batch_exporter(exporter)
        .build()
}

#[tokio::main]
async fn main() {
    let tracer_provider = init_traces();
    global::set_tracer_provider(tracer_provider.clone());
    let tracer = global::tracer("basic-otlp-example-grpc");
    tracer.in_span("Main operation", |cx| {
        let span = cx.span();
        span.add_event(
            "Nice operation!".to_string(),
            vec![KeyValue::new("k1", 100)],
        );
        span.set_attribute(KeyValue::new("another.key", "yes"));

        tracer.in_span("Sub operation...", |cx| {
            let span = cx.span();
            span.set_attribute(KeyValue::new("another.key", "yes"));
            span.add_event("Sub span event", vec![]);
        });
    });

    tracer_provider.shutdown().expect("Failed to shutdown tracer provider");
}

[cijothomas]

I tried the above setup and service.name is showing up in jaeger:

is this matching what you are expecting to see?

[yasin-bozkurt]

@cijothomas Thanks for the repro! Your example helped narrow things down. The difference was that you used a SpanExporter directly, while we use a custom SpanProcessor. It looks like in our case we have to set the resource on the SpanProcessor instead of passing it to the TracerProviderBuilder.

Is this the intended behavior? I would have expected the SdkTracerProvider::builder().with_resource(...) call to ensure the resource is properly applied regardless of the processor or exporter. Should it silently ignore the resource if it's not applied directly to the SdkTracerProvider?

Thanks again for the quick responses and the minimal repro — it really helped pinpoint the issue!

[cijothomas]

SdkTracerProvider::builder().with_resource(...)

The above is good enough only if the processors are handling Resource properly! The processor has to pass Resource to the exporter, as SdkTracerProvider has no direct knowledge of the Exporter. Example is here: https://github.com/open-telemetry/opentelemetry-rust/blob/main/opentelemetry-sdk/src/trace/span_processor.rs#L173

Actual implementation depends on your custom processor, but should be similar.

(Btw, what is the reason why you have a custom SpanProcessor?)

[yasin-bozkurt]

I see! Would it make sense to remove the default implementation of set_resource in the SpanProcessor trait? I assume there's a reason for keeping it, but removing it might have prevented our issue and could help prevent similar issues for other users as well.

(Btw, what is the reason why you have a custom SpanProcessor?)

We are doing this to set additional span attributes that are part of the trace baggage.

[cijothomas]

(Btw, what is the reason why you have a custom SpanProcessor?)
We are doing this to set additional span attributes that are part of the trace baggage.

Can you share a minimal repro showing the full setup? Are you doing something like https://github.com/open-telemetry/opentelemetry-rust/blob/main/examples/tracing-http-propagator/src/server.rs#L161-L162

The enrichmentment processor should not have impacted this, if used like above?

(Once you share a repro, we can investigate more, and potentially see how to improve this or document this better)

[yasin-bozkurt]

Can you share a minimal repro showing the full setup? Are you doing something like https://github.com/open-telemetry/opentelemetry-rust/blob/main/examples/tracing-http-propagator/src/server.rs#L161-L162

Yes, that is very similar to what we are doing.

The issue on our side was that we implemented a custom SpanProcessor, but we didn’t realize that the set_resourcemethod was added as a new (default-implemented) function on the SpanProcessor trait. Since it has a default no-op implementation, the compiler didn’t complain, and our processor silently ignored the resource that was being passed in.

[cijothomas]

@yasin-bozkurt If you were using a SpanProcessor just to enrich attributes, then you don't have to do anything with set_resource! Its only required if its an exporting processor like the Simple/Batch one... Its not clear if you are replacing Batch/Simple processor.. Need to see full code.