Мониторинг инфраструктуры через Thanos: масштабируемый Prometheus

Мы часто видим ситуацию: несколько Prometheus-инстансов собирают метрики с разных кластеров, дата-центров или облачных регионов. Нет единой точки, где можно выполнить запрос по всем данным сразу. А retention в Prometheus ограничен локальным диском — хранить метрики дольше пары месяцев становится дорого и неэффективно. При этом нагрузка может достигать 1 млн метрик в секунду, и каждый инстанс Prometheus хранит данные локально, что приводит к дублированию и увеличению затрат.

Thanos решает обе эти проблемы. Он обеспечивает единый global view поверх множества Prometheus и переносит долгосрочное хранение метрик в объектное хранилище (S3, GCS, Azure Blob). При этом Thanos не заменяет Prometheus, а дополняет его, сохраняя привычный PromQL и совместимость с Grafana. На практике это позволяет сократить расходы на инфраструктуру до 40% за счёт оптимизации хранения и downsampling.

Мы с командой внедрили Thanos на десятках проектов, от стартапов до крупных enterprise-инсталляций с сотнями тысяч метрик в секунду. Ниже — практический разбор компонентов, типичные ошибки и процесс внедрения.

Архитектура Thanos: компоненты

Thanos — набор микросервисов, каждый со своей зоной ответственности. Минимальная установка включает четыре основных компонента.

Сравнение хранения: локальное Prometheus vs Thanos Object Storage

Почему Thanos, а не Prometheus в одиночку?

Prometheus эффективен для одного кластера или группы серверов. Как только появляется второй Prometheus — для другого региона, проекта или изоляции tenant'ов — возникает проблема «разрозненных стекол». Вам приходится переключаться между datasources в Grafana или писать сложные прокси. Thanos объединяет все источники под единый Query endpoint, а глобальный retention настраивается один раз для всех данных. Наши клиенты экономят до 40% на стоимости хранения метрик за счёт downsampling и tiered retention.

Как избежать дублирования данных в Thanos?

Если Prometheus запущен в HA (два инстанса с одинаковой нагрузкой), Thanos Querier будет видеть дублированные ряды. Дедупликация включается флагом --query.replica-label=prometheus_replica. Но условие: оба Prometheus должны иметь одинаковые все внешние labels, кроме label-реплики. Типичная ошибка — разные значения cluster или env. В результате Querier считает их разными source'ами и не дедуплицирует — на графиках вы увидите удвоение значений.

Пример корректной конфигурации:

global:
  external_labels:
    cluster: production-eu
    env: production
    prometheus_replica: replica-0 # для второго инстанса replica-1

Мы рекомендуем для каждого Prometheus-инстанса заранее согласовать схему external_labels и тестировать дедупликацию на стейджинге.

Почему Store Gateway может быть медленным?

Store Gateway не кэширует сами метрики, только индексы. Без кэширования запрос к данным за месяц будет медленным (до 10 секунд). Оптимальная настройка: --index-cache-size=512MB и установка Redis или Memcached как shared cache. Это снижает задержку в два-три раза.

Bucket config с retention для downsampled данных:

---
type: S3
config:
  bucket: metrics-thanos-prod
  endpoint: s3.eu-west-1.amazonaws.com
  retention:
    resolution_raw: 30d
    resolution_5m: 90d
    resolution_1h: 365d
---

Raw данные (15-секундные) хранятся 30 дней — это дорого. Downsampled до 5-минутного и часового разрешения — дольше и дешевле. Запросы за последний квартал работают с 5m, за год — с 1h.

Как Thanos снижает стоимость хранения?

Thanos использует downsampling: редко запрашиваемые старые данные хранятся в агрегированном виде (5-минутное или часовое разрешение). Это уменьшает объём хранилища в 10–20 раз по сравнению с raw-данными. Например, за год хранения raw-метрик заняло бы ~10 ТБ, а с downsampling — 500 ГБ. Плюс tiered retention: raw — 30 дней, 5m — 90 дней, 1h — 365 дней. Таким образом, 70% данных хранится в дешёвом объектном хранилище, что даёт экономию до 40%. Для масштабирования Prometheus Thanos незаменим: он позволяет объединить метрики из разных кластеров Kubernetes в единое хранилище, обеспечивая мониторинг Kubernetes на десятые доли секунды.

Thanos Ruler: alerting на исторических данных

Thanos Ruler выполняет Prometheus recording и alerting rules, запрашивая данные через Querier. Это позволяет писать кросс-кластерные правила, которые недоступны в обычном Prometheus:

groups:
  - name: cross-cluster.rules
    rules:
      - alert: ClusterHighMemoryUsage
        expr: |
          avg by (cluster) ( node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes ) < 0.15
        for: 10m

Такой алерт срабатывает, когда средняя утилизация памяти во всём кластере падает ниже 15%. В Prometheus для этого пришлось бы запускать отдельный запрос к каждому инстансу.