50 микросервисов и ни одного лога: внедряем Grafana Loki для стримингового сервиса

Прежде чем приступить к внедрению, наши инженеры подготовили сравнительный анализ двух систем для конкретного кейса клиента:

Для стримингового сервиса, где нужно быстро фильтровать логи по сервису и уровню ошибки, а не искать произвольный текст в миллионах строк, Loki подходил идеально. Решение утвердили за 2 дня.

Мы спроектировали следующую архитектуру:

• Promtail — агент сбора логов, развёрнутый как DaemonSet на каждой ноде Kubernetes
• Grafana Loki — бэкенд в режиме Simple Scalable (read + write + backend), развёрнутый через Helm
• MinIO — S3-совместимое хранилище для чанков и индексов (у клиента уже был кластер)
• Grafana — визуализация, дашборды, алертинг

Весь стек был развёрнут внутри того же Kubernetes-кластера, что минимизировало latency между Promtail и Loki.

# Создаём выделенный namespace для стека мониторинга
kubectl create namespace monitoring

# Добавляем Helm-репозиторий Grafana
helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

# Проверяем доступные версии чарта
helm search repo grafana/loki --versions | head -10

На момент внедрения актуальной была версия чарта 6.6.2 с Loki 3.0.

Наши инженеры подготовили кастомный values.yaml с учётом нагрузки клиента — 50 сервисов генерировали около 15 ГБ логов в сутки:

# values-loki.yaml
loki:
  schemaConfig:
    configs:
      - from: 2024-04-01
        store: tsdb
        object_store: s3
        schema: v13
        index:
          prefix: loki_index_
          period: 24h
  storage:
    type: s3
    s3:
      endpoint: minio.storage.svc.cluster.local:9000
      bucketnames: loki-chunks
      access_key_id: ${MINIO_ACCESS_KEY}
      secret_access_key: ${MINIO_SECRET_KEY}
      s3ForcePathStyle: true
      insecure: true
  commonConfig:
    replication_factor: 2
  limits_config:
    ingestion_rate_mb: 16
    ingestion_burst_size_mb: 32
    max_entries_limit_per_query: 10000
    retention_period: 720h   # 30 дней
  compactor:
    retention_enabled: true
    retention_delete_delay: 2h
    compaction_interval: 10m

write:
  replicas: 2
  resources:
    requests:
      cpu: 500m
      memory: 1Gi
    limits:
      cpu: "2"
      memory: 4Gi
  persistence:
    size: 20Gi
    storageClass: fast-ssd

read:
  replicas: 2
  resources:
    requests:
      cpu: 500m
      memory: 1Gi
    limits:
      cpu: "2"
      memory: 4Gi

backend:
  replicas: 1
  resources:
    requests:
      cpu: 250m
      memory: 512Mi
    limits:
      cpu: "1"
      memory: 2Gi

gateway:
  replicas: 2
  ingress:
    enabled: true
    hosts:
      - host: loki.internal.streamvibe.ru
        paths:
          - path: /
            pathType: Prefix

Ключевые параметры, которые мы настроили:

• schema v13 + TSDB store — новейший формат хранения, на 40% эффективнее по дисковому вводу/выводу по сравнению с boltdb-shipper
• replication_factor: 2 — каждый чанк хранится в двух экземплярах для отказоустойчивости
• retention_period: 720h — автоматическое удаление логов старше 30 дней
• ingestion_rate_mb: 16 — ограничение скорости приёма для защиты от лог-штормов

# Деплой Loki
helm upgrade --install loki grafana/loki \
  -n monitoring \
  -f values-loki.yaml \
  --version 6.6.2

# Проверяем статус подов
kubectl -n monitoring get pods -l app.kubernetes.io/name=loki

# Ожидаемый вывод:
# NAME                           READY   STATUS    RESTARTS   AGE
# loki-backend-0                 1/1     Running   0          2m
# loki-read-0                    1/1     Running   0          2m
# loki-read-1                    1/1     Running   0          2m
# loki-write-0                   1/1     Running   0          2m
# loki-write-1                   1/1     Running   0          2m
# loki-gateway-7d8f9b6c4-x2k9l  1/1     Running   0          2m
# loki-gateway-7d8f9b6c4-m4n7p  1/1     Running   0          2m

# Проверяем health-эндпоинт
kubectl -n monitoring port-forward svc/loki-gateway 3100:80 &
curl -s http://localhost:3100/ready
# ready

# values-promtail.yaml
config:
  clients:
    - url: http://loki-gateway.monitoring.svc.cluster.local/loki/api/v1/push
      tenant_id: streamvibe
      batchwait: 1s
      batchsize: 1048576  # 1 МБ
  snippets:
    pipelineStages:
      - cri: {}
      - multiline:
          firstline: '^\d{4}-\d{2}-\d{2}|^\[\d{4}|^{"timestamp"'
          max_wait_time: 3s
          max_lines: 128
      - json:
          expressions:
            level: level
            service: service
            trace_id: trace_id
      - labels:
          level:
          service:
      - timestamp:
          source: timestamp
          format: RFC3339Nano
      - output:
          source: message

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 256Mi

tolerations:
  - effect: NoSchedule
    operator: Exists

# Деплой Promtail
helm upgrade --install promtail grafana/promtail \
  -n monitoring \
  -f values-promtail.yaml \
  --version 6.16.4

# Проверяем, что Promtail запущен на всех нодах
kubectl -n monitoring get pods -l app.kubernetes.io/name=promtail -o wide

# Проверяем targets — какие контейнеры обнаружены
kubectl -n monitoring port-forward ds/promtail 3101:3101 &
curl -s http://localhost:3101/targets | jq '.[] | length'
# 127  (все контейнеры всех подов на ноде)

Микросервисы StreamVibe использовали структурированный JSON-формат логирования. Пример строки лога из сервиса транскодера:

{"timestamp":"2026-02-15T14:32:01.443Z","level":"error","service":"transcoder","trace_id":"abc123def456","message":"FFmpeg process exited with code 137","video_id":"v-98234","codec":"h265","duration_ms":45200}

Наши pipeline stages выполняли следующую обработку:

1. cri — парсинг CRI-формата контейнерных логов (Kubernetes оборачивает каждую строку в свой формат)
2. multiline — склейка многострочных стектрейсов в одну запись
3. json — извлечение полей level, service, trace_id из JSON
4. labels — промоутинг level и service в labels Loki для быстрой фильтрации
5. timestamp — использование таймстампа из лога вместо времени приёма
6. output — поле message становится основным текстом лог-записи

Такая обработка позволяла Loki индексировать логи по labels {namespace="production", pod="transcoder-7b8c9d-x2k", level="error", service="transcoder"}, а полнотекстовый поиск использовать только при необходимости.

Помимо парсинга содержимого, Promtail автоматически обогащает каждую запись метаданными Kubernetes через service discovery. Мы дополнительно настроили relabeling для удобства фильтрации:

# Дополнение к values-promtail.yaml
config:
  snippets:
    extraRelabelConfigs:
      # Добавляем label с именем deployment
      - source_labels: [__meta_kubernetes_pod_label_app]
        target_label: app
      # Добавляем label с версией
      - source_labels: [__meta_kubernetes_pod_label_version]
        target_label: version
      # Отбрасываем системные контейнеры istio-proxy
      - source_labels: [__meta_kubernetes_container_name]
        regex: istio-proxy
        action: drop

Это позволило фильтровать логи по деплойменту и версии приложения, а также исключить шумные sidecar-контейнеры сервисной сетки.

# Все ошибки транскодера за последний час
{namespace="production", service="transcoder", level="error"}

# Поиск по конкретному видео ID
{namespace="production", service="transcoder"} |= "v-98234"

# Regex-поиск: все HTTP-ошибки 5xx в API-gateway
{namespace="production", app="api-gateway"} |~ "HTTP/1.1\" 5[0-9]{2}"

# Исключение шумных health-check логов
{namespace="production", app="api-gateway"} != "/healthz" != "/readyz"

# Поиск по trace_id для сквозной трассировки
{namespace="production"} |= "abc123def456"

Важная особенность LogQL: сначала Loki фильтрует по labels (это мгновенно, так как labels индексированы), а затем применяет текстовые фильтры к содержимому. Поэтому чем точнее labels, тем быстрее запрос.

# Частота ошибок по сервисам за последние 5 минут (errors per second)
sum by(service) (
  rate({namespace="production", level="error"} [5m])
)

# Топ-5 самых шумных сервисов (строк логов в секунду)
topk(5,
  sum by(app) (
    rate({namespace="production"} [5m])
  )
)

# Процент ошибок от общего числа записей для биллинга
sum(rate({service="billing", level="error"} [15m]))
/
sum(rate({service="billing"} [15m]))
* 100

# Количество уникальных ошибок за час (по первым 100 символам)
count_over_time(
  {namespace="production", level="error"}
    | line_format "{{.message | trunc 100}}"
  [1h]
)

Эти запросы стали основой для дашбордов и алертов, о которых мы расскажем далее.

# Извлечение поля duration_ms из JSON и фильтрация медленных операций
{service="transcoder"}
  | json
  | duration_ms > 30000
  | line_format "video={{.video_id}} codec={{.codec}} duration={{.duration_ms}}ms"

# Статистика по кодекам: среднее время транскодирования
avg by(codec) (
  {service="transcoder"}
    | json
    | unwrap duration_ms [5m]
)

# Подсчёт ошибок по HTTP-статусам
sum by(status) (
  count_over_time(
    {app="api-gateway"}
      | json
      | status >= 400
    [1h]
  )
)

JSON-парсинг выполняется в query-time, что медленнее, чем pre-indexed labels, но позволяет анализировать любые поля без изменения конфигурации Promtail.

Основной дашборд включал следующие панели:

• Error Rate Heatmap — тепловая карта частоты ошибок по сервисам, позволяющая мгновенно увидеть аномалии
• Log Volume — общий объём логов по уровням (info/warn/error/fatal)
• Top Errors — таблица с самыми частыми ошибками за последний час
• Deployment Events — аннотации на графиках с моментами деплоев

Пример JSON-модели панели Error Rate:

{
  "type": "timeseries",
  "title": "Error Rate by Service",
  "datasource": { "type": "loki", "uid": "loki-ds" },
  "targets": [
    {
      "expr": "sum by(service) (rate({namespace=\"production\", level=\"error\"} [$__interval]))",
      "legendFormat": "{{service}}"
    }
  ],
  "fieldConfig": {
    "defaults": {
      "unit": "reqps",
      "thresholds": {
        "steps": [
          { "color": "green", "value": null },
          { "color": "yellow", "value": 0.5 },
          { "color": "red", "value": 2 }
        ]
      }
    }
  }
}

Для удобства on-call инженеров мы создали интерактивный дашборд с переменными:

• $service — выпадающий список сервисов (автозаполнение из labels Loki)
• $level — уровень логирования
• $search — произвольный текстовый поиск
• $trace_id — для сквозного поиска по trace ID

Определение переменных в Grafana:

# Variable: service (type: Query)
# Data source: Loki
# Query: label_values({namespace="production"}, service)
# Refresh: On Dashboard Load

# Variable: search (type: Text box)
# Default: (empty)

# Variable: trace_id (type: Text box)
# Default: (empty)

Основная панель с логами использовала динамический LogQL-запрос:

{namespace="production", service=~"$service", level=~"$level"}
  |= "$search"
  |= "$trace_id"

Инженер мог выбрать сервис, уровень, ввести поисковую строку — и мгновенно увидеть отфильтрованный поток логов с возможностью раскрыть каждую запись для просмотра полного JSON.

Отдельный дашборд отслеживал состояние компонентов Loki — чтобы система мониторинга сама не стала слепым пятном:

# Задержка приёма логов (ingestion lag)
histogram_quantile(0.99,
  sum by(le) (
    rate(loki_distributor_ingester_append_latency_seconds_bucket[5m])
  )
)

# Скорость записи чанков в S3
sum(rate(loki_ingester_chunks_flushed_total[5m]))

# Ошибки записи
sum by(reason) (
  rate(loki_ingester_chunks_flush_failures_total[5m])
)

# Использование памяти ingester-ами
sum by(pod) (
  container_memory_working_set_bytes{namespace="monitoring", container="loki"}
) / 1024 / 1024 / 1024

Мы создали набор alert rules прямо в Grafana (начиная с версии 9.x Grafana имеет встроенную систему алертинга):

# grafana-alerts.yaml (provisioning)
apiVersion: 1
groups:
  - orgId: 1
    name: StreamVibe Production Alerts
    folder: Production
    interval: 1m
    rules:
      - uid: error-rate-spike
        title: "High Error Rate"
        condition: C
        data:
          - refId: A
            datasourceUid: loki-ds
            model:
              expr: |
                sum by(service) (
                  rate({namespace="production", level="error"} [5m])
                )
          - refId: B
            datasourceUid: __expr__
            model:
              type: reduce
              reducer: max
              expression: A
          - refId: C
            datasourceUid: __expr__
            model:
              type: threshold
              expression: B
              conditions:
                - evaluator:
                    type: gt
                    params: [5]
        for: 3m
        labels:
          severity: critical
        annotations:
          summary: "Error rate > 5/sec in {{ $labels.service }}"
          description: "Service {{ $labels.service }} has error rate {{ $values.B }} errors/sec for 3+ minutes"

      - uid: log-volume-drop
        title: "Log Volume Drop (possible outage)"
        condition: C
        data:
          - refId: A
            datasourceUid: loki-ds
            model:
              expr: |
                sum(rate({namespace="production"} [5m]))
          - refId: B
            datasourceUid: __expr__
            model:
              type: reduce
              reducer: last
              expression: A
          - refId: C
            datasourceUid: __expr__
            model:
              type: threshold
              expression: B
              conditions:
                - evaluator:
                    type: lt
                    params: [10]
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Log volume dropped below 10 lines/sec"
          description: "Total log ingest rate is {{ $values.B }}/sec — possible service outage"

Для routing алертов мы настроили два канала:

# grafana-contact-points.yaml
apiVersion: 1
contactPoints:
  - orgId: 1
    name: telegram-oncall
    receivers:
      - uid: telegram-1
        type: telegram
        settings:
          bottoken: "$TELEGRAM_BOT_TOKEN"
          chatid: "-1001234567890"
          parse_mode: HTML
          message: |
            🔥 {{ .CommonLabels.alertname }}
            Severity: {{ .CommonLabels.severity }}
            Service: {{ .CommonLabels.service }}
            {{ .CommonAnnotations.description }}
  - orgId: 1
    name: pagerduty-critical
    receivers:
      - uid: pd-1
        type: pagerduty
        settings:
          integrationKey: "$PAGERDUTY_KEY"
          severity: "{{ .CommonLabels.severity }}"

# grafana-notification-policies.yaml
apiVersion: 1
policies:
  - orgId: 1
    receiver: telegram-oncall
    group_by: ["alertname", "service"]
    group_wait: 30s
    group_interval: 5m
    repeat_interval: 4h
    routes:
      - receiver: pagerduty-critical
        matchers:
          - severity = critical
        continue: true

Логика маршрутизации: все алерты идут в Telegram-чат дежурной команды. Критические — дополнительно в PagerDuty для автоматического вызова on-call инженера.

# Дополнение к loki config (values-loki.yaml)
loki:
  limits_config:
    retention_period: 720h  # 30 дней по умолчанию
    per_stream_rate_limit: 5MB
    per_stream_rate_limit_burst: 15MB
  compactor:
    retention_enabled: true
    retention_delete_delay: 2h
    delete_request_store: s3
  overrides:
    # Для tenant "streamvibe" кастомные лимиты
    streamvibe:
      retention_period: 720h
      retention_stream:
        - selector: '{level="debug"}'
          priority: 1
          period: 72h        # Debug-логи: 3 дня
        - selector: '{level="info"}'
          priority: 2
          period: 168h       # Info: 7 дней
        - selector: '{level="error"}'
          priority: 3
          period: 2160h      # Ошибки: 90 дней
        - selector: '{service="billing"}'
          priority: 4
          period: 4320h      # Биллинг: 180 дней (compliance)

Такая стратегия позволила сократить объём хранилища на 60% — debug-логи (составлявшие 70% объёма) удалялись через 3 дня, а критически важные ошибки биллинга хранились полгода для аудита.

Для контроля за ростом хранилища мы добавили метрики в дашборд Loki Health:

# Общий объём данных в S3
sum(loki_store_series_total)

# Скорость роста хранилища (ГБ/день)
sum(increase(loki_ingester_bytes_received_total[24h])) / 1024 / 1024 / 1024

# Эффективность компактора: удалено чанков
sum(increase(loki_compactor_deleted_series_total[24h]))

Дополнительно мы настроили алерт на случай, если хранилище MinIO заполнится более чем на 80%, с автоматическим уведомлением в Telegram инфраструктурной команды.