Define the fallback case for service.name

[carlosalberto]

Fixes #1241, #1237

This is a very minimalistic clarification based on what currently many SIGs do (providing a fallback based on the running service), finally defaulting to the unknown_service literal.

[Oberon00]

In my opinion, this is the wrong place to specify this. I mean, it's fine to additionally specify it here, but we need a list of required resources in the SDK specification. Maybe https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/resource/sdk.md, although in principle it applies to tracing, metrics and probably logging SDK.
I think we should not assume that SDK implementers will read all resource semantic conventions.

[carlosalberto]

I think we should not assume that SDK implementers will read all resource semantic conventions.

Fair point. I think this documentation needs to be here, but we also need to mention this in the main sdk.md document, with a link to the specific case of service.name, as this is a rather important item.

[Oberon00]

We probably also want that for the telemetry.sdk resources BTW.

[andrewhsu]

@open-telemetry/specs-approvers should this really be P1 since the linked issues #1241, #1237 are also P1?

[jmacd]

Based on this comment, #1241 (comment), I'm inclined to promote my own suggestion above:

#1269 (comment)

Explicitly, it means that we can remove some of the words in this PR and simply specify one of the two options in my comment.

[austinlparker]

Just as a note, I think whatever the decision is here needs to be something that is obvious to an operator/consumer of the telemetry and something that is non-suitable for actual usage (such as a 'smart' derived name based on command line or whatnot). Ultimately the name of a service is a logical decision made by humans who are interpreting data, but if we're too clever about it, some users may defer to the cleverness which is good up until the moment it isn't. An obvious default that isn't suitable for long-term usage satisfies both of these conditions.

[jmacd]

The semantic conventions in https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/resource/semantic_conventions/process.md already contain the command name, and the telemetry SDK details are built in (https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/resource/semantic_conventions/README.md), so based on @austinlparker's comment I think when service.name is not set exporters MUST use opentelemetry_service as a fallback.

[carlosalberto]

After a few iterations myself, I think we either go with:

1. Something standard based on the semantic conventions (as @jmacd proposed), such as process.executable.name or process.command - with a fallback to opentelemetry_service or unknown_service, OR
2. Fallback directly to opentelemetry_service or unknown_service.

Opinions? cc @yurishkuro @Oberon00

[yurishkuro]

I prefer "unknown" to be in the name. I don't have a strong opinion on auto-resolvers, but I share Austin's concern with them not doing the right thing and being worse than the default.

[jmacd]

I support "unknown"

[carlosalberto]

Ping @Oberon00 (as I'm also slightly inclined to use unknown_service without the fallback, for the operators interaction that Austin mentioned).

[Oberon00]

"unknown" is fine. Or "unknown:EXE-NAME".

[carlosalberto]

Ping @Oberon00 @austinlparker

[austinlparker]

lgtm

I think there is awareness now for the problem with #1034, so not blocking this PR (trusting you to sort this out properly)

[carlosalberto]

I think there is awareness now for the problem with #1034, so not blocking this PR (trusting you to sort this out properly)

Thanks! Have made service.instance.id non-required, so this can be properly addressed in #1034