Skip to content

perf-sentinel chart v0.2.59

Choose a tag to compare

View all tags
@github-actions github-actions released this 18 Jun 10:28
chart-v0.2.59
This tag was signed with the committer’s verified signature.
robintra Robin Trassard
SSH Key Fingerprint: PXKuwB2z5bZZ3oIp+fY+Xz6iV03G/e2xkgzJJxieD4k
Verified
Learn about vigilant mode.
6df67b3

What's new in chart-v0.2.59

Like chart-v0.2.57, this is a real chart-level template change, not a metadata-only bump. appVersion stays at 0.8.12, the daemon image and every wire surface are unchanged. What changes is the rendered post-install notes and the default resources block in values.yaml.

perf-sentinel keeps per-trace and correlation state in memory, per pod, with no shared state. A plain round-robin Service spreads the spans of a single trace across replicas, so N+1 and correlation detection silently degrade because no single pod ever sees the whole trace. The chart now renders a post-install warning whenever workload.replicas is greater than 1 on a non-DaemonSet workload, pointing operators at either replicas: 1 or trace-aware routing (consistent hashing by trace_id through the OTel Collector loadbalancingexporter). A DaemonSet does not trigger the warning, because it ignores workload.replicas and schedules one pod per node, so the replicas-based check does not apply to it.

The default resources block is also resized to the measured daemon footprint. The daemon idles near 17Mi but holds roughly 150 to 190Mi RSS under sustained ingestion, so the previous 64Mi limit risked an OOMKill under load. Requests move from cpu: 50m, memory: 16Mi to cpu: 50m, memory: 64Mi, and limits move from cpu: 200m, memory: 64Mi to cpu: 500m, memory: 256Mi. The throughput plateau is CPU-bound, so limits.cpu is the first knob to raise for heavy traffic. The raw-manifest baseline in docs/INSTRUMENTATION.md is mirrored.

Changed

  • Post-install notes warn on multi-replica non-DaemonSet deployments. When workload.replicas is greater than 1 and workload.kind is not DaemonSet, helm install and helm upgrade now print a scaling warning explaining that per-trace state is per-pod and that a round-robin Service degrades detection. The note links docs/HELM-DEPLOYMENT.md ("Scaling and state").
  • Default resources resized to the measured footprint. Requests are now cpu: 50m, memory: 64Mi, limits are now cpu: 500m, memory: 256Mi (previously 50m/16Mi and 200m/64Mi). The 256Mi limit covers the loaded RSS peak so the kernel does not OOMKill the pod under sustained ingestion.

Behavior

  • No daemon runtime change. appVersion stays 0.8.12. The daemon image, the /api/* routes, the OTLP HTTP and gRPC listeners, the Prometheus series, and the detection findings are all identical to chart-v0.2.58.
  • Upgrades roll the pod with a higher memory ceiling. The values.yaml resource defaults feed the pod spec, so an upgrade that keeps the defaults raises the memory limit from 64Mi to 256Mi and reschedules the pod through the existing checksum/config annotation. Deployments that pinned their own resources override are unaffected.
  • The scaling warning is advisory only. It is post-install text. It does not block install, change any rendered manifest, or alter the Service. Single-replica and DaemonSet deployments never see it.

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

Upgrade an existing release:

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

Full Changelog: chart-v0.2.58...chart-v0.2.59

Assets 4
Loading