Recommendation for service.name to be autodetected when not manually set

[Kronos11]

What are you trying to achieve?
I believe changing service.name to Recommended instead of Required will allow SDKs to properly set the values when not found to an appropriate default instead of (unknown_service). This is a terrible default for many cases. One in particular is an AspNet Framework application that uses (see: open-telemetry/opentelemetry-dotnet#2781).
There are many other cases where there is not an appropriate way to set the service.name at a feasible default when it is not specified or specified ONLY by an Environment variable.

What did you expect to see?
service.name should be set as Recommended instead of Required. This will allow SDK libraries to set defaults when the user hasn't specified them, or they are unable to specify them in certain cases.

Additional context.
Other tickets that have problems when service.name should not be required
1
2
3
4

See an appropriate default set here by the splunk library.

[Kronos11]

After reviewing previous issues I see why this decision was made. I do wonder if it could instead be up to the auto instrumentor to decide if they want to provide a better default value for the user in case it's needed as in my case.

The other option I suppose would be for the user to decide if they really do want a fallback or default as part of configuration.
What do you think?

[pellared]

I agree with issue and I do not think that it is only applicable for ASP.NET. It is not rare the instrumented application works on top some "hosting process" such us dotnet, java, python3, w3wp.

However, some ecosystems could bring some useful defaults. This would be extremely useful especially for auto-instrumentations.

If the value was not specified, SDKs MUST fallback to unknown_service: concatenated with process.executable.name, e.g. unknown_service:bash

Option 1 (resource detectors)

I think that the spec allows using additional "resource detectors". I guess we can create/use more detectors that would set the service.name.

Am I correct? If not then GOTO: option 2

Option 2 (allow other names)

Alternatively , we can change in the specification to allow different values than process.executable.name such as "name of the main program entry" (which following for .NET it can be the name of the executing assembly, for Python it could be the name of the main module, for Java - the main package name).

E.g.

If the value was not specified, SDKs MUST fallback to a name that could represent the service, e.g. for .NET the name of the executing assembly, or unknown_service: concatenated with process.executable.name, e.g. unknown_service:bash .

Would such change in the specification be seen as backwards compatible? The unknown_service:[process.executable.name] would still be allowed. But we would also allow "discovering" the service names automatically with better approximation than the process name.

[tsloughter]

Big +1 to this because I already thought this was the spec and not that it was simply "user defined or unknown".

If the value was not specified, SDKs MUST fallback to unknown_service

In Erlang we use the OTP Release name and version for the service name because this is basically always what is wanted and the user can override with configuration or the environment variable.

So I wouldn't want it to be "recommended", it should still be "required", but allow for well defined name and versions to be used from a particular language or framework.

[arminru]

From the spec triage meeting - @carlosalberto will follow up

[Aneurysm9]

I think that the spec allows using additional "resource detectors". I guess we can create/use more detectors that would set the service.name.

Am I correct?

This is how I view it. I don't think that any change is required unless we want to clarify that users can use resource detectors to detect any resource attribute. The requirement that the SDK provide an ultimate fallback is only there because the service.name resource attribute is mandatory and something needs to ensure that it exists. In the Go SDK we do this with a resource detector.

[pellared]

From 07-2023-03-07 OTel Spec SIG meeting

It is acceptable to use resource detectors which is already done e.g. by Java . The SDKs should apply the the resource detectors before falling to the unknown_service service name.

There was no consensus if it needs to be explicitly defined in the specification.

[pellared]

@open-telemetry/specs-approvers I think this issue can be closed.