missing resource providers for declarative config

[zeitlinger]

Is your feature request related to a problem? Please describe.

All resource providers in all repos - old vs. new

Describe the solution you'd like

• Missing resource component providers
  • Service instance ID
  • Distro
  • OS - is part of host
  • Spring Boot
  • Jar service name
  • manifest
  • Contrib
    • Cloud providers: Declarative config: Cloud component providers opentelemetry-java-contrib#2014

The rest is implemented in #14222

[zeitlinger]

@jack-berg can you explain where the missing resource providers should be added?

[jack-berg]

@jack-berg can you explain where the missing resource providers should be added?

In declarative config, resource providers are registered as instances of ComponentProvider with getType() returning Resource.class, and getName() returning a name to reference in the YAML config.

For example, a "foo" resource provider might define a ComponentProvider like:

public class FooComponentProvider implements ComponentProvider<Resource> {
  @Override
  public Class<Resource> getType() {
    return Resource.class;
  }
  @Override
  public String getName() {
    return "foo";
  }
  @Override
  public Resource create(DeclarativeConfigProperties config) {
    return Resource.builder().put("foo", "bar").build();
  }
}

And referenced in YAML like:

resource:
  attributes:
    - name: service.name
      value: my-service
  detection/development:
    detectors:
      - foo:

(A typical YAML file would reference other detectors as well.)

Does this answer the question?

[jack-berg]

Note that the EnvironmentResourceProvider is a special case which has no equivalent in the declarative config space.

Also, ServiceInstanceIdResourceProvider is already handled by the service detector as defined in open-telemetry/opentelemetry-java#7436

DistroVersionResourceProvider - this is sort of like Resource.getDefault() from opentelemetry-java in that it provides meta data attributes which are pretty fundamental and that the user shouldn't need to opt in to. One option for implementing this in declarative config would be for the agent to implement the declarative configuration customizer SPI, and customize the OpenTelemetryConfiguration model by enriching its resource with these static distro resource attributes.

NOTE: the service detector is responsible for providing service.instance.id, but the user has to opt into this by listing service in the list of named detectors in their config file. It may be more appropriate for service.instance.id to be more fundamental, and not something the user needs to opt into. Alternatively, the java agent could implement a declarative configuration customizer to provide service.instance.id automatically if it is not set by user and if the service has not been included by the user. This would make it equivalent to the agent's current behavior, which includes service.instance.id by default.