Dropping raw metrics without shipping them to s3 and only keeping recording rules for a tenant. Any recommendations?

[AKNucoder]

I have a use case where I want to drop raw metrics and only keep recording rules for a specific tenant.

• I'm thinking I could use mimir federated rule evaluations where I store the recording rule evaluations of the raw metrics tenant into a different tenant with a long retention time.
• This raw metrics tenant only has a retention of 2 hours so they'd get dropped.

My issue is that I don't want these raw metrics shipped to the backend s3 only to get deleted shortly after. Any recommendations on how to avoid having these raw metrics getting uploaded to the backend storage? I'm open to other ideas, but wanted to see what the best practice is for this use case.

[56quarters]

I have a use case where I want to drop raw metrics and only keep recording rules for a specific tenant.
I'm thinking I could use mimir federated rule evaluations where I store the recording rule evaluations of the raw metrics tenant into a different tenant with a long retention time.

That sounds reasonable to me.

This raw metrics tenant only has a retention of 2 hours so they'd get dropped.

Ingesters keep the last 24h of metrics and are queried for the last 12h of metrics by default so this wouldn't really have any effect. I'd also recommend not having a such an aggressive retention policy as a backup in case you find a problem with the aggregation being performed or there's a ruler outage or something like that.

My issue is that I don't want these raw metrics shipped to the backend s3 only to get deleted shortly after. Any recommendations on how to avoid having these raw metrics getting uploaded to the backend storage? I'm open to other ideas, but wanted to see what the best practice is for this use case.

Trying to prevent metrics from being shipped to object storage is going to be fighting against how Mimir works. Personally, I'd keep the raw metrics for a few days (meaning they do get shipped to object storage) as insurance against issues with the recording rules or aggregations being done.