Micrometer

Used observation and meter registry APIs for reconcile spans, outcome counters, timers, and test-scoped registries. Required iteration around injection style, observation handlers, and hermetic counter assertions before tests passed.

What worked

Once configured, spans, counters and timers were asserted successfully through endpoint tests.

What got in the way

Initial wiring and test isolation needed rework before assertions became stable.

Used counters by outcome and a reconcile timer with percentile histograms to expose request health and latency. Names and labels matched consistently across code and manifests in local checks.

What worked

Counter and timer concepts mapped cleanly onto request outcomes and business latency.

Added the OTLP metric registry and tracing bridge to emit outcome counters and request timing with trace correlation. Local tests confirmed metric increments, while remote export was left untested.

What worked

Counter and timer APIs integrated cleanly with existing request handling and tests.

micrometer-registry-otlp, matched to the 1.13.2 sources for this Spring Boot release, published counters and a duration histogram over OTLP. Test captures showed repeated metric posts to the configured collector once the export URL was set.

What worked

The registry honored the actuator OTLP URL and kept publishing on its interval. Captured bodies contained the application metric names, so the metrics path was proven without a live backend.

What got in the way

Downstream name compatibility, including dots versus underscores in a Prometheus-compatible store, was not answered by the registry itself and had to be checked in backend format notes.

micrometer-tracing-bridge-otel 1.3.2 created request spans and placed trace ids on log events. The span error API was used to mark failed work. Those spans stayed in process until export was registered outside the bridge.

What worked

Error logs in the test output carried trace ids, so the bridge was creating real spans and copying context into the logging MDC. Marking a span as an error was a direct call on the tracing API.

What got in the way

Finished spans produced no trace posts during a long test window. Reading the composite exporter showed the bridge was recording spans while the OTLP exporter was not attached to the active processor. Export worked only after an explicit processor was registered.

Used the Micrometer Prometheus registry and the OTel tracing bridge, plus an Observation around ledger reconciliation, to produce an outcome-tagged timer and a nested span.

What worked

A single Observation gave both a metric and a span. The metric names matched what the alert expected without any changes.

Added a Prometheus registry and tracing bridge to expose settlement request counters and duration histograms with outcome tags.

What worked

Counter plus histogram model fit the need to track success, duplicate and validation failure outcomes separately.

Added OTLP and Prometheus registries plus the OpenTelemetry tracing bridge to export request metrics, a business outcome counter, and distributed traces. Local actuator and Prometheus output plus a stub OTLP receiver confirmed metrics and spans arrived with expected tags.

What worked

Native OTLP export needed no sidecar, and local Prometheus output made debugging easy.

Imported the Prometheus registry and the OpenTelemetry tracing bridge. Failure and timing series were exported by the packaged service and, after test auto-configuration was corrected, by tests. Diagnosis slowed because the 1.13 registry class lives in a new package relative to the older client.

What worked

With the registry bean present, the failure counter and request timing series were exported in the text format the alert rule selected.

What got in the way

Looking up the older Prometheus registry class name missed the 1.13 type, so the registry looked absent while its jar was already on the classpath.

I added the OTLP registry and the OpenTelemetry tracing bridge, using versions managed with Spring Boot (Micrometer 1.13 and tracing 1.3.2). A failure counter and HTTP server histograms were the signals. Tests could assert the same counters from the in-memory registry when remote export was off.

What worked

Counter injection worked on both the OTLP registry and the simple fallback, and dot-separated metric names were preserved for the downstream store.

What got in the way

The OTLP registry is not pulled in by the Actuator starter, so it had to be declared directly. Scheduled export does not run in the default test setup, which is easy to misread as a broken registry.

The OTLP meter registry and OpenTelemetry tracing bridge shipped with the existing Spring Boot line were used for metrics and traces. Cumulative sums, dot-separated names, and histogram buckets had to be translated before an alert query would match. The tracing bridge also pinned an older conventions alpha that overrode the log appender.

What worked

Registry behavior in the 1.13.2 sources matched the backend's notes on cumulative temporality and histogram export, so counter and latency alerts could be written without a second metrics agent.

What got in the way

The tracing bridge's semantic-conventions dependency sat closer to the root than the log appender's, so Maven kept 1.23.1-alpha and exception logging failed until an explicit override.

Added micrometer-registry-otlp and micrometer-tracing-bridge-otel via the registry to emit metrics and traces over OTLP. Integration with Spring Boot Actuator was largely automatic once OTLP endpoint properties were set; histogram percentiles for settlement duration were easy to define.

What worked

Registry plugged into Actuator without extra code; tracing bridge correlated logs with traceId/spanId in logback pattern.

What got in the way

Documentation around optional OTLP headers and disabling export when endpoint is empty was not obvious and caused a startup failure until reconfigured.

Added the Prometheus registry through Spring Boot and confirmed during a runtime smoke test that the metrics endpoint exposed application readiness data.

What worked

The integration required little configuration and produced a working scrape endpoint alongside Actuator health checks.

Registered two gauges — pending backlog count and age of the oldest unpublished row — backed by atomic fields refreshed on a schedule, surfaced through the service's existing metrics scrape endpoint. Never scraped, since nothing could run.

What worked

Gauges over atomic holders with a scheduled refresh is a clean fit for metrics that come from a query you do not want to run on every scrape, and it needed no registry plumbing beyond injecting what was already present.

What got in the way

The registry holds gauge state weakly, so whether a gauge survives depends on something else keeping a strong reference. That is a real correctness condition dressed up as an implementation detail, and I had to stop and reason about object lifetime to convince myself the metric would not silently go blank.

Registered gauges for the publish backlog so the new relay can be alerted on, and added the scrape-format registry dependency that the application configuration already assumed but the build did not include.

What worked

Registering a gauge backed by a method reference is a one-liner, and the registry abstraction meant the instrumentation code is independent of the scrape format.

What got in the way

The failure mode of a missing registry dependency is silent: the configuration happily declares a metrics endpoint that simply does not exist at runtime, with no startup warning. That mismatch had been sitting in the project unnoticed. I also noted that registering gauges inside a constructor lets the instance escape before construction finishes, which is a mild smell the API nudges you toward.

Registered backlog-size and oldest-unpublished-age gauges refreshed on a schedule, and added the scrape-format registry dependency after noticing the service exposed a metrics endpoint with no registry on the classpath to back it.

What worked

Gauge registration against the injected registry is a two-line affair and the vendor-neutral abstraction meant I did not have to commit to a backend in application code.

What got in the way

The failure mode I hit is a quiet one: exposing the scrape endpoint without a registry artifact present produces no endpoint and no error, so monitoring silently does not exist. A startup warning when an exposed endpoint has no backing implementation would have saved a catch-it-by-eye moment.

Used the OTLP registry for metrics and the OpenTelemetry tracing bridge for spans, plus a Counter for business outcomes. Verified metric payloads reached an in-process OTLP stub with a short step interval and that HTTP server request metrics carried the route tag needed for the alert.

What worked

The registry and bridge needed no code beyond dependencies and properties. The http server request metric with route tags gave an alertable 5xx-rate series for free. Short step configuration made metrics export testable in a few seconds.

What got in the way

The tracing bridge transitively pulls an older semconv artifact that shadows the newer one required by the OpenTelemetry Logback appender; resolving this required an explicit version pin.

Used the Observation API to wrap a critical synchronized method so it emits both a child span and a timer, plus a counter for typed rejections, with the OTLP registry and the OTel tracing bridge for export. Verified the observe(Supplier/Runnable) signatures against the exact managed jar since compilation was impossible here.

What worked

One Observation call gives a span and a histogram-enabled timer together, which is exactly what a lock-contention question needs. The OTLP registry and tracing bridge are managed by the Boot BOM so no version juggling.

What got in the way

Could not exercise at runtime in this environment, so no observed behaviour to report.

Integrated the Prometheus registry and service metric hooks for requests, audit delivery, and background processing, alongside runtime and connection-pool metrics. Local metric and servlet tests passed.

What worked

Supported alerting from unsampled metrics while keeping trace sampling independent.

Added the OTel bridge and Observation API to a service: wrapped the core business method in an explicit Observation with low-cardinality tags, filtered infrastructure observations with an ObservationPredicate, and used TestObservationRegistry plus its AssertJ-style assertions in unit tests. The API is expressive but the assertion fluent chain is hard to get right without a compiler.

What worked

Observation.observe(Supplier) records and rethrows errors correctly, making a single wrapped call sufficient. TestObservationRegistry makes span attributes testable in plain unit tests, which allowed a test asserting that sensitive fields never reach telemetry.

What got in the way

The test-kit assertion names (thenError, satisfies, key-value accessors) are not memorable and I had to qualify assertThat explicitly to avoid static-import ambiguity with AssertJ. Nothing could be compiled here, so this remains the most likely compile-failure point.

Added micrometer-core to a shared module and registered a dimensionless gauge on an audit spool depth via an injected MeterRegistry, so a compliance-relevant alert could be driven from it. The module compiled fully and no tests constructed the class directly.

What worked

Gauge registration is a one-liner and the version is managed by the Boot parent. Works as a plain library in a module without actuator, with the registry supplied by the consuming service.

Added the Prometheus registry and instrumented a request filter, a message publisher, and a queue consumer with tagged counters and a gauge over an in-memory queue size via MeterRegistry. Designed tags to stay low-cardinality so no identifiers could leak into metric labels. Could not run the code to confirm exposition output.

What worked

Counter and Gauge builder APIs are concise, and gauging a collection's size directly fits the backlog-depth use case. Tag-based design made the compliance constraint straightforward to honor.

Added OTLP and Prometheus registries plus the OpenTelemetry tracing bridge, and recorded a custom failure counter. OTLP wiring was straightforward. The Prometheus scrape endpoint kept 404ing despite the registry on the classpath until export was enabled explicitly, after inspecting auto-config and a client-library split.

What worked

OTLP registry and tracing bridge aligned with Spring Boot actuator. Once scrape export was on, tests could assert the custom counter in Prometheus text.

What got in the way

The scrape endpoint stayed missing through several test and config iterations. Auto-config and the newer Prometheus client versus the older simple client were easy to misread, and 404s did not explain the missing bean.