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 та скоротьте витрати на логування без втрати функціональності.