While we make it easy for users to contribute a SdkMeterProvider (see #36545), we don't have full-fledged auto-configuration for OpenTelemetry metrics. In this issue, should add auto-configuration for SdkMeterProvider.
Comment From: ThomasVitale
@mhalbritter if this is open to external contributors, I'd be available to submit a PR. I have already implemented something similar in my Arconia OpenTelemetry library and I'd be happy to adapt and contribute upstream the OpenTelemetryMetricsAutoConfiguration and related exporters.
Comment From: mhalbritter
Hello @ThomasVitale, please go ahead and create a PR. Thanks!
Comment From: ThomasVitale
Great, thanks. I'll start working on a PR!
Comment From: ThomasVitale
@mhalbritter I split the work in two steps:
- auto-configuration for OpenTelemetry Metrics APIs
- auto-configuration for OpenTelemetry Metrics Exporters APIs.
Step 1 is covered in this PR: https://github.com/spring-projects/spring-boot/pull/46640 and is ready for review.
Step 2 is covered in this PR: https://github.com/ThomasVitale/spring-boot/pull/1, but it's not ready for review. I think there are a few things to discuss first, but I wanted to show a code example of how things would look like (also, after deciding on a direction, the PR would benefit from being split up in smaller PRs).
There's a general problem, currently, about mixing up OpenTelemetry and OTLP, and some confusion about the entry point for configuration (OpenTelemetry vs. Actuator vs. Micrometer). Some related issues:
- https://github.com/spring-projects/spring-boot/issues/46303
- https://github.com/spring-projects/spring-boot/issues/46229
- https://github.com/spring-projects/spring-boot/issues/46842
- https://github.com/spring-projects/spring-boot/issues/44647
My suggestion would be the following, which is also what I drafted in https://github.com/spring-projects/spring-boot/pull/46640 (just for OpenTelemetry Metrics, but the same approach could be extend to OpenTelemetry Logs, at least)
Configuration properties
Configuration properties for OpenTelemetry SDK and Exporters would be under the management.opentelemetry namespace. Each observability signal gets its own sub-namespace (logging, metrics, tracing + resource). Exporters configuration would be provided globally for all observability signals, with the possibility to customise it for each signal. A key part of OpenTelemetry is having a unified exporter configuration. I believe it's beneficial to provide such feature in Spring Boot so that you can configure things once instead of three times.
Currently, there's some kind of assumption that OpenTelemetry export means OTLP, but that's not necessarily the case. For example, I could use a "console exporter" to get all the produced telemetry logged, useful for development/testing. That's why I'm suggesting making it explicit that OTLP is one type of exporter (auto-configured in Spring Boot), but there could be other types.
- OpenTelemetry -> unified API for managing observability signals (definition, instrumentation, propagation...)
- OTLP -> protocol for exchanging observability signals
Example:
management:
opentelemetry:
export:
type: otlp
otlp:
endpoint: http://localhost:4318
connect-timeout: 10s
compression: gzip
metrics: true
timeout: 10s
transport: http
headers:
x-otel-tenant: default
metrics:
cardinality-limit: 500
exemplars:
enabled: true
filter: trace_based
export:
type: otlp
interval: 5s # this could be named "step" to be consistent with other providers in Spring Boot
aggregation-temporality: cumulative
histogram-aggregation: explicit_bucket_histogram
otlp:
endpoint: http://localhost:4317
connect-timeout: 10s
compression: gzip
metrics: true
timeout: 10s
transport: grpc
headers:
x-otel-tenant: metrics
Module Structure
Right now, the spring-boot-opentelemetry module contains only general SDK and Logging configuration. In my PRs, I have also added metrics. My suggestion for the module structure:
├── export (common OpenTelemetry exporters config)
│ └── otlp (common OpenTelemetry OTLP exporters config)
├── logging (OpenTelemetry Logs config)
│ ├── export (OpenTelemetry Logs exporter config)
│ │ ├── otlp (OpenTelemetry Logs OTLP exporter config)
├── metrics (OpenTelemetry Metrics config)
│ ├── export (OpenTelemetry Metrics exporter config)
│ │ ├── otlp (OpenTelemetry Metrics OTLP exporter config)
├── resource (OpenTelemetry Resource config)
├── (OpenTelemetry SDK core config)
OpenTelemetry Tracing
I'm still unsure about OpenTelemetry Tracing. I would expect its configuration to live in the spring-boot-opentelemetry module. Currently, the module doesn't depend on Micrometer. But maybe it'd make sense if it did. A project that adopts OpenTelemetry would typically include tracing. In the Spring Boot context, that would mean having a dependency on Micrometer since there's no plain support in Spring Boot for OpenTelemetry Tracing without Micrometer. At that point, if the project also wants logs and metrics with OpenTelemetry, the fact that spring-boot-opentelemetry has a dependency on Micrometer shouldn't be a big deal since it would already have it due to the Tracing support. What do you think?
Conclusion
There's a lot to unpack here, and I'm aware it's going a bit out of scope for this issue. But I wanted to start the conversation here before registering ad-hoc issues. Also, this might be the only chance of making such changes given the new major release of Spring Boot. Postponing this discussion might make it difficult to change things in a minor release.
I'm available to work on these tasks and also available to jump on a call and discuss them in more detail.
Thanks!
Comment From: mhalbritter
@ThomasVitale thanks for the PR, i'm going to take a look. I'm in the middle of something, so it might take a bit longer, but i plan to look at it this week.