robintra/perf-sentinel v0.25.1 on GitHub

What's new in v0.25.1

v0.25.1 is about a Java service that looked badly instrumented when it was not. Before lending an idle connection, a pool such as HikariCP checks it with Connection.isValid(), which the PostgreSQL driver answers by running an empty query, execute(""). The OpenTelemetry JDBC instrumentation traces that call like any other statement, with db.system set and db.statement="". perf-sentinel read a blank statement as a missing one, so every pool ping counted as a missing_db_statement instrumentation gap, and a service whose every query carried its text reported a steady stream of spans that did not.

An empty query is not a missing one

A span is now read as a driver ping when its statement key is present and exactly empty, neither db.statement nor db.query.text carries text, and it names no operation in db.operation or db.operation.name. Such a span is filtered as not_io, the reason kept for spans that describe no I/O, instead of missing_db_statement.

The test is narrow on purpose, so that the gap it used to overstate stays visible where it is real. A redacting layer that strips the query text keeps the operation it stripped it from, and a statement made of whitespace is no empty query, so both still count as missing_db_statement. That is the gap the counter and the usable span ratio exist to show.

A ping no longer borrows a statement

A statement-less span named like a query execution can take the statement of a related span in the same trace: that split-span stitch rebuilds the instrumentations that put the query text on one span and the execution on another. A ping whose span name contained execute or query qualified, and then counted as one more execution of the statement it borrowed. A driver ping now never takes part in the stitch.

Measured in the simulation lab on the Spring services, HikariCP over PostgreSQL, where each ping reaches the trace backend as a root span named after the database. The 0.25.0 daemon counted missing_db_statement=9, exactly the 9 pings the backend held and no other statement-less database span. On 0.25.1 the counter stayed at 0 through 642 pings and 120,264 received spans, and the 12 anti-pattern scenarios still produce their findings.

Upgrade impact

missing_db_statement falls on services behind a connection pool. The pings move to not_io, on perf_sentinel_otlp_spans_filtered_total and in analysis.ingest of the JSON report. A dashboard or an alert built on the missing_db_statement rate sees it drop by the pings it was counting.
The usable span ratio rises for those services. An analyze --ci run that failed min_usable_span_ratio on pool pings alone can now pass.
A finding moves only where a ping had borrowed a statement. That ping no longer adds an execution to the statement it took, so the occurrence count of such a finding can drop by the pings it held. The acknowledgment signatures are untouched.
No configuration key is added or removed, no route, metric name or wire format changes, no public signature in perf-sentinel-core moves, the embedded reference data keeps its vintages, and MSRV stays 1.98.1.

Full detail in CHANGELOG.md.

Verifying this release

# Binary integrity via SLSA Build L3 attestation
gh attestation verify perf-sentinel-linux-amd64 \
  --repo robintra/perf-sentinel

# A periodic disclosure produced by this binary
perf-sentinel verify-hash --report perf-sentinel-report.json \
  --expected-identity "https://github.com/robintra/perf-sentinel/.github/workflows/release.yml@refs/tags/v0.25.1" \
  --expected-issuer "https://token.actions.githubusercontent.com" \
  --verify-binary ./perf-sentinel-linux-amd64

gh CLI 2.49 or newer required for gh attestation verify.