github robintra/perf-sentinel chart-v0.25.1
perf-sentinel chart v0.25.1

4 hours ago

What's new in chart-v0.25.1

A metadata-only bump. No template changes, no values.yaml key added or removed, and the rendered perf-sentinel.toml is byte-for-byte what chart-v0.25.0 rendered, same 5047 bytes and the same digest under the default values. appVersion moves to 0.25.1 and image.tag follows it to :0.25.1, which is the whole of this release: everything it ships is inside the daemon image.

What moves inside the pod

A driver ping no longer counts as a missing statement. 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, and the OpenTelemetry JDBC instrumentation traces that call with db.statement="". The daemon counted each of those as a missing_db_statement instrumentation gap. It now filters them as not_io, while a statement stripped by a redacting layer, which keeps its operation, still counts as the gap it is.

This one shows more under Helm than on a laptop, because a cluster is where the pools run all day. In the simulation lab, on three Spring services over PostgreSQL, the 0.25.0 daemon counted every ping the trace backend held as a missing statement, 9 of 9, and the 0.25.1 daemon counted none of 642.

The v0.25.1 binary notes describe it, including the split-span stitch a ping no longer takes part in.

Upgrade impact

  • Pods roll on the image. helm upgrade replaces them because appVersion and image.tag move together.
  • missing_db_statement falls where services sit behind a connection pool. The pings move to not_io on perf_sentinel_otlp_spans_filtered_total, so the OTLP span intake (received vs filtered) panel of the example overview dashboard shows them under not_io from the upgrade on, and an alert on the missing_db_statement rate sees it drop.
  • checksum/config moves too, and not because your configuration changed. The rendered perf-sentinel.toml is identical, but the ConfigMap carries helm.sh/chart and app.kubernetes.io/version labels that bump with the chart, so the checksum over it differs on every version bump.
  • No values.yaml key is added or removed, no template changes, and the shipped PrometheusRule is untouched.
  • The example incident alerting rules live outside this chart and now leave out the pods a Job owns, in the OOM, restart and memory-saturation rules, through kube_pod_owner{owner_kind="Job"}. A trivy-operator scan Job names its container after the container it scans, so a scan pod that restarted could reach the daemon as an incident with no finding. Re-apply examples/incident-alerts-prometheus-operator.yaml or its VictoriaMetrics twin wherever you deploy them.

Install

The chart is published as an OCI artifact on GHCR, install it directly with no helm repo add step:

helm install perf-sentinel oci://ghcr.io/robintra/charts/perf-sentinel --version 0.25.1

Upgrade an existing release:

helm upgrade perf-sentinel oci://ghcr.io/robintra/charts/perf-sentinel --version 0.25.1

Read docs/HELM-DEPLOYMENT.md for the ServiceMonitor section, sizing and Ingress postures.

If you are upgrading from chart-v0.23.0 or earlier, read the chart-v0.24.0 notes first: that release raises the default workload.statefulset.persistence.size to 2Gi, which an existing StatefulSet does not pick up on its own. From chart-v0.18.0 or earlier, read the chart-v0.19.0 notes as well: that release adds a grouping label to five metrics and is breaking for an unaggregated alert on any of them. From chart-v0.16.0 or earlier, the chart-v0.17.0 notes change the shipped PrometheusRule.

Full Changelog: chart-v0.25.0...chart-v0.25.1

Don't miss a new perf-sentinel release

NewReleases is sending notifications on new releases.