Jaeger exporter service.name clarification needed

[jkwatson]

What are you trying to achieve?

#1222 includes language that requires the Jaeger exporter to use the service.name attribute of the Resource, but does not explain how the exporter should behave if that attribute is missing from the Resource.

Should the exporter be configured with a fallback service name, or should it fail to export any spans without a valid Resource service.name entry?

[arminru]

@yurishkuro is there any fallback in Jaeger if it's not provided?
If so, I'd just not set it in that case and we could fix the spec by adding an , if present here:

opentelemetry-specification/specification/trace/sdk_exporters/jaeger.md

Lines 24 to 26 in f2869a3

	Critically, Jaeger backend depends on `Span.Process.ServiceName` to identify the service
	that produced the spans. That field MUST be populated from the `service.name` attribute
	of the [`service` resource](../../resource/semantic_conventions/README.md#service).

[yurishkuro]

Most Jaeger SDKs will refuse to initialize if the service name (a required parameter) is blank, e.g.

• https://github.com/jaegertracing/jaeger-client-python/blob/4cde94a984e0ef7ba1fbfe670391514398fe20da/jaeger_client/config.py#L109
• https://github.com/jaegertracing/jaeger-client-go/blob/ca996000929ca5e2c70b9bcd67375836ab410de4/config/config.go#L219

I would expect OTEL in general to guarantee that there is always a resource with non-empty service name. In other words, I don't think this should be solved at the level of Jaeger exporters or any Jaeger-specific functionality.

Whether the SDK should raise an exception or default to some unknown_service constant is up for debate.

To unblock Jaeger exporter work specifically, I would suggest going with unknown_service.

[jkwatson]

Currently, from what I understand, there is no requirement that service.* is present in the Resource. What is required is that if anything service.* is provided, that service.name is included. [although, I don't know if any SDKs have implemented this particular validation].

The java implementation requires a "service name" to be configured into the Jaeger exporter, but it's not clear how that should interact with the service.name on the Resource (I have guesses about how it should, but it's not specified here).

[yurishkuro]

The java implementation requires a "service name" to be configured into the Jaeger exporter

That sounds like a bad take. Jaeger backend uses OTEL collector components and can accept OTLP data directly, so the service name must be present in the native OTEL data.

[jkwatson]

The java implementation requires a "service name" to be configured into the Jaeger exporter

That sounds like a bad take. Jaeger backend uses OTEL collector components and can accept OTLP data directly, so the service name must be present in the native OTEL data.

But, as I mentioned in the part you didn't quote...there isn't a requirement that the service name is present in the Resource.

[yurishkuro]

there isn't a requirement that the service name is present in the Resource.

What's stopping us from making it a requirement?

[jkwatson]

there isn't a requirement that the service name is present in the Resource.

What's stopping us from making it a requirement?

I don't know. I'm honestly not sure why it isn't a requirement already. That would be a satisfactory resolution to this issue for me.

[yurishkuro]

I am suggesting making it a requirement, and use unknown_service in the exporter as a fallback, since not all Resource API may be able to enforce required attributes.

[jkwatson]

I am suggesting making it a requirement, and use unknown_service in the exporter as a fallback, since not all Resource API may be able to enforce required attributes.

Do you mind championing a spec change for this? I can create the issue if you'd like?

[jkwatson]

@yurishkuro #1241

[andrewhsu]

@tedsuo fyi

[tedsuo]

Hey hey! I would also like to see service.name as a required attribute. Almost every tracing system has a version of this which is required.

[yurishkuro]

I think this should be closed in favor of #1241

[jkwatson]

I think this should be closed in favor of #1241

I'd rather keep this open until that one is resolved, since this won't actually be resolved until that one is agreed to and merged.

[jkwatson]

So, with #1269 merged, does that mean we should remove the fallback service-name configuration option for the Jaeger exporter and always use whatever is on the Resource? I think 'yes', but it would be good to get a firm confirmation.

[yurishkuro]

I think fallback configuration should be removed, but it may sense to keep the fallback logic to default to unknown_service if the SDK fails to enforce that. However, my preference would be if the exporter SPI was explicitly defined to require the service name from the SDK at construction.

[carlosalberto]

@jkwatson @yurishkuro My feeling is that with #1294 this should be done, unless you want further clarification, to be on the safe side ;)

[Oberon00]

I think we want further clarification, which is why I had objected to closing #1241 -- I did not realize this issue here also exists.

[jkwatson]

I think our Jaeger exporter spec still needs clarification on this, yes. I wouldn't close this until that document has been updated to explain the 2 different possible resources for the service.name and when to choose which.

[tedsuo]

@yurishkuro I'm concerned that we are going to have to drop Jaeger as a v1.0 requirement unless we get the TBD's in the jaeger exporter spec resolved for OTel this week – this is blocking v1.0 at this point. Do you feel like you have enough information to add these attribute translations to the spec? Can we tap a jaeger member of the OTel community to make this PR?

[yurishkuro]

@tedsuo #1374

[yurishkuro]

@jkwatson is there still an open issue here? I don't particularly like how the notion of Resource.getDefault is hidden away and there is more than one place that explains something about service.name, but cumulatively those places do seem to define a clear path. It may be worth mentioning it in the jaeger exporter, e.g. "if Resource does not specify service.name, then get it from Resource.getDefault".

[jkwatson]

@jkwatson is there still an open issue here? I don't particularly like how the notion of Resource.getDefault is hidden away and there is more than one place that explains something about service.name, but cumulatively those places do seem to define a clear path. It may be worth mentioning it in the jaeger exporter, e.g. "if Resource does not specify service.name, then get it from Resource.getDefault".

heh. I was literally about to write this as well. I do think it would be good to mention that, yes.

[cijothomas]

For Zipkin also: #1380