Opentelemetry on tsvinc

Measuring OpenTelemetry Overhead Without Fooling Yourself

Mon, 26 Oct 2026 00:00:00 +0000

Saturday 24 October, 17:05 UTC: the first cell of my telemetry overhead matrix starts. At 18:55 UTC (21:55 on the local clock that driver.log keeps) I stopped it, seven cells into thirty. Five of the seven had passed the gate, and two of those five had been OOM-killed 39 and 48 times.

The question was one number per setup: what OpenTelemetry costs a Spring Boot 4.1.2 service in memory and in CPU per order. The service is the order pipeline from part 1, in two flavours: plain uses the bare RabbitMQ, Mongo and JDBC clients, spring uses Spring Data and Spring AMQP. The setups are none, a Prometheus reference, Boot's own OpenTelemetry starter (mo-*), the OpenTelemetry project's starter (on-*) and the JVM-only OTel Java agent; -m is metrics only, -mt metrics and traces. The second attempt finished all 60 cells. Most of this post is what had to be true of a cell before its number counted.

Counts Match, Dashboards Don't: OTel Agent vs Starter

Sun, 25 Oct 2026 00:00:00 +0000

Twenty-four test cells, 284 row checks, 24 cross-checks, zero failures. I ran one Spring Boot order pipeline under the OpenTelemetry Java agent, OpenTelemetry's Spring Boot starter and Boot's own OpenTelemetry starter, on the JVM and, for the two starters, as a GraalVM native image. Every count with an exact expectation, 284 rows of them, equalled what the load generator had sent.

The question I'd been asked was whether a service on the agent today can go native and keep its Grafana dashboards and alerts. The agent doesn't run in a native image, so native means a starter, and a parity report that green reads like permission to swap. A panel reads something else: a metric name, a unit, label keys, label values and histogram buckets. Scored on those, OpenTelemetry's starter in native keeps 4 of the 26 things a panel in my two test apps can read, and all four are the job and instance labels. Boot's starter in native keeps 2, both of them job. A perfect score on the wrong exam.

Java 25 Changes Your Telemetry in Strings, Not Code

Sun, 25 Oct 2026 00:00:00 +0000

A JDK upgrade gets tested like a runtime change. Does it compile, does it start, did the GC pauses get worse. Telemetry rides along as if it were part of the runtime. In practice it's a contract written in strings, like jvm.gc.name="ZGC Pauses" and jvm.memory.pool.name="ZHeap", and no test suite asserts on a name the JVM makes up at start-up. When those strings change, nothing errors. A panel goes flat, an alert stops firing, and both look exactly like a healthy service.

Spring Boot 4 Keeps a Tracer With Tracing Off

Sun, 25 Oct 2026 00:00:00 +0000

Spring Boot 4.0's release notes cover it in one bullet, under Miscellaneous: "The property management.tracing.enabled has been renamed to management.tracing.export.enabled." The old key doesn't forward to the new one. It doesn't fail startup, and in the run I have it doesn't log a word. Set it to false and it binds to nothing.

I found it while chasing a red test on Boot 4.1.2, and the dead key wasn't what turned the test red. The test was wrong: with the new key, the Tracer bean stays too.

The Config I Measured Was Not the Config That Ran

Sun, 25 Oct 2026 00:00:00 +0000

optional: is the most forgiving word in a Spring Boot config file. Put it in front of an import and Boot loads the file if it's there and carries on if it isn't. A missing file can never keep the app from starting. My benchmark app imported its telemetry settings that way. In the native image the import kept that promise to the letter. The file wasn't there, Boot carried on without it, and not one byte of telemetry reached the collector.