Ability to easily modify the service names

[poulsbopete]

Feature Request

With the OpenTelemetry Demo, I would like to be able to modify the service names to demonstrate additional industry vertical stacks aside from Retail. Some example industries that are looking into OpenTelemetry to meet their needs include: telecom, financial, computer software, etc.

Is your feature request related to a problem?

No, this is not related to a problem with the OpenTelemetry Demo.

Describe the solution you'd like:

I would like to see a helm variable mapping to "alias" the service name, all of the underlying technology should not need to be changed. In all vendor tracing tools, the maps and trace waterfalls will display the new service name as well as the logs.

Describe alternatives you've considered.

There are screen manipulation solutions, but if the level of effort is low to modify the service name, it will allow OpenTelemetry to apply to several different industry segments.

Additional Context

Full disclosure: I work at Splunk and proudly demo the OpenTelemetry Demo, getting everyone I can talk to excited about OpenTelemetry. This feature request will allow all the vendors to tailor the OpenTelemetry Demo to meet their needs when talking to different industries.

[puckpuck]

I see 2 different ways to accomplish this today.

1. Use a transform or resourceattribute processor configured with the deployed Collector
2. As part of the values passed into the Helm chart, re-specify the default.env list without the OTEL_SERVICE_NAME variable, and re-add that variable as part of envOverrides for each component.

[puckpuck]

@poulsbopete are you able to use the techniques I described in the previous comment to achieve what you need?

[poulsbopete]

Yes, @puckpuck, I am working on your option number 2, "re-specify the default.env list without the OTEL_SERVICE_NAME variable, and re-add that variable as part of envOverrides for each component." Many thanks for the rapid turnaround time. I will post some examples, perhaps we can add to the documentation in the future. Thanks again.