Ensure that metrics retention is long enough #211

New issue

Open

opened 2025-05-08 17:01:39 +00:00 by raito · 1 comment

raito commented

2025-05-08 17:01:39 +00:00

(Migrated from git.lix.systems)

We should make use of downsampling to be able to aggregate long term metrics and keep some information over the 10 years, 5 years, 1 year with different downsampling options.

cc @k900

We should make use of downsampling to be able to aggregate long term metrics and keep some information over the 10 years, 5 years, 1 year with different downsampling options. cc @k900

emilylange commented

2025-05-11 11:20:32 +00:00

(Migrated from git.lix.systems)

Unfortunately, downsampling is currently not implemented nor supported in Mimir.
Most other metrics storage backends however do 🫠

tl;dr for https://github.com/grafana/mimir/discussions/1834#discussioncomment-2727217 and https://github.com/grafana/mimir/pull/5028:

s3 storage is cheap
downsampling is very IO intensive
complicates promql query engine

Most workarounds for this aren't particularly great.
Maybe we defer this for now and lower its priority from "High" to "Medium" or even "Low" and also mark it as blocked (by upstream)?

Unfortunately, downsampling is currently not implemented nor supported in Mimir. Most other metrics storage backends however do 🫠 tl;dr for https://github.com/grafana/mimir/discussions/1834#discussioncomment-2727217 and https://github.com/grafana/mimir/pull/5028: - s3 storage is cheap - downsampling is very IO intensive - complicates promql query engine Most workarounds for this aren't particularly great. Maybe we defer this for now and lower its priority from "High" to "Medium" or even "Low" and also mark it as blocked (by upstream)?

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: afnix/infra#211

No description provided.

Rows
Columns