opentelemetry-dotnet
opentelemetry-dotnet copied to clipboard
open-telemetry
Refine the default resource service.name
Ideally, the SDK should try the name of the entry assembly first and only if that fails fallback to the process name. This way it gets better default names for applications started via dotnet MySvc.dll which is currently resolves dotnet as the process name.
Do you see any problem with such a change?
Originally posted by @pjanotti in https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/pull/312#discussion_r782478960
This sounds reasonable change.
https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/semantic_conventions/README.md#service
If the value was not specified, SDKs MUST fallback to
unknown_service:concatenated withprocess.executable.name, e.g.unknown_service:bash
As far as I understand we would first need to propose a change in the specification to allow different values than process.executable.name such as "name of the main program entry" (for .NET it can be the executing assembly, for Python probably the name of the main module). Can you confirm, please?
mm. Yes it feels some change to spec would be needed, given its a "MUST" in the spec.
Was there any further discussions on this since January? This default is so bad that it basically enforces every application to change it otherwise telemetry info becomes nearly impossible to follow.
Seeing stuff like unknown_service_w3wp or unknown_service_dotnet is completely useless as it basically conflates every single application if they do not set a value manually.
@julealgon None that I am aware of. Feel free to create a PR/issue in OTel specification or join their SIG meeting (more info here).
This would be a really great change in my mind as well. Having better defaults or a way to change this on a per application basis is going to be the only viable solution here.
For IIS this needs to be something related to the VDIR name similar to what DataDog does.
@cijothomas what we talked about last night in the SIG, maybe I didn't do the request justice.
Per https://github.com/open-telemetry/opentelemetry-specification/issues/3210 we could simply create a new resource detector that sets the service.name resource based on the name of the entry assembly.
Per open-telemetry/opentelemetry-specification#3210 we could simply create a new resource detector that sets the service.name resource based on the name of the entry assembly.
@pellared what about a resource detector implementation that relies on this?
- https://github.com/dotnet/extensions/tree/main/src/Libraries/Microsoft.Extensions.AmbientMetadata.Application
It could then cover both the service.name and service.version attributes, and potentially also the deployment.environment one.
Another alternative option: one could also overload the AddService extension method on the resource builder, similar as it's done for the service instance id (autoGenerateServiceInstanceId). So you could call
resourceBuilder.AddService(autoGenerateServiceName: true);
I wouldn't see this as a violation of the specification, as the user has to explicitly request the auto-generation of a service name.
Having a resource detector for this is viable too, however, then this makes it 4 ways users have to specify a service name, which seems quite a lot (via AddService, via the resource detector, via OTEL_SERVICE_NAME, and via OTEL_RESOURCE_ATTRIBUTES).
FYI here is a code that we have in .NET Automatic Instrumentation: https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/blob/42c51e6273df04cfe54e08ae073939cf515c2e93/src/OpenTelemetry.AutoInstrumentation/Configurations/ResourceConfigurator.cs#L51