Skip to main content

Mimir

Mimir is an open source, horizontally scalable, highly available, multi-tenant TSDB for long-term storage for Prometheus.

Deployment Modes​

On IaaS-providers​

The official Mimir-Distributed Helm Chart only supports microservices mode. For the IaaS-provider overlays we're using this chart, as it delivers a production-ready Mimir setup.

On your local env​

As the official Helm chart does not support monolithic mode, this means that only microservices mode is available. For use on your local environment, this leads to the consumption of too many resources. For that reason, in the Local overlay, we are currently using a forked Helm chart which does support monolithic mode.

In the official Mimir repo, there's an open issue to enable monolithic mode through the Helm chart. Some comments make a lot of sense and we can map this on our own usecase as well.

The folks who are behind the fork, have commented the following:

For those complaining about this, we are still maintaining a working fork that provides this functionality at https://github.com/NGDATA/mimir

We merge in the upstream changes every 2-3 months. We have this setup running on several kubernetes environments without issues.

They are also actively working on getting their fork merged back upstream. Once that has happened, we can start using the official Helm chart.

Object Storage​

Mimir is able to use multiple different storage providers, but in our case we're standardizing on S3 / S3-compatible API's.

Mimir needs 3 Object Storage buckets:

  • mimir-alertmanager
  • mimir-blocks
  • mimir-ruler
info

Keep in mind that the bucket names must be globally unique within the context of an IaaS-provider.

When running the stack on your local environment, a Minio instance is automatically deployed and these three buckets are automically created as well.

For instructions on how to create these with the relevant IaaS provider, please consult the provider-specific instructions.

S3 Credentials Secret​

ℹ When deploying the stack in your local environment using the Local overlay, you can skip the following step.

Use the S3 credentials provided by the concerning IaaS-provider and use these to create a secret.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: s3-credentials
type: Opaque
stringData:
  S3_ACCESS_KEY_ID: <access-key-id>
  S3_SECRET_ACCESS_KEY: <secret-access-key>

Next, use kubeseal to generate a sealed-secret based on the secret above:

kubeseal -f secret.yaml -w sealed.yaml  --controller-namespace sealed-secrets -n mimir

An entry for sealed.yaml has already been preconfigured in kustomization.yaml, you just need to uncomment it. Furthermore, ensure that sealed.yaml is placed in the same folder as the kustomization.yaml.

Don't forget to remove the secret.yaml and definitely do NOT commit the actual secret.yaml to Git!

The HelmRelease patch refers to the secret.

Data Retention​

By default, Mimir retains data for 31 days. You can adjust this to your organisation's needs by setting mimir.structuredConfig.limits.compactor_blocks_retention_period to another value, e.g. 7d for 7 days of retention.