robintra/perf-sentinel chart-v0.13.1

perf-sentinel chart v0.13.1

on GitHub

What's new in chart-v0.13.1

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

Behavior

• max_export_findings is a new key you can set under daemon.config. It sizes the /api/export/report slice apart from the browsing cap on /api/findings, which the export was pinned to. A daemon retaining tens of thousands of findings was stuck shipping 1000 of them with no way to widen the snapshot. The default is that same value, so an untouched values file exports exactly what it exported on 0.13.0.
• Setting it too high is advised on at startup, not at the first request. max_export_findings and max_retained_traces fill the same response body, and a pair sitting inside both comfort zones can still project past the 8 MiB limit the query clients read the snapshot with. The daemon logs the projected total and names both keys and both values. Above the hard ceiling of 100,000 it refuses to start rather than failing later.
• An oversized snapshot now reports the read limit instead of looking like an unreachable daemon. query inspect and query monitor pointed at the in-cluster daemon used to flatten a body over the cap into the same result as a daemon that never answered, which sends an operator to the NetworkPolicy for what is a setting on the peer. query monitor prints the reason beside its [STALE] marker.
• /api/export/report gains warning_details entries under a new snapshot_scope kind. They state that the finding slice is capped and that the green figures describe the latest analyzed batch rather than the exported set, two populations a reader could otherwise take for one. A client that enumerates warning kinds sees one it does not know. A cold-start daemon still reports only cold_start.
• The Prometheus surface is unchanged. The new oversized-body outcome folds onto the body-read reason the energy scrapers already expose, so no series and no label value was added and /metrics keeps its cardinality.
• 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.13.0 to 0.13.1. 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.
• Nothing else in the daemon changes. The rest of 0.13.1 reorganises the HTML dashboard, which perf-sentinel report produces and this chart does not run. Routes, metrics and wire formats are unchanged: /api/findings, /api/correlations, /metrics and the OTLP listeners answer in exactly the same shapes, and the archived per-window JSON keeps its shape. 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.13.1

Upgrade an existing release:

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

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.13.1 binary notes carry the full account of the changes above.

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.13.0...chart-v0.13.1