add span stacktrace config option

[SylvainJuge]

Description:

Span stacktrace module can't use autoconfiguration for now as it relies on a strict ordering of the span processors. The addition of OnEnding callback would unblock this but it's not available yet (open-telemetry/opentelemetry-java#6367).

While autoconfiguration is still not supported, this PR adds a way to provide a ConfigProperties for configuration, which allows to

• define configuration option and default value
• implement configuration in a consistent way across usages

Configuration option name otel.java.experimental.span-stacktrace.min.duration
Default value: 5ms

[SylvainJuge]

As discussed yesterday SIG we can't mark the feature as stable in part because it relies on an unstable semconv attribute code.stacktrace.

While we work on making this code.stacktrace a stable semconv attribute, we should still be able to merge this PR with an experimental configuration option otel.java.experimental.span-stacktrace.min.duration, so at least add support for some configuration.

So here I think this PR is ready for review and we should be able to merge it as-is until we manage to make progress on making the feature stable.

@trask @jack-berg does it sounds like a good next step for this ?

[jack-berg]

The delimiter situation is always a bit hard.. Thoughts:

• The autoconfigure module automatically turns any - into ., so there doesn't seem to be any point in introducing other delimeters.
• I could see this evolving to have a log record processor one day, in which case nesting the properties under otel.java.experimental.stacktrace.* (or otel.java.experimental.stacktraceprocessor.*) would allow for a more uniform property schema. But on the other hand, the component is currently named *-span-stacktrace - maybe the component name is worth revisiting?

Suggested change

	The `otel.java.experimental.span-stacktrace.min.duration` configuration option (defaults to 5ms) allows configuring
	The `otel.java.experimental.stacktrace.span.min.duration` configuration option (defaults to 5ms) allows configuring

[SylvainJuge]

I'm fine to remove - and replace it with ., for now we just need to have one configuration option to start, we will of course need to revise this later when making this feature stable.

I think the suggestion to use - in the feature name came from what we currently have for otel.java.experimental.span-attributes.copy-from-baggage.include in the baggage-processor, which by the way isn't really consistent as we have otel.java.experimental.span-attributes as prefix for a module named baggage-processor.

As long as things are not marked as stable, I think those minor inconsistencies are fine and acceptable, especially in the contrib repo where things are mostly alpha.

---

However we probably need to have some proper definition somewhere about those configuration options, for example to at least define what are the main namespaces like otel.java.*, otel.javaagent.* or otel.java.experimental.* or even define a global registry with all the possible options to ensure there isn't any conflict between all the repositories. Also, this might be something also happening in other platforms & otel components SIGs.

However that's definitely something that will take a while and should be covered separately, and I know that it sounds like "let's start another SIG about configuration options" 😄 .

[jack-berg]

Ha - well unfortunately I doubt we'll get any additional clarity around property naming anytime soon. There's already a dedicated config sig (which I lead), focussing on building out declarative configuration which aims to replace the system property / env var config scheme as the dominant mechanism for configuration. That's where all the configuration effort is being spent these days.

I think you're right to stick with precedents that already exist in this repo - I wasn't aware of those.

[SylvainJuge]

Ok, then let's stick to otel.java.experimental.span-stacktrace.min.duration for now if you agree and we can always change it later as it's experimental, we can even still support the current experimental config for as long as we'd like.

[SylvainJuge]

Woops, I deleted the branch by accident, thus just re-opening it with this comment.