Централизованный сбор логов: настройка Grafana Loki с Promtail и Alloy

Настройка Grafana Loki для централизованных логов

Мы часто сталкивались с ситуацией, когда разработчики жалуются: «Логов нет, а те, что есть — в Elasticsearch, который жрёт 200 ГБ оперативы и стоит как космический корабль». Elasticsearch индексирует всё содержимое, что даёт гибкость поиска, но за это приходится платить железом. Grafana Loki предлагает другой подход: индексируем только метаданные (labels), а текст храним сжатым в S3. Это реально сокращает затраты в 3–5 раз при объёмах от 100 ГБ/сутки. По нашим оценкам, переход на Loki позволяет сократить затраты на хранение логов на 60–70% по сравнению с Elasticsearch.

Почему LogQL — ключевой инструмент для анализа логов?

LogQL — язык запросов Loki, делящийся на два типа: stream selectors (фильтрация по labels) и pipeline (обработка содержимого). Pipeline может содержать операции json, logfmt, regexp, line_format, а также функции агрегации, как в PromQL. Например, метрика ошибок по сервисам:

// Stream selector + filter
{namespace="production", app="payment-service"} |= "error"

// Pipeline с JSON-парсингом и форматированием
{app="api-gateway"} | json | status_code >= 500 | line_format "{{.method}} {{.path}} → {{.status_code}} ({{.duration_ms}}ms)"

// Metric query — rate ошибок по сервисам
sum by (app) ( rate( {namespace="production"} | json | status_code >= 500 [5m] ) )

Этот запрос можно использовать в Grafana как alert rule — точно так же, как Prometheus метрику. LogQL metric queries позволяют строить SLO и error budget на основе логов.

Как правильно настроить лейблинг и избежать кардинальности?

Loki индексирует только labels, не содержимое логов. Высокая кардинальность labels убивает производительность — каждая уникальная комбинация labels создаёт отдельный stream. Запрещённые паттерны:

# ПЛОХО — trace_id в labels создаёт миллионы streams
labels:
  trace_id: "abc123def456..."

# ПЛОХО — user_id в labels
labels:
  user_id: "12345"

# ХОРОШО — только стабильные идентификаторы
labels:
  namespace: "production"
  app: "payment-service"
  pod: "payment-service-7d9f8b-xkqp2"
  level: "error"

trace_id должен быть в теле лога, а не в label. Для перехода из Loki в Jaeger — используйте derivedFields в Grafana datasource.

Шаги развёртывания Loki через Helm

1. Установите Helm 3, если ещё не установлен.
2. Добавьте репозиторий Grafana: helm repo add grafana https://grafana.github.io/helm-charts.
3. Создайте файл loki-values.yaml с конфигурацией S3, retention и масштабирования.
4. Выполните команду установки: helm upgrade --install loki grafana/loki --namespace logging --create-namespace -f loki-values.yaml.

Эти шаги подходят для режима SimpleScalable. Более сложные инсталляции требуют дополнительной настройки Kafka и Consul.

Архитектура развёртывания

Loki работает в нескольких режимах. Для большинства production случаев подходит simple-scalable через Helm:

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update
helm upgrade --install loki grafana/loki \
  --namespace logging \
  --create-namespace \
  -f loki-values.yaml

# loki-values.yaml
loki:
  auth_enabled: false
  commonConfig:
    replication_factor: 1
  storage:
    type: s3
    s3:
      endpoint: s3.eu-west-1.amazonaws.com
      region: eu-west-1
      bucketnames: my-loki-chunks
      access_key_id: ${AWS_ACCESS_KEY_ID}
      secret_access_key: ${AWS_SECRET_ACCESS_KEY}
      s3forcepathstyle: false
      insecure: false
  schemaConfig:
    configs:
      - from: "2020-01-01"
        store: tsdb
        object_store: s3
        schema: v13
        index:
          prefix: loki_index_
          period: 24h
  limits_config:
    ingestion_rate_mb: 64
    ingestion_burst_size_mb: 128
    max_query_parallelism: 32
    max_streams_per_user: 10000
    retention_period: 744h
    reject_old_samples: true
    reject_old_samples_max_age: 168h
  compactor:
    retention_enabled: true
deploymentMode: SimpleScalable
backend:
  replicas: 2
read:
  replicas: 2
write:
  replicas: 2
minio:
  enabled: false

Сравнение режимов развёртывания

SimpleScalable — оптимальный компромисс для нагрузок до 50 ГБ/сутки. В этом режиме компоненты (read, write, backend) разделены и могут масштабироваться независимо, но без лишней сложности microservices (кафка, консул). Для небольших команд это сокращает time-to-market и упрощает эксплуатацию.

Сравнение агентов сбора логов

Типичные ошибки при работе с Loki

• Высокая кардинальность labels — использование trace_id или user_id в качестве labels. Это убивает производительность. Всегда проверяйте вкладку «Series» в Grafana.
• Отсутствие retention policy — если не настроить compactor и retention, база данных логов будет расти бесконечно, вызывая переполнение хранилища.
• Single-binary в production — режим single-binary не поддерживает отказоустойчивость и масштабирование. Используйте SimpleScalable или Microservices.
• Игнорирование схемы индекса — с версии 13 используется store tsdb. Не используйте старые схемы (boltdb-shipper) без необходимости.

Что входит в работу по внедрению Loki

Мы предлагаем услугу под ключ:

• Аудит текущей инфраструктуры логирования (объёмы, источники, retention).
• Развёртывание Loki (режим SimpleScalable или Microservices) с Helm, настройка S3-хранилища.
• Установка и конфигурация Promtail/Alloy на всех хостах.
• Написание правил лейблинга и LogQL-запросов для ключевых метрик.
• Создание дашбордов в Grafana и алертов (SLI, error budget).
• Документация и обучение команды.

Опыт нашей команды — более 5 лет в DevOps, десятки внедрений Loki на проектах от стартапов до enterprise. Мы даём гарантию на стабильную работу системы и SLA на инциденты.

Свяжитесь с нами для аудита вашей инфраструктуры логирования — мы оценим объёмы и подберём оптимальную конфигурацию. Закажите внедрение Loki и сократите затраты на логирование без потери функциональности.