Grafana Mimir — бесконечное хранилище для Prometheus

Никита Ражев

Старший инженер КРОК

Grafana Mimir — продукт Grafana Labs, построенный на основе проекта Cortex, был анонсирован и запущен в 2022 году. По нему практически нет подробных разборов и гайдов от пользователей. В статье расскажем, как он устроен и в чём его плюсы и минусы. А также попробуем сравнить его с известными инструментами Thanos и VictoriaMetrics.

Что за Mimir?

Mimir предназначен для долговременного хранения метрик мониторинга, представленных в формате временных рядов. Такими метриками, например, оперирует популярная система мониторинга с открытым исходным кодом Prometheus.

Mimir получает данные от систем-источников с помощью функции Prometheus remote-write и сохраняет их, используя сторонние объектные хранилища, такие как Amazon S3 или GCS. За счёт этого уменьшается стоимость и повышается надёжность хранения. 

Основное преимущество Grafana Mimir — сравнительно высокая скорость обработки данных за счёт распределения нагрузки и оптимизированного хранения, а также механизмов сжатия, кэширования и индексации. И новой архитектуры, которая позволяет быстро загружать и обрабатывать большие объёмы данных из множества различных источников.

Использование Mimir позволяет собирать и агрегировать в одном месте данные из нескольких различных инсталляций Prometheus, VictoriaMetrics и Grafana Agent. Продукт также предоставляет расширенные возможности по созданию сложных запросов и обработке данных. Это эффективно решает проблемы обработки и анализа больших объёмов данных за длительный период.

Варианты развёртывания

Mimir можно развернуть в двух вариантах: all-in-one (монолитный), в котором все компоненты работают в едином контейнере или исполняемом файле, и микросервисный, когда компоненты запущены в отдельных контейнерах/подах, и каждый компонент доступен для масштабирования. Микросервисный вариант идеально подходит для работы в Kubernetes.

Монолитный вариант

Микросервисный вариант

Компоненты Mimir

• Distributor — компонент, не требующий собственного постоянного хранилища. Получает и валидирует данные от источников, например, Prometheus или Grafana agent, и далее отправляет их в компонент Ingester, причём параллельно, согласно заданному фактору репликации (по умолчанию он равен 3).
• Ingester — записывает метрики, полученные из Distributor, в долговременное хранилище, но также хранит их некоторое время у себя в кэше и отвечает на запросы от Querier, если блоки данных ещё в кэше.
• Querier — занимается поиском данных на основе выражений PromQL для недавних данных в Ingester и в долговременном хранилище через Store-gateway.
• *Query Frontend — позволяет кэшировать ответы от компонента Querier и сразу выдавать клиентам. Авторы проекта рекомендуют разворачивать этот компонент для ускорения отклика. Именно с ним взаимодействует клиент, когда обращается к Mimir.
• Store-gateway — отвечает за выгрузку данных из долговременного хранилища. Store-gateway периодически опрашивает хранилище на наличие обновлённого Compactor’ом индекса бакета, и сохраняет его локально.
• Compactor — улучшает производительность хранилища и сокращает утилизацию его ресурсов за счёт объединения, сжатия и дедупликации блоков данных, а также удаляет блоки данных по настроенным политикам хранения.
• *Ruler — позволяет хранить данные для агрегации метрик и правил алертинга, например, между разными тенантами на основе PromQL выражений. Для этого он использует встроенные Querier и Distributor.
• *Alertmanager — добавляет возможность мультиарендной и масштабируемой работы Prometheus Alertmanager.
• *Query-scheduler — занимается хранением и распределением очереди запросов между доступными Querier.
• *Overrides-exporter — позволяет настроить различные ограничения для тенантов, например, в части количества метрик. Доступны отдельные метрики для анализа и мониторинга использования этих лимитов.

* — опциональные компоненты архитектуры

Преимущества и сравнение с конкурентами

На рынке известен другой продукт с похожей функциональностью и предназначением — это Thanos, который также реализует долговременное хранилище для Prometheus-like систем мониторинга.

Несмотря на то что Thanos и Mimir имеют схожую архитектуру, выделим некоторые различия.

• В Mimir нет необходимости подключаться к текущему Prometheus как sidecar. В Thanos есть компонент Thanos receiver, но в документации говорится, что стоит его использовать только для изолированных сред.
• Компонент Store в Thanos не поддерживает масштабируемость штатными средствами.
• Надёжность Thanos Rule оставляет желать лучшего, например, могут потеряться алерты в случае сбоев других компонентов Thanos.

Однако, на текущий момент, Mimir в отличие от Thanos не поддерживает downsampling и удаление отдельных блоков данных, кроме как с помощью политик хранения.

Сравнение с Victoria Metrics будет не совсем корректным, так как инструменты в основном реализуют разные функции.

• Mimir — в первую очередь, хранилище, в которое другие источники метрик записывают данные по push-модели. 
• VictoriaMetrics — полноценная система мониторинга, которая сама по pull-модели собирает метрики с различных экспортёров и агрегирует их локально в своём формате хранения. Поэтому VictoriaMetrics и Mimir можно — и в некоторых случаях необходимо — использовать совместно.

Также по результатам тестирования мы отметили очевидные плюсы Mimir.

• Он удобно и быстро развёртывается, у него понятная документация. Можно без особых трудностей подключить новые источники метрик.
• Легко горизонтально масштабируется, достаточно запустить необходимое количество реплик у компонентов. Доступна настройка autoscaling’а.
• Интегрируется с механизмом алертинга Grafana.
• Позволяет реализовать мультиарендность, которая базируется на основе дополнительных заголовков HTTP-запросов в Prometheus remote-write.

Практические кейсы для использования

У Mimir есть несколько вариантов применения, которые отличаются в зависимости от задач. Основные из них:

• сбор и хранение метрик с удалённых Prometheus-like систем мониторинга с минимальным изменением их конфигурации;
• стандартизация и агрегация данных, собранных разными системами мониторинга внутри организации (что позволяет использовать единую точку входа для всех пользователей);
• предоставление пользователям, как внутренним в компаниях, так и внешним, сервиса MaaS (Monitoring as a Service).

Как интегрировать облако с Grafana Mimir

Чтобы использовать Mimir для долговременного хранения данных, его нужно настроить для работы с объектным хранилищем по протоколу S3. Его можно развернуть у себя локально, но удобно также использовать готовые объектные хранилища от облачных провайдеров. 

Развёртывание

По умолчанию Mimir в качестве хранилища использует MinIO. Рассмотрим стандартное развёртывание в Kubernetes с использованием официального helm-чарта https://grafana.com/docs/helm-charts/mimir-distributed/latest/ и подключение к внешнему S3-хранилищу.

• Создадим новый namespace под Mimir:

			kubectl create namespace mimir-test
		

• Добавим helm-репозиторий Grafana:

			helm repo add grafana https://grafana.github.io/helm-charts
helm repo update
		

• Создадим файл с values для настройки S3-хранилища. В качестве него мы будем использовать объектное хранилище Облака КРОК:

			nginx: 
  ingress:
    enabled: true
    ingressClassName: nginx
    annotations: {}
    hosts:
      - host: mimir-example.croc.ru
        paths:
          - path: /
            pathType: Prefix
minio:
  enabled: false

global:
  extraEnvFrom:
    - secretRef:
        name: mimir-bucket-secret
  podAnnotations:
    bucketSecretVersion: "0"


mimir:
  structuredConfig:
    common:
      storage:
        backend: s3
        s3:
          endpoint: storage.cloud.croc.ru
          region: croc
          secret_access_key: ${AWS_SECRET_ACCESS_KEY}
          access_key_id: ${AWS_ACCESS_KEY_ID} 
    alertmanager_storage:
      s3:
        bucket_name: mimir-croc-alertmanager
        access_key_id: ${AWS_ACCESS_KEY_ID}
        endpoint: storage.cloud.croc.ru
        secret_access_key: ${AWS_SECRET_ACCESS_KEY}
    blocks_storage:
      backend: s3
      s3:
        bucket_name: mimir-croc-blocks
        access_key_id: ${AWS_ACCESS_KEY_ID}
        endpoint: storage.cloud.croc.ru
        secret_access_key: ${AWS_SECRET_ACCESS_KEY}
    ruler_storage:
      s3:
        bucket_name: mimir-croc-ruler
        access_key_id: ${AWS_ACCESS_KEY_ID}
        endpoint: storage.cloud.croc.ru
        secret_access_key: ${AWS_SECRET_ACCESS_KEY}
		

• Создадим Secret для хранения ключей для доступа к S3:

			apiVersion: v1
kind: Secret
metadata:
  name: mimir-bucket-secret
data:
  AWS_ACCESS_KEY_ID: example:example@croc.ru
  AWS_SECRET_ACCESS_KEY: secretkey
		

			kubectl -n mimir apply -f secret.yml
		

• Развернём helm-чарт в кластере Kubernetes:

			helm install grafana/mimir-distributed -f values.yml
		

• В Prometheus/VictoriaMetrics укажем эндпоинт Ingress для RemoteWrite:

			remote_write:
  - url: http://mimir-example.croc.ru/api/v1/push
		

Настроенные таким образом Prometheus/VictoriaMetrics, будут отправлять данные в зависимости от указанных источников в разделе scrape_configs.

Подключим Mimir в Grafana в качестве Data Source:

• заходим в раздел Configuration —> Data Sources —> Add new data source

• в строку URL вписываем host, который задавали ранее в файле values.yml

• сохраняем источник

Теперь с помощью добавленных дашбордов мы можем визуализировать метрики, находящиеся в Mimir.