Skip to content

fix(monitoring): set Prometheus retention to 10y, never 0 - #97

Merged
hakan-persson merged 1 commit into
mainfrom
fix/prometheus-retention-not-zero
Sep 5, 2026
Merged

fix(monitoring): set Prometheus retention to 10y, never 0#97
hakan-persson merged 1 commit into
mainfrom
fix/prometheus-retention-not-zero

Conversation

@hakan-persson

Copy link
Copy Markdown
Member

The bug

retention: 0d (merged in #96) does not mean "keep forever". Prometheus treats retention.time=0 as unset and falls back to its built-in 15 day default. The change intended as infinite retention actually made retention far shorter than the 90d it replaced.

Confirmed on the running instance:

$ curl /api/v1/status/runtimeinfo
"storageRetention": "15d"

Impact

The TSDB now starts at 2026-08-20. The camp period (2026-07-23 → 08-02) has been pruned. Prometheus disk usage dropped 46.1 GB → 14.4 GB, and prometheus_tsdb_time_retentions_total = 33 block deletions.

Not recoverableaz snapshot list and az backup vault list are both empty for the Jamboree26 subscription.

Fix

Explicit positive duration:

retention: 10y
retentionSize: "0"

retentionSize: "0" is safe to keep as a size-pruning disable because retention.time is now positive. The trap is specifically that both being zero/unset triggers the default.

Loki is unaffected

retention_period: 0s genuinely means keep-forever in Loki, and the compactor has deletes disabled. Camp logs verified intact: 14,924,877 lines across 2026-07-23 → 08-02, all 264 hours present, no gaps, min ~9k lines/hour. j26-prod alone has 5.85M lines over the camp peak.

🤖 Generated with Claude Code

retention: 0d does NOT mean "keep forever". Prometheus treats
retention.time=0 as unset and falls back to its built-in 15d default, so
the previous change (intended as infinite retention) silently made
retention far SHORTER than the 90d it replaced.

Effective retention was 15d, confirmed via /api/v1/status/runtimeinfo
(storageRetention: "15d"). TSDB now starts 2026-08-20; the camp period
(2026-07-23..08-02) has been pruned and is not recoverable — there are no
disk snapshots or backup vaults in the subscription.

Use an explicit positive duration instead. retentionSize: "0" is safe to
keep as a size-pruning disable now that retention.time is positive.

Loki is unaffected: retention_period: 0s is genuinely "keep forever" there,
and camp logs are verified intact (14.9M lines, no hourly gaps).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Copilot AI lite review requested due to automatic review settings September 5, 2026 09:04
@hakan-persson
hakan-persson merged commit 7949ca4 into main Sep 5, 2026
2 checks passed
@hakan-persson
hakan-persson deleted the fix/prometheus-retention-not-zero branch September 5, 2026 09:04

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

The change is small, correctly scoped to the Prometheus values, and directly addresses the documented retention-time fallback behavior.

Pull request overview

This PR fixes Prometheus retention configuration in the monitoring Helm values so that retention is truly long-term instead of silently falling back to Prometheus’ default (15 days) when set to 0.

Changes:

  • Set prometheus.prometheusSpec.retention to an explicit positive duration (10y) to avoid the 0/unset fallback behavior.
  • Keep prometheus.prometheusSpec.retentionSize: "0" to disable size-based pruning while time-based retention is explicitly set.
File summaries
File Description
k8s/infra-manifest/monitoring/helm-values.yaml Updates Prometheus retention settings to ensure time-based retention is explicitly long-term and does not revert to the default.
Review details
  • Files reviewed: 1/1 changed files
  • Comments generated: 0
  • Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants