robintra/perf-sentinel chart-v0.9.23

perf-sentinel chart v0.9.23

on GitHub

What's new in chart-v0.9.23

This chart release carries the messaging daemon and changes one default that can turn a green pipeline red. No template is touched, so a Deployment, StatefulSet or DaemonSet install renders exactly as it did under 0.9.22, with one exception: the ConfigMap now holds a fourth quality-gate rule. appVersion advances to 0.9.23, the release that admits OpenTelemetry messaging spans as I/O and attributes broker energy to the findings they produce.

Changed (can fail a gate that passed before)

• The default config.toml gains n_plus_one_messaging_warning_max = 3. A values file that keeps the bundled config.toml inherits the fourth gate rule, so a service carrying four or more warning-or-higher n_plus_one_messaging findings starts failing its gate with no configuration change of its own. The threshold counts warning-and-above rather than critical-only on purpose: a Kafka client may already batch the publishes it buffers, so the occurrence count is an upper bound and a zero tolerance would fire on work already done. Override the value under config.toml in your values file to keep the previous behavior.
• config.toml accepts the two new broker energy sections. [green.alumet.broker] measures a declared broker cgroup with Alumet. [green.broker_static] needs no agent at all, an operator declares nodes and an instance type and the embedded SPECpower table turns that into watts, which is the only path open on a managed broker such as MSK, Confluent Cloud or SQS. Neither is enabled by default and the schema still treats config.toml as an opaque string, so nothing changes for a values file that does not set them.

Added (companion Grafana dashboard)

The dashboard is examples/grafana-dashboard.json in the repository, deliberately not rendered by the chart, since a dashboard pinned in a chart drifts from the Grafana you already run. Re-import it after upgrading to pick up:

• A messaging series on the slow-span panel, so publish latency is visible beside SQL and HTTP.
• An OTLP span intake panel, plotting perf_sentinel_otlp_spans_received_total against filtered and rejected spans, which is what tells you the daemon is being fed rather than merely running.
• The three missing energy backends on the freshness panel. It plotted Scaphandre and cloud energy only, so an operator running Alumet, Kepler or Redfish saw no staleness signal at all. All five now appear.
• Analysis batch shedding on the headroom panel, from perf_sentinel_analysis_shed_batches_total. Shedding is the daemon dropping whole analysis batches under queue pressure, so findings go missing with nothing else moving, which makes it the counter to alert on rather than to discover afterwards.
• A description on every panel stating what the metric measures and how to read it, since the metric names alone assume knowledge of the pipeline internals.

Behavior

• No template changes. Manifests render identically for every workload kind, so upgrading from 0.9.22 rolls nothing beyond the new image and the ConfigMap line above. The DaemonSet opt-in workload.daemonset.spanRoutingByTraceId introduced in 0.9.22 is unchanged and still required.
• The eight PrometheusRule alerts are unchanged, and still disabled by default under prometheusRule.enabled.
• appVersion moves to 0.9.23, so upgrading pulls the new daemon image unless image.tag is pinned. That release widens what counts as I/O: publish spans now feed total_io_ops, the I/O intensity score and the waste-ratio denominator, so the same traffic scores differently than it did under 0.9.22. Read the v0.9.23 release notes before upgrading a cluster whose dashboards or gates track those numbers.

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

Upgrade an existing release:

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

Keeping the previous gate behavior on a bus-heavy service means overriding the threshold in your own values file. config.toml is one opaque string, so a --set cannot patch a single line inside it, copy the block from values.yaml and edit the rule:

config:
  toml: |
    [thresholds]
    n_plus_one_sql_critical_max = 0
    n_plus_one_http_warning_max = 3
    n_plus_one_messaging_warning_max = 20   # was absent before 0.9.23
    io_waste_ratio_max = 0.30
    # ... keep the rest of the default block

Full Changelog: chart-v0.9.22...chart-v0.9.23