robintra/perf-sentinel chart-v0.24.0

perf-sentinel chart v0.24.0

on GitHub

What's new in chart-v0.24.0

One default moves and nothing else does. workload.statefulset.persistence.size goes from 1Gi to 2Gi, no template changes, no values.yaml key is added or removed, the shipped PrometheusRule is untouched, and the rendered perf-sentinel.toml is byte-for-byte what chart-v0.23.0 rendered, same 5477 bytes and the same digest. appVersion moves to 0.24.0 and image.tag follows it to :0.24.0.

A claim that could never hold what the chart puts on it

With persistence.enabled, the chart points [daemon.archive] path at the volume it creates. At its own defaults that archive keeps one active file plus max_files (12) rotated ones of max_size_mb (100) each, about 1.3 GB, and the ack store sits beside it. The claim was 1Gi.

A full volume does not stop the daemon. The archive writer drops the windows it cannot write and counts them on perf_sentinel_archive_windows_dropped_total{reason="write_error"}, so the loss was silent unless somebody watched that counter, and the periodic disclosure built from that archive came out with holes its hash chain cannot show.

2Gi covers the archive at its defaults with room beside it. It leaves nothing for a [daemon.incidents] archive_path pointed at the same volume, which the incidents note in values.yaml suggests doing: that file is append-only and never rotates, so raise the claim further for it or keep it off the PVC.

What moves inside the pod

The daemon reads its incident ring back from [daemon.incidents] archive_path at startup, so /api/incidents and the Grafana incident panels no longer come back empty after every restart and every helm upgrade. The archive was written and never read. The replay is bounded to the file's last 256 MiB so an unrotated file cannot hold the daemon past its liveness probe, it runs before the API serves, and nothing is appended back.

Findings that carried no framework signal now carry a suggested_fix: an OpenTelemetry Java agent scope identifies Java, cross-trace and cross-batch slow findings go through the suggestions step, the four structural types carry the scopes and code_location of one representative call, and a framework with no fix for a type falls back to its language generic. Finding signatures depend on neither field, so existing acknowledgments still match.

GET /api/incidents takes an id and GET /api/acks takes an include_toml. Both are additions, and a client that sends neither sees the response it saw before.

The v0.24.0 binary notes describe all of it.

Upgrade impact

• An existing StatefulSet keeps its 1Gi claim. A volumeClaimTemplate is immutable, so helm upgrade cannot grow it. Resize the PVC itself where the StorageClass allows expansion, or reinstall the release. A fresh install gets 2Gi.
• Go back below 2Gi only with the archive sized to match. persistence.manageDaemonPaths: false and a smaller [daemon.archive] in config.toml, when storage rather than the archive is what you are short of.
• Pods roll on the image. helm upgrade replaces them because appVersion and image.tag move together.
• Incidents come back on the first restart after the upgrade, where [daemon.incidents] archive_path is set. The ring is repopulated from a file the daemon has been writing all along, so the incident panels show history they never had.
• Findings gain fields they did not carry. suggested_fix, instrumentation_scopes and code_location appear on findings that had none. No finding appears or disappears and no signature changes.
• 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.
• The two example Grafana dashboards live outside this chart. The findings one moves to version 11: a History (Hub) row that reads PerfSentinelHub through a second, optional Infinity datasource, an Ack column on its three findings tables, incident panels that page the whole ring, and a readable info severity on a dark theme. Re-import it wherever you provision it.
• The example incident alerting rules live outside this chart too, and they gain a perf_sentinel:untraced_services:1d recording rule so a workload the daemon has never traced raises nothing. Under the VictoriaMetrics operator that rule needs the VMAlert's remoteWrite, without which vmalert refuses every rule it selects.

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

Upgrade an existing release:

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

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

If you are upgrading from chart-v0.18.0 or earlier, read the chart-v0.19.0 notes first: 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, read the chart-v0.17.0 notes as well, which change the shipped PrometheusRule.

Full Changelog: chart-v0.23.0...chart-v0.24.0