Ease process for setting service.name

[MrAlias]

As pointed out in #25, the service.name resource attribute is very important for APM. This attribute is what lets APM identify individual services. Today this defaults to unnamed-<lang>-service for Splunk libraries. For example, if a user forgets to specify this attribute for a Node service, it'll show up as unnamed-node-service in APM. If a user forgets to specify it for multiple node service, then APM will likely treat all of those services as a single service.

Today the only way to specify a value for this attribute is to use the OTEL_RESOURCE_ATTRIBUTES environment varariable. For example. OTEL_RESOURCE_ATTRIBUTES=service.name=svc-payments. This can be confusing and not obvious for new users. This has been identified in the OTel community and there is an open issue looking to address this.

Ideally the OTel community provides a way to easily set the service name and handles any priority resolution with OTEL_RESOURCE_ATTRIBUTES if they add support for an additional environment variable. If this does not happen, and we discover this is a major pain point for customers, we need to add our own environment variable to support this.

Prior Art

• Old SignalFx libraries had a dedicated config var for service name.
• Lightstep's new Otel distros have dedicated config vars for service name.
• DataDog's new Otel libraries have a dedicated config var for service name.
• AWS distros don't do anything special and expect the user to configure the attribute via OTEL_RESOURCE_ATTRS.
• Honeycomb uses the SERVICE_NAME environment variable that they defined to set this.

[iNikem]

I am sure that the correct solution to this issue is to solve spec's issue :) Providing a new env variable should not be a hard change in the spec. I can try to submit a PR in about a week's time the latest. Unless somebody else wishes to do so.

[iNikem]

@MrAlias open-telemetry/opentelemetry-specification#1677

[iNikem]

Spec PR is merge open-telemetry/opentelemetry-specification#1677. We now have OTEL_SERVICE_NAME

[mateuszrzeszutek]

A bit Java-centric question: should we implement that right now in our javaagent? I suppose that otel SDK will add this in 1.3, but if we're expecting to release splunk-otel-java 1.0 this week it might be a good idea to do it right away in our repo.
CC @jkwatson @flands

[jkwatson]

A bit Java-centric question: should we implement that right now in our javaagent? I suppose that otel SDK will add this in 1.3, but if we're expecting to release splunk-otel-java 1.0 this week it might be a good idea to do it right away in our repo.
CC @jkwatson @flands

I think we should wait until the spec gets released to put this in. Otherwise, it could get reverted in the spec pre-release and we'd be stuck with having something custom.