Масштабирование: создание платформы Prometheus + Loki производительностью 100 ТБ/день

Уроки масштабирования Prometheus и Loki для эффективной обработки 100 ТБ/день метрик и журналов

Масштабирование окружения для наблюдаемости до 100 ТБ/день требует тщательного планирования и постепенных улучшений. В этой статье рассматриваются десять методов с объяснениями, диаграммами ASCII и фрагментами кода, которые помогут спроектировать, развернуть и эксплуатировать высоконагруженный стек наблюдаемости Prometheus и Loki, обеспечивающий бесперебойную обработку метрик и логов даже при большой нагрузке.

Введение

Сбор сотен миллионов метрик и миллиардов строк логов в день — задача не для слабонервных. В этой статье вы узнаете, как создать отказоустойчивую и экономичную платформу Prometheus + Loki, которая без проблем справится с нагрузкой 100 ТБ в день. Вы узнаете о методах хранения, обработки данных, производительности запросов, мониторинга ресурсов (задержки, памяти, диска, процессора) и изоляции сбоев.

1. Распределение приема данных на граничных узлах

Вместо того чтобы направлять весь трафик через один шлюз, распределите входящие метрики и логи по нескольким узлам приема.

Client → [ Ingest-A ] →|
         [ Ingest-B ] →|→ [ Distributor ]
         [ Ingest-C ] →|

Каждый граничный узел обрабатывает подмножество тенантов или источников, снижая нагрузку на конечные узлы.
Совет: используйте метки обнаружения сервисов для маршрутизации экземпляров приложений в один и тот же сегмент.

2. Используйте удаленную запись с горизонтальным Prometheus

Разверните множество экземпляров Prometheus, которые собирают данные с локальных служб, а затем выполните удаленную запись в централизованный кластер приемников.

# prometheus.yaml snippet
remote_write:
  - url: https://prom-recv.example.com/api/v1/write
    queue_config:
      max_samples_per_send: 5000
      capacity: 25000

Такая схема изолирует всплески данных и обеспечивает устойчивость центрального хранилища.

3. Создайте надежное хранилище TSDB

При нагрузке 100 ТБ/день локальные диски не справятся. Используйте объектное хранилище (S3, GCS) для долгосрочного хранения данных в базе данных Prometheus TSDB.

+-----------+     +------+     +--------+
| Prom-TSDB |<--->| Minio|<--->|  S3   |
+-----------+     +------+     +--------+

Включите автоматическую выгрузку фрагментов данных блоками Thanos или Cortex.

4. Оптимизируйте настройки фрагментов и индексов.

Настройте длительность блоков Prometheus TSDB и размеры кэша индексов, чтобы сбалансировать пропускную способность записи и скорость запросов.

# prom-override.yaml
storage.tsdb:
  min-block-duration: 2h
  max-block-duration: 6h
  retention: 30d
  wal-compression: true

Более короткие блоки уменьшают скачки уплотнения; сжатие WAL экономят диск и снижают нагрузку на сеть.

5. Масштабируйте прием в Loki с помощью дистрибьютора/инжестера

Микросервисы Loki — Distributor, Ingester, Querier — масштабируются горизонтально. Настраивайте маршрутизацию на основе тенантов или меток для распределения записи.

+--------+    +------------+    +----------+
| Loki → |→→→ | Distributor|→→→ | Ingester |
| Client |    +------------+    +----------+
           label-based → node

6. Управление жизненным циклом и сохранением фрагментов данных

Loki сохраняет фрагменты логов на локальном диске перед отправкой в ​​объектное хранилище. Настраивайте сжатие и хранение разумно.

schema_config:
  configs:
    - from: 2025-01-01
      store: boltdb-shipper
      object_store: s3
      schema: v11
      index:
        prefix: index_
        period: 24h

Ежедневно производите ротацию и очистку старых индексных таблиц, чтобы минимизировать накладные расходы на запросы.

7. Настройте запросы и ограничьте большие рабочие нагрузки

Запросы с большим диапазоном значений могут перегрузить систему. Установите ограничения по времени, количеству результатов и размеру очереди.

# loki-config.yaml
limits_config:
  max_query_length: 30m
  max_entries_limit: 100000
  split_queries_by_interval: 15m

Совет: поощряйте пользователей использовать {app="foo"} | json конвейеры вместо неограниченных запросов.

8. Мониторинг состояния платформы (задержка, память, диск, процессор)

Отслеживайте показатели ресурсов для каждого компонента. Примеры оповещений Prometheus:

# Alert: High write latency
- alert: PrometheusWriteLatencyHigh
  expr: histogram_quantile(0.95, rate(prometheus_tsdb_head_samples_appended_total[5m])) > 0.005
  for: 5m

[Grafana Dashboard]
Latency: p50/p95 write, query durations
Memory: heap_usage_bytes
Disk: disk_io_time_seconds_total
CPU: process_cpu_seconds_total

9. Реализуйте логику буферизации и повторных попыток

Если конечные точки remote_write работают медленно, настройте буферизацию и повторные попытки отправки, чтобы избежать потери данных.

// Go pseudocode using promclient
buf := make([]MetricSample, 0, 5000)
for sample := range ch {
    buf = append(buf, sample)
    if len(buf) >= 5000 {
        for retry := 0; retry < 3; retry++ {
            err := client.Push(buf)
            if err == nil { break }
            time.Sleep(time.Second * time.Duration(retry+1))
        }
        buf = buf[:0]
    }
}

Дистрибьютор Loki также поддерживает -distributor.replication-factor и настройки повторных попыток.

10. Автоматизируйте масштабирование и планирование мощностей

Используйте Horizontal Pod Autoscalers (HPA) на уровне CPU, памяти или пользовательских метрик Prometheus (например, длины очереди) для автоматического масштабирования каждой службы.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: prom-recv-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: prom-recv
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
  minReplicas: 3
  maxReplicas: 15

Комбинируйте инструменты прогнозирования (Kube-cost, Goldilocks) для масштабирования с учетом бюджета.

Заключение

Создание платформы наблюдения с производительностью 100 ТБ/день — это декомпозиция: захват фрагментов, разгрузка хранилища, настройка сжатия и обеспечение соблюдения ограничений. Следуя этим десяти практикам — шардирование, remote_write, хранилище долговременных объектов, настройке фрагментов, масштабированию микросервисов, политикам хранения, регулированию запросов, мониторингу работоспособности, буферизации и автоматическому масштабированию — вы обеспечите надёжный сбор метрик и логов в космических объёмах.