Expand the scope of the built-in service resource detector
Currently, the built-in service resource detector is specified as:
service: Populates service.name based on OTEL_SERVICE_NAME environment variable; populates service.instance.id […]
In practice, several SDKs and automatic instrumentations already discover a service.name from language- and framework-specific signals when the user has not set one (see reference table). The spec neither sanctions nor describes this.
Proposal
Expand the accepted scope of the built-in service resource detector to permit language- and framework-specific discovery of service.name.
service: Populates service.name from the OTEL_SERVICE_NAME environment variable, falling back to language- or platform-specific sources (for example spring.application.name, a JAR manifest, or a Composer/package manifest) when it is not set; populates service.instance.id […]
(For the record: I would even go with SHOULD, in the name of better defaults!)
Expanding the scope of the service detector (rather than defining a new one) seems better for two reasons:
- Principle of least surprise: the
service detector discovers service.*.
- Declarative configuration works out of the box: the schema already treats
service as a built-in detector, so no schema change is required.
Note: many of the implementations below are instrumentation-level ResourceProviders rather than the literal built-in service detector; this proposal brings that existing behavior under the service detector's scope.
Related work in semantic conventions
If this proposal is accepted, we also should update the definition of service.name in the semantic conventions to allow for the new language-specific behaviors.
Reference: service discovery in languages
| Ecosystem |
Detector |
Signal (beyond the two env vars) |
Status |
Source |
| Java |
SpringBootServiceNameDetector |
spring.application.name (Spring's own precedence: CLI args → sysprop → SPRING_APPLICATION_NAME → application.{properties,yml,yaml} → classpath bootstrap.*) |
shipped in agent; lib -alpha |
opentelemetry-java-instrumentation |
| Java |
ManifestResourceProvider |
main JAR META-INF/MANIFEST.MF Implementation-Title |
-alpha |
opentelemetry-java-instrumentation |
| Java |
JarServiceNameDetector |
main JAR filename (myapp.jar → myapp) |
-alpha |
opentelemetry-java-instrumentation |
| Java (contrib) |
AppServerServiceNameProvider |
WAR/EAR deployment name on Tomcat, Jetty, Wildfly, Glassfish, TomEE, WebSphere (traditional + Liberty) |
contrib, non-GA |
opentelemetry-java-contrib |
| .NET |
ServiceNameConfigurator |
IIS SiteName + ApplicationVirtualPath (ASP.NET), else entry assembly name, else process name |
GA (auto-instr distro) |
opentelemetry-dotnet-instrumentation |
| PHP |
Composer detector |
composer.json root package name |
stable SDK, opt-in via OTEL_PHP_DETECTORS |
opentelemetry-php |
Expand the scope of the built-in
serviceresource detectorCurrently, the built-in
serviceresource detector is specified as:In practice, several SDKs and automatic instrumentations already discover a
service.namefrom language- and framework-specific signals when the user has not set one (see reference table). The spec neither sanctions nor describes this.Proposal
Expand the accepted scope of the built-in
serviceresource detector to permit language- and framework-specific discovery ofservice.name.(For the record: I would even go with
SHOULD, in the name of better defaults!)Expanding the scope of the
servicedetector (rather than defining a new one) seems better for two reasons:servicedetector discoversservice.*.serviceas a built-in detector, so no schema change is required.Note: many of the implementations below are instrumentation-level
ResourceProviders rather than the literal built-inservicedetector; this proposal brings that existing behavior under theservicedetector's scope.Related work in semantic conventions
If this proposal is accepted, we also should update the definition of
service.namein the semantic conventions to allow for the new language-specific behaviors.Reference: service discovery in languages
SpringBootServiceNameDetectorspring.application.name(Spring's own precedence: CLI args → sysprop →SPRING_APPLICATION_NAME→application.{properties,yml,yaml}→ classpathbootstrap.*)-alphaManifestResourceProviderMETA-INF/MANIFEST.MFImplementation-Title-alphaJarServiceNameDetectormyapp.jar→myapp)-alphaAppServerServiceNameProviderServiceNameConfiguratorSiteName + ApplicationVirtualPath(ASP.NET), else entry assembly name, else process nameComposerdetectorcomposer.jsonroot packagenameOTEL_PHP_DETECTORS