Opentelemetry-java: Automation-friendly SpanExporter factory framework needed

[prydin]

Motivation

I've been working on the java auto agent to build a framework for plugging in arbitrary exporters (such as vendor-provided ones). To make this work in a way that makes it easy for authors of exporters to make their exporters auto-instrumentation friendly, we need to add a small factory framework for creating SpanExporters

Current state

Currently, the preferred way of creating a SpanExporter is through a builder. This works very well for programmatically creating an exporter. However, it does not work when the exporter is loaded dynamically and configured from e.g. system properties and environment variables.

Proposed change

Implement simple factory framework consisting of two interfaces:

public interface SpanExporterFactory {
  SpanExporter fromConfig(ConfigProvider config);
}

The implementation of this interface is provided by the exporter. This is the interface used when the auto agent wants to create a SpanExporter. It would have obtained an implementation of this interface through a ServiceLoader. To create a SpanExporter, the agent needs to pass a configuration bundle as a ConfigProvider. This is an interface that looks as follows:

public interface ConfigProvider {
  String getString(String key, String defaultValue);

  int getInt(String key, int defaultValue);

  long getLong(String key, long defaultValue);

  boolean getBoolean(String key, boolean defaultValue);

  double getDouble(String key, double defaultValue);
}

The auto agent provides a implementation of this interface that pulls configurations from its internal config framework which, in turn, pulls configurations from system properties, environment variables and config files.

[jkwatson]

To support complex configuration, it might be good to also have ConfigProvider getSubConfig(String key, ConfigProvider default)

[jkwatson]

Also, I think I'd prefer calling it Config, rather than adding provider onto the end.

[prydin]

I agree with both comments.

[jkwatson]

@prydin Decision in the Java SIG today is to put this and any other interfaces needed for configuring the auto-instrumentation agent into a new contrib module for the sdk. I'll put in a PR to create the module, then we can add this Config interface in a 2nd PR and get things moving forward. Sound ok to you?

/cc @bogdandrutu

[bogdandrutu]

Decision to put it in a separate module for the moment is because we don't have full clarity on what exactly is needed, when this gets stable we can move it to the sdk package if needed.

[prydin]

@prydin Decision in the Java SIG today is to put this and any other interfaces needed for configuring the auto-instrumentation agent into a new contrib module for the sdk. I'll put in a PR to create the module, then we can add this Config interface in a 2nd PR and get things moving forward. Sound ok to you?

Sounds great. I'd be happy to do that.

[jkwatson]

@prydin the newly minted module is ready for you to add a Config class to it.

[prydin]

Great! I’m traveling today but will do it as soon as I get to peaceful enough place...

[jkwatson]

Closing this. I believe this is up and working well in the instrumentation project, via the extension module interfaces.