Масштабований моніторинг через 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 для цього довелося б запускати окремий запит до кожного інстансу.