Should service.name resource attribute be a required field?

[owais]

service.name resource attribute is a 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 env var. For example. OTEL_RESOURCE_ATTRIBUTES=service.name=svc-payments. This can be confusing for new users and adds unnecessary friction. One could argue this is the most important piece of configuration any instrumented service should have. We should make it easier to specify the service name and make it very obvious when the user forgets to specify it or misconfigure it. We can make implement either the option 1. or both the options:

1. Add a dedicated config option for service name with env var SPLUNK_SERVICE_NAME.
2. When SPLUNK_SERVICE_NAME is not set, complain very loudly by logging an error.. Alternatively, make this a required option and throw an exception to fail fast if a value is not provided.

---

• 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.

[mateuszrzeszutek]

We can do point 2. right now by checking that resource's service.name != default.

If we were to add a separate property for service name, how would it work with the otel resource? What if you used both of them? What if you used the resource configuration and not our property?

[owais]

how would it work with the otel resource? What if you used both of them?

SPLUNK_SERVICE_NAME value would always be injected into resource attributes overwriting any existing value.

What if you used the resource configuration and not our property?

If we don't make it a required field and this was allowed, it'd work as expected in APM. Libraries may still log warning to keep validation logic simple.

[owais]

@mateuszrzeszutek updated the original post. For 2., I meant to log errors when SPLUNK_SERVICE_NAME is not set, not look into resource attributes. May be the 3rd option can be to not introduce a dedicated config value but add warnings when resource attributes don't have service.name set.

[ghost]

It's tempting to go for point 1. as I agree with all points made by @owais
With regards to pain points mentioned by @mateuszrzeszutek the easiest way forward to to prioritise Splunk config in case of conflict.
However adding our own config property means that we will need to:

• support it till the end of time ;) (which adds friction on our side)
• document it separately (this may increase customer's confusion if not done really good)

Taking above into consideration I'd go with 2. (complaining loudly in logs) and document that it SHOULD be done by each customer (meaning - put in on the first page of the doc, capitalized ;) ).

[iNikem]

Also take a look at open-telemetry/opentelemetry-specification#709. We may want to put more pressure on that proposal. Especially if other vendors already demonstrate the need for that separate variable. @owais can you add links to vendor specific service name configuration to my linked issue?

[owais]

open-telemetry/opentelemetry-specification#709 (comment)

[flands]

So we can continue to push spec, but cannot wait so will stick to current approach. Given OTel has a fall-back option, how about we go with option 2 and log loudly for now.

[jkwatson]

Should we also fill in a splunk-specific default service name for them, or is the otel default good enough?

[iNikem]

@flands do you mean that we still should introduce SPLUNK_SERVICE_NAME? And then add support for OTEL_SERVICE_NAME as well? As we currently have kinda working solution with OTEL_RESOURCE_ATTRIBUTES I think we can wait for Otel spec update. I can file a corresponding PR.

[MrAlias]

Talking with @owais IRL, the plan is to add a warning when this is detected to be unset and wait to see what for the OTel community to support this (or re-evaluate adding Splunk specific support if they do not plan to move forward with this in the 1.1 release).