@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: #46640 and is ready for review.

Step 2 is covered in this PR: ThomasVitale#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:

My suggestion would be the following, which is also what I drafted in #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!

Provide auto-configuration for OpenTelemetry metrics #36546

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions