robintra/perf-sentinel chart-v0.12.0

perf-sentinel chart v0.12.0

on GitHub

What's new in chart-v0.12.0

An appVersion move from 0.11.2 to 0.12.0, plus two commented reference blocks in values.yaml. No template changed, and the two additions are comments, so a values file renders the same objects as 0.11.2 apart from the image tag, the chart version labels and the checksum they feed.

Everything under Behavior is what the new daemon image does differently once it rolls. One of those items can stop the pod from starting at all, which is a first for this chart, so read that one before rolling anything.

Behavior

• A stale or misspelled key in config.toml now stops the daemon at startup. Sixteen configuration sections used to accept anything they did not recognize, silently, and ran on the default. They now reject it. The ConfigMap this chart renders is unchanged and renders identically, but the new image refuses the same content if it carries a key that was quietly ignored before, and the pod enters CrashLoopBackOff. [thresholds], [detection], [green], [daemon], [daemon.correlation], [daemon.ack], [daemon.cors] and every energy-backend section are affected, which is to say every section a values file actually customizes. Render it and load it once before rolling out: helm template ... | ... the ConfigMap out, then perf-sentinel analyze --config <file>. The error names the offending key and lists the valid ones beside it.
• 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.11.2 to 0.12.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 daemon reports fewer findings on identical traffic. Connection and session management statements, COMMIT, SET, SELECT set_config(...), pool pings and their vendor equivalents, no longer surface as n_plus_one_sql, redundant_sql or links of a serialized_calls chain. A pooled driver emits one per connection checkout, so a request borrowing N connections showed N identical statements behind a remediation that cannot apply to a SET.
• io_waste_ratio falls on identical traffic. Those statements keep counting as I/O operations, so total_io_ops and the carbon figures hold, but their operations leave avoidable_io_ops, which is derived from the findings. The chart ships io_waste_ratio_max = 0.30 in values.yaml, and a threshold calibrated against a 0.11.2 run is now looser than intended rather than tighter. Re-baseline it against a 0.12.0 run before trusting the gate verdict. This is the opposite direction from chart-v0.11.2, where the same ratio rose.
• Acknowledgments covering one of those findings will report as unmatched. Signatures themselves are untouched, so nothing moves. A finding that disappeared simply leaves its acknowledgment with nothing to suppress, and a fresh batch analysis says the problem looks fixed, which is the wrong conclusion for an ack whose finding only vanished with the upgrade.
• The daemon can now push findings to PerfSentinelHub. [daemon.hub_export] is off by default and values.yaml gains it as a commented reference block. Enabling it needs the API key as a mounted file, never a value: use extraVolumes and extraVolumeMounts to expose a Secret at the configured api_key_file path. perf_sentinel_hub_export_pending exposes the backlog and perf_sentinel_hub_export_dropped_total counts what is lost.
• Shutdown drains the Hub exporter, bounded to 10 seconds. Only relevant with the exporter enabled. The default terminationGracePeriodSeconds of 30 seconds leaves room for it, but a cluster that lowers it below 10 seconds cuts the drain short and loses whatever was still pending.
• The commented [daemon.correlation] block gains max_tracked_pairs. It listed the three other keys of that section and silently omitted the one that truncates. Pairs scale with finding types times services, so enabling correlation on a seven-service fleet overruns the 10000 default and /api/correlations returns an arbitrary subset with nothing on the output saying so. perf_sentinel_correlator_pairs_evicted_total is the signal that it is happening, and unlike the other daemon limits this knob gets no comfort-zone warning at startup.
• Routes, metrics and wire formats are unchanged. /api/findings, /api/correlations, /metrics and the OTLP listeners answer in exactly the same shapes, minus the two new Hub export gauges. The archived per-window JSON keeps its shape, so a disclosure content_hash computed under 0.11.2 still verifies here.

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

Upgrade an existing release:

helm upgrade perf-sentinel oci://ghcr.io/robintra/charts/perf-sentinel --version 0.12.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 and the NetworkPolicy peer an ingress controller needs. The v0.12.0 binary notes carry the full account of the detection and configuration changes above.

If you are upgrading from chart-v0.11.1 or earlier, read the chart-v0.11.2 notes first: that release moves the endpoint a finding is attributed to, which does change acknowledgment signatures and persisted baselines, and it moves io_waste_ratio in the opposite direction from this one.

Full Changelog: chart-v0.11.2...chart-v0.12.0