Configuring exporters after installation

[kenfinnigan]

With Quarkus and GraalVM it's possible to build native images from Java applications, which enables lots of things to happen during the build that normally happens at runtime.

From a look through the docs and code, it currently doesn't appear to be possible to have code adding a Jaeger exporter, for instance, to the SDK but the configuration of where that exporter sends the spans to be defined later. Or even the ability to disable an exporter with runtime configuration.

A "config comes later" type ability is probably needed for several areas, this was just the first one I encountered.

If there's interest in this, and it's not currently possible today, I can raise an issue. But I wanted to ask here first.

[Oberon00]

A "config comes later" type ability is probably needed for several areas

Why is it necessary to do some setup steps earlier?

[Oberon00]

That makes sense. However, I think adding that "late-configuration" approach would add lots of code complexity. In fact, the support for adding span processors after creation was removed just a few weeks ago to simplify the code. #2223 (review)
Is this request mostly because it would feel right / more perfect, or did you notice a particular overhead from the builder classes, etc.?

One thing you can do right now to get around this is to implement your own LateBoundExporter or similar, configure that at startup, and later do something like myLateBoundExporter.setRealExporter(configureMyJaegerExporter()).

[kenfinnigan]

It's more to do with there being lots of builder classes, as opposed to any particular overhead related to them, which don't need to exist after the instance is created. In the native executable case, it would be preferable for them to not be present at all.

I can certainly try a custom delayed exporter. Is that something the project would be interested in to support native executable usage or no?

[jkwatson]

This definitely seems like a good thing to put into the tracing-incubator module, for sure.

[anuraaga]

@kenfinnigan Yeah and we may move it to a -nativeexe, -graal, -substrate type of extension artifact if the SDK proper doesn't seem to make sense, depending on what things look like. I wonder how many things will want to be delayed, e.g., do you think we would preinitialize the gRPC channel too, just change its endpoint on native-image startup? If so, sounds like an intense task :-)

[kenfinnigan]

@anuraaga in theory, any piece of configuration that could be different between testing and production would need such a feature.

Some of the ones I can think of are:

• Exporter location
• Enable/disable exporters
• Sampling strategy

Possibly other things as I come across them