OTLP Example logging with incorrect service.name

[andreasWallnerIFX]

Bug Report

Just a simple report on the OTLP example. I'm running the example as it is here: https://github.com/tokio-rs/tracing-opentelemetry/blob/v0.1.x/examples/opentelemetry-otlp.rs.

Logs to Jaeger will use the service name "unknown_service" instead of the crate name as intended.

Version

version dumps

$ cargo tree | grep tracing
│   │   └── tracing v0.1.41
│   │       ├── tracing-attributes v0.1.28 (proc-macro)
│   │       └── tracing-core v0.1.33
│   │   │   └── tracing v0.1.41 (*)
│   │   └── tracing v0.1.41 (*)
│   │   └── tracing v0.1.41 (*)
│   └── tracing v0.1.41 (*)
│   │   ├── tracing-core v0.1.33 (*)
│   │   └── tracing-error v0.2.1
│   │       ├── tracing v0.1.41 (*)
│   │       └── tracing-subscriber v0.3.19
│   │           ├── tracing v0.1.41 (*)
│   │           ├── tracing-core v0.1.33 (*)
│   │           └── tracing-log v0.2.0
│   │               └── tracing-core v0.1.33 (*)
│   └── tracing-error v0.2.1 (*)
│   └── tracing v0.1.41 (*)
│   │   └── tracing v0.1.41 (*)
│   │   │   └── tracing v0.1.41 (*)
│   │       │   └── tracing v0.1.41 (*)
│   │       └── tracing v0.1.41 (*)
│   └── tracing v0.1.41 (*)
│   └── tracing v0.1.41 (*)
├── tracing v0.1.41 (*)
├── tracing-core v0.1.33 (*)
├── tracing-opentelemetry v0.30.0
│   ├── tracing v0.1.41 (*)
│   ├── tracing-core v0.1.33 (*)
│   ├── tracing-log v0.2.0 (*)
│   └── tracing-subscriber v0.3.19 (*)
├── tracing-subscriber v0.3.19 (*)

And the opentelemetry stuff:

$ cargo tree | grep opentelemetry
├── opentelemetry v0.29.1
├── opentelemetry-otlp v0.29.0
│   ├── opentelemetry v0.29.1 (*)
│   ├── opentelemetry-http v0.29.0
│   │   ├── opentelemetry v0.29.1 (*)
│   ├── opentelemetry-proto v0.29.0
│   │   ├── opentelemetry v0.29.1 (*)
│   │   ├── opentelemetry_sdk v0.29.0
│   │   │   ├── opentelemetry v0.29.1 (*)
│   ├── opentelemetry_sdk v0.29.0 (*)
├── opentelemetry-semantic-conventions v0.29.0
├── opentelemetry-stdout v0.29.0
│   ├── opentelemetry v0.29.1 (*)
│   └── opentelemetry_sdk v0.29.0 (*)
├── opentelemetry_sdk v0.29.0 (*)
├── tracing-opentelemetry v0.30.0
│   ├── opentelemetry v0.29.1 (*)
│   ├── opentelemetry_sdk v0.29.0 (*)

Platform

Windows-64

Description

Running the example linked above, all logs that go to Jaeger use "unknown_service" as the service name.
Output from running the example as-is (c888aae), but copied into my project:

$ cargo run --bin repro
    Blocking waiting for file lock on package cache
   Compiling <snip>
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 10.22s
     Running `<snip>\target\debug\repro.exe`
2025-04-22T08:39:37.796814Z  INFO foo: repro: handle foo monotonic_counter.foo=1 key_1="bar" key_2=10
2025-04-22T08:39:37.827525Z  INFO foo: repro: histogram example histogram.baz=10
Metrics
Resource
        Resource SchemaUrl: "https://opentelemetry.io/schemas/1.31.0"
         ->  service.name=String(Static("unknown_service"))
         ->  deployment.environment.name=String(Static("develop"))
         ->  telemetry.sdk.language=String(Static("rust"))
         ->  telemetry.sdk.version=String(Static("0.29.0"))
         ->  service.version=String(Static("0.2.0"))
         ->  telemetry.sdk.name=String(Static("opentelemetry"))
        Instrumentation Scope #0
                Name         : tracing/tracing-opentelemetry
                Version  : "0.30.0"
Metric #0
                Name         : foo
                Description  :
                Unit         :
                Type         : Sum
                Sum DataPoints
                Monotonic    : true
                Temporality  : Cumulative
                StartTime    : 2025-04-22 08:39:37.827313
                EndTime      : 2025-04-22 08:39:38.507583
                DataPoint #0
                        Value        : 1
                        Attributes   :
                                 ->  message: handle foo
                                 ->  key_1: bar
                                 ->  key_2: 10
InternalFailure("[InternalFailure(\"Failed to shutdown\")]")

Looking at opentelemetry_sdk they seem have a separate function to specify the service name,
I tried this code:

--- repro.rs    2025-04-22 10:50:26.262185900 +0200
+++ repro_fixed.rs      2025-04-22 10:51:02.279980000 +0200
@@ -13,13 +13,13 @@
 use tracing_subscriber::{layer::SubscriberExt, util::SubscriberInitExt};

 // Create a Resource that captures information about the entity for which telemetry is recorded.
 fn resource() -> Resource {
     Resource::builder()
+        .with_service_name("blub")
         .with_schema_url(
             [
-                KeyValue::new(SERVICE_NAME, env!("CARGO_PKG_NAME")),
                 KeyValue::new(SERVICE_VERSION, env!("CARGO_PKG_VERSION")),
                 KeyValue::new(DEPLOYMENT_ENVIRONMENT_NAME, "develop"),
             ],
             SCHEMA_URL,
         )

with which I get the expected service.name in the message:

$ cargo run --bin repro_fixed
   Compiling <snip>
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 7.23s
     Running `<snip>\target\debug\repro.exe`
2025-04-22T08:43:57.809098Z  INFO foo: repro: handle foo monotonic_counter.foo=1 key_1="bar" key_2=10
2025-04-22T08:43:57.857634Z  INFO foo: repro: histogram example histogram.baz=10
Metrics
Resource
        Resource SchemaUrl: "https://opentelemetry.io/schemas/1.31.0"
         ->  telemetry.sdk.name=String(Static("opentelemetry"))
         ->  service.version=String(Static("0.2.0"))
         ->  service.name=String(Static("blub"))
         ->  telemetry.sdk.version=String(Static("0.29.0"))
         ->  deployment.environment.name=String(Static("develop"))
         ->  telemetry.sdk.language=String(Static("rust"))
        Instrumentation Scope #0
                Name         : tracing/tracing-opentelemetry
                Version  : "0.30.0"
Metric #0
                Name         : foo
                Description  :
                Unit         :
                Type         : Sum
                Sum DataPoints
                Monotonic    : true
                Temporality  : Cumulative
                StartTime    : 2025-04-22 08:43:57.856932
                EndTime      : 2025-04-22 08:43:58.578611
                DataPoint #0
                        Value        : 1
                        Attributes   :
                                 ->  key_1: bar
                                 ->  key_2: 10
                                 ->  message: handle foo
InternalFailure("[InternalFailure(\"Failed to shutdown\")]")

Sorry if you are already aware of the change and just did not update dependencies yet, but I wanted to raise this cause it stumped me for a while.

[djc]

This crate is getting passively maintained -- happy to review a PR for this.