Decide if service.name should be required

[codeboten]

It isn't required to set OTEL_SERVICE_NAME, however the SDKs will set service.name to unknown_service when it isn't configured. Making it required allows users to correctly set it upfront, rather than finding out later that the service name isn't set.

That being said, there are a few different mechanisms out there that set the service name automatically (i.e. resource detectors)

Originally posted by @tsloughter in #6 (comment)

[codeboten]

@tsloughter is erlang setting it via a resource detector or is the SDK detecting the service name?

[MikeGoldsmith]

Initially I was in favour of making it required because the config file is expected to wholly be used by itself and not be layered with other configuration sources (eg env vars or SDK options). Making service.name required would help prevent the cycle of users not naming their services, seeing unknown_service and then going back to name their services.

However, setting service.name in the config file means a single config file cannot be used by multiple similar services without edits. I think this is a very valuable feature and will increase adoption of the config file.

[jack-berg]

However, I setting service.name in the config file means a single config file cannot be used by multiple similar services without edits. I think this is a very valuable feature and will increase adoption of the config file.

Can still achieve this by doing something like:

resource:
  attributes:
    service.name: ${env:OTEL_SERVICE_NAME}

[codeboten]

@MikeGoldsmith right, re-using this config would require service.name to be set via an environment variable:

resource:
  attributes:
    service.name: ${env:OTEL_SERVICE_NAME}

[codeboten]

... what @jack-berg said 😄

[tsloughter]

@codeboten the SDK's resource detector runner does it after running all detectors.

[MikeGoldsmith]

However, I setting service.name in the config file means a single config file cannot be used by multiple similar services without edits. I think this is a very valuable feature and will increase adoption of the config file.

Can still achieve this by doing something like:

resource:
  attributes:
    service.name: ${env:OTEL_SERVICE_NAME}

Ah, that is nice. Thanks for pointing out how to evaluate env vars 👍🏻

[tsloughter]

I'll have to check if any others do similar to Erlang. I can't imagine we are the only ones who are able to get the service name without the user essentially setting it twice.

[tsloughter]

I asked around and one other is .net which also has the ability to discover the service name https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/blob/6f4e6a67994d8b042f74351c828b4e2b115079c7/src/OpenTelemetry.AutoInstrumentation/Configurations/ServiceNameConfigurator.cs#L24

[marcalff]

Resolved by #68

Please close.