Docs

Docs

Observability Kit Integrations

Observability Kit records into a Micrometer registry, so it exports to any backend Micrometer and Spring Boot Actuator support.

Observability Kit doesn’t export anything itself. It records metrics into your application’s Micrometer MeterRegistry and emits tracing spans through the Micrometer Observation API. Getting that data into a backend is standard Micrometer and Spring Boot Actuator work — the same as for any Micrometer-instrumented application — so the kit reaches every backend those support.

This means there are two independent pipelines to wire up:

Metrics

Add a micrometer-registry-* dependency for your backend and expose it through Spring Boot Actuator. Some backends are scraped (Prometheus); others are pushed to (OTLP, Datadog, New Relic).

Traces

Add a Micrometer tracing bridge — for example OpenTelemetry (micrometer-tracing-bridge-otel) or Zipkin (micrometer-tracing-bridge-brave) — plus the matching exporter.

Because both pipelines are backend-agnostic, a vendor that speaks OpenTelemetry Protocol (OTLP) can receive both metrics and traces through a single OTLP endpoint, either natively or through an OpenTelemetry collector.

The following pages show vendor-specific setup:

Prometheus
Learn how to export Observability Kit metrics to Prometheus from a Vaadin application.
Grafana
Learn how to export Observability Kit metrics, traces, and logs to a Grafana stack.
Jaeger & Prometheus
Set up a local Jaeger and Prometheus stack to collect traces and metrics from Observability Kit.
Datadog
Learn how to export Observability Kit metrics and traces to Datadog.
New Relic
Learn how to export Observability Kit metrics and traces to New Relic over OTLP.

How Export Works

The kit is active as soon as it’s on the classpath; it starts recording into whatever MeterRegistry your application provides. Nothing is exported until you add and configure a registry backend.

For a Spring Boot application, the minimum for metrics is Actuator plus one registry:

Source code
pom.xml
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

For traces, add the OpenTelemetry starter, which bundles the tracing bridge and the OTLP exporter:

Source code
pom.xml
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-opentelemetry</artifactId>
</dependency>

The starter also brings in the OTLP metrics registry (micrometer-registry-otlp). If you export metrics through a different registry — such as Prometheus, above — disable the OTLP one so it doesn’t also try to push metrics: set management.otlp.metrics.export.enabled=false.

Note
Service Identity
Set spring.application.name so every meter and span is tagged with a consistent service name. For OTLP backends, additional resource attributes can be set through management.opentelemetry.resource-attributes.*. This replaces the version 4 otel.service.name and otel.resource.attributes settings, which lived in the agent.
Note
Trace Sampling
Spring Boot samples only a fraction of traces by default (management.tracing.sampling.probability, 0.1). While testing an integration, set it to 1.0 so every request produces a span. Lower it again for production.

Percentiles and Histogram Buckets

The kit’s timers export their count, sum, and max only by default. That’s enough for rates and averages, but a percentile query — a histogram_quantile() expression, a Grafana p95 panel, a latency alert — needs histogram buckets, and Micrometer publishes those only when asked. A percentile query over a bucket-less timer doesn’t fail; it silently returns no data.

Enable buckets for the timers you build percentiles on:

Source code
application.properties
management.metrics.distribution.percentiles-histogram.vaadin.request.duration=true
management.metrics.distribution.percentiles-histogram.vaadin.rpc.duration=true
management.metrics.distribution.slo.vaadin.request.duration=25ms,50ms,100ms,250ms,500ms,1s,2s
management.metrics.distribution.slo.vaadin.rpc.duration=25ms,50ms,100ms,250ms,500ms,1s,2s

The slo lines are optional: they add explicit bucket boundaries at your service-level objectives, the durations you alert on. The 1s boundary matches the UX budget that interaction insights use, so dashboard percentiles and insights draw their line at the same place.

The property keys match meters by dotted prefix, so management.metrics.distribution.percentiles-histogram.vaadin=true covers every vaadin.* timer at once. Prefer enabling buckets per meter, though: each bucketed timer publishes tens of additional series per tag combination, so a blanket switch multiplies the metric volume for timers you never query by percentile.

One meter is an exception: vaadin.db.fetch.rows publishes pre-computed p95 and p99 percentiles out of the box — in Prometheus, as quantile series — so you can alert on runaway result sets without any bucket configuration. Pre-computed percentiles are calculated per instance and per tag value; they can be read directly but not re-aggregated across instances the way histogram buckets can.

Local Development & Testing

For development-time testing on your own machine, use one of these setups:

  • Jaeger & Prometheus — Jaeger for traces and Prometheus for metrics. Both run stand-alone with no further dependencies. The downside is that logs aren’t included and data is viewed from two separate tools.

  • Grafana — a single tool for metrics, traces, and logs, backed by Prometheus, Tempo, and Loki.

Both are also production observability stacks; the pages describe the app-side configuration, which is the same in development and production.

JVM, Infrastructure, and Library Metrics

In version 4, the OpenTelemetry Java agent bundled instrumentation for JVM internals, connection pools, HTTP clients, and other libraries. Version 5 doesn’t — and doesn’t need to. Spring Boot Actuator and Micrometer’s standard binders already instrument the JVM, process, HTTP clients, data sources, and connection pools, and they export through the very same registry you configure here.

So a single registry backend receives the kit’s Vaadin meters, Micrometer’s infrastructure meters, and any custom meters you add, all together. See the Micrometer documentation for the available binders.

Updated –