perf-sentinel chart v0.15.0

What's new in chart-v0.15.0

An appVersion move from 0.14.0 to 0.15.0, and nothing else. No template changes, values.yaml untouched, so a values file renders the same objects as 0.14.0 apart from the image tag, the chart version labels and the checksum they feed.

Most of 0.15.0 lands in batch subcommands this chart does not run. What reaches a deployed daemon is the disclosure archive, on both sides: a data-loss fix and a new counter.

Behavior

• A rotation could truncate the disclosure archive to nothing, and no longer can. The writer tracks how many bytes it has appended so it can stop at its configured cap, and it resynced that count by stat-ing the archive path. A rotation moves the file out from under the open descriptor, so the path then named a file that did not exist yet and stat-ed as zero bytes, after which the writer believed it had the whole cap free and a later set_len cut the archive back to empty. It reads the count from the descriptor it holds now, which follows the file through a rename. Exposed deployments are the ones rotating the archive with an external tool rather than letting the daemon reach its own cap, and with statefulset.persistence.enabled=true the loss lands on the PVC.

• /metrics gains perf_sentinel_archive_windows_dropped_total. It counts the per-window archive entries dropped instead of written, labelled by reason with four values fixed at compile time, channel_full, writer_exited, serialize_error and write_error. That is four new series and no user-controlled label value, so the exposition's cardinality stays bounded as it was. All four pre-warm to zero at startup, which is what lets a healthy archive be told from a metric that is simply not there.

• The chart's PrometheusRule does not alert on it. The shipped rules cover the daemon being absent, ingest rejection, memory pressure, analysis shedding, queue saturation, correlator eviction and service cardinality overflow, and nothing was added here. Add your own rule if you archive for disclosure, since the archive hash chain only advances on a successful write, which means a dropped window leaves seq continuous and disclose verify-hash cannot find the gap afterwards:

  - alert: PerfSentinelArchiveDropping
    expr: rate(perf_sentinel_archive_windows_dropped_total[5m]) > 0
    for: 10m

• Archive lines gain a drops field, and the disclosure schema moves to perf-sentinel-report/v1.7. Each line carries the daemon-lifetime cumulative drop count at write time, so two consecutive lines whose drops differ bracket the loss between them and disclose can reconstruct the gaps from the archive alone, without a Prometheus scrape from the right moment. The period report gains windows_dropped and drop_counter_resets under integrity.trace_integrity_chain. A validator pinned to v1.6 rejects the new reports.

• The archive chain still verifies across the upgrade. The line hash covers whatever keys the body carries, so lines written by a 0.14.0 pod and by a 0.15.0 pod verify side by side in one archive file. Lines written before the counter existed report the two new fields as absent rather than zero, so an archive from before the upgrade never reads as a period that dropped nothing.

• The image ships h2 0.4.19 against RUSTSEC-2026-0258. It reaches the daemon transitively through hyper, under both the OTLP listeners and the query API, so this is the dependency patch the pod picks up on the rollout. Patch-level and semver-compatible, no behavior change.

• The upgrade rolls the pods. The image tag falls back to .Chart.AppVersion when image.tag is empty, which is the default, so the pod spec moves from 0.14.0 to 0.15.0. The checksum/config annotation also changes, since the ConfigMap carries the chart version in its labels. Pinning image.tag explicitly keeps the old image and skips the rollout.

• The rest of 0.15.0 does not reach this chart. The diff mutation pairing, the pg-stat and mysql-stat trace cross-reference, the --baseline coverage estimate and the acknowledgment successor warning are all batch subcommands the chart does not run, and the two dashboard color fixes belong to the HTML that perf-sentinel report renders, not to the JSON this daemon serves on /api/export/report. Routes and wire formats are unchanged: /api/findings, /api/correlations, /api/export/report, /metrics and the OTLP listeners answer in exactly the same shapes. Findings, thresholds and signatures are untouched, so no acknowledgment and no baseline moves on this upgrade.

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.15.0

Upgrade an existing release:

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

Verify that the rollout picked up the new image:

kubectl get pod -l app.kubernetes.io/name=perf-sentinel \
  -o jsonpath='{.items[*].spec.containers[*].image}'

Read docs/HELM-DEPLOYMENT.md for the sizing guidance, the Ingress postures, the NetworkPolicy peer an ingress controller needs, and the acknowledgments ConfigMap mount. The v0.15.0 binary notes carry the full account of the changes above, including the two blind spots the drop counter cannot close.

If you are upgrading from chart-v0.12.0 or earlier, read the chart-v0.13.0 notes first: that release makes a mounted acknowledgments ConfigMap reload without a pod restart, and it stops a ConfigMap projection from blocking startup. Mount that ConfigMap as a directory, a subPath mount defeats the reload.

Full Changelog: chart-v0.14.0...chart-v0.15.0