Конвейеры логов: ELK и Loki

1) Зачем и когда: цели логирования

Наблюдаемость и RCA: ускорение дебага, пост-мортем, SLO/SLA контроль.
Безопасность и аудит: следы доступа, аномалии, расследования.
Бизнес-метрики: конверсия, платежные флоу, ошибки PSP, поведение пользователей.
Комплаенс: хранение, маскирование PII, политики ретеншна, Legal Hold.

Типы логов: приложенческие, инфраструктурные (kubelet, kube-proxy, CNI, ingress), сетевые, аудитные, платежные, веб-события, Nginx/Envoy, БД.

2) Высокоуровневые архитектуры

Вариант A: ELK

Producers → Logshipper (Filebeat/Fluent Bit/Vector) → Logstash/Beats input → Elasticsearch → Kibana/Алертинг

Вариант B: Loki

Producers → Promtail/Fluent Bit → Loki distributor/ingester/querier → Grafana/Алертинг

Гибрид

ELK для поиска по полнотексту/фасетам, Loki для дешевого масштабируемого хранения и быстрых греп-подобных запросов; кореляция с метриками/трассами в Grafana.

3) Поток данных и уровни обработки

1. Сбор: побайтный tail файлов, journald, syslog, stdout контейнеров, HTTP.
2. Обогащение: timestamp нормализация, host/pod/namespace, env (prod/stage), release, commit SHA, trace/span id.
3. Парсинг: JSON → flat fields; grok/regex; Nginx/Envoy форматы; платежные схемы (коды ошибок PSP).
4. Фильтрация/редакция: вырезать PII (PAN, CVV, e-mail, адреса), секреты, токены.
5. Роутинг: по tenant/service/лог-уровню; hot/warm/cold; в S3/объектное хранилище.
6. Хранение и ретеншн: политика TTL по классам данных.
7. Доступ/Аналитика/Алерты.

4) ELK: ключевые решения

4.1 Logstash/Beats

Используйте Beats/Fluent Bit на нодах для легкого сборщика, Logstash — как центральный ETL (grok, dissect, mutate, geoip, translate).
Пулы Logstash: ingest-ETL, security-ETL, payments-ETL — для изоляции нагрузок.

4.2 Elasticsearch

Шардирование: ориентируйтесь на ~20–50 ГБ на шард; избегайте «шард-взрыва».
Стратегия индексов: `logs-<tenant>-<service>-YYYY.MM.DD` или дата-стримы; rollover по размеру/времени.

• hot: SSD, 1–7 дней; warm: HDD, 7–30 дней; cold: объемное; frozen: минимальная стоимость с более медленным доступом.
• Мэппинги: жестко типизируйте поля, ограничивайте `fielddata` и создание динамических полей.
• Кэш и запросы: фильтры по keyword-полям, агрегаты — аккуратно; pin-to-hot для высокочастотного поиска.

4.3 Kibana

Пространства (Spaces) для мульти-тенантности.
Saved searches, Lens/TSVB, threshold/метрик-алерты.
RBAC по индекс-паттернам (`logs-tenant-`).

5) Loki: ключевые решения

5.1 Модель лейблов

Лейблы — это «индекс» Loki. Используйте низкую кардинальность: `cluster`, `namespace`, `app`, `level`, `env`, `tenant`.
Поля с высокой кардинальностью (uid, request_id) — в строке; извлекайте при запросе через LogQL `|=`, `| json`, `| regexp`.

5.2 Компоненты

Promtail: сбор stdout, files, journald; парсеры (JSON, regex, cri).
Distributor/Ingester/Querier/Query-frontend: масштабирование по ролям; кэширование запросов.
Object storage (S3/GCS/MinIO) для долговременного хранения чанк-логов.

5.3 LogQL приемы

Быстрый grep: `{app="payments",level="error"} |= "declined"`

Парсинг JSON: `{app="api"} | json | code="5xx" | unwrap duration | avg()`

Корреляция с метриками: `rate({app="nginx"} |= "200" [5m])`

6) Сравнение ELK vs Loki (вкратце)

Поиск/агрегации: ELK сильнее для сложных полнотекстовых и фасетных запросов; Loki — grep-like, быстрый и дешевый.
Стоимость: Loki часто дешевле на больших объемах (объектное хранилище + меньший индекс).
Сложность эксплуатации: ELK требует дисциплины по индексам/ILM, Джаву-хипам; Loki — дисциплины по лейблам.
Корреляция с метриками/трассами: Loki естественно интегрируется с Grafana/OTel стеком; ELK тоже умеет, но чаще через интеграции.

7) Безопасность и комплаенс

PII-редакция на краю (shipper): маскируйте PAN, e-mail, телефон, адреса, токены.
TLS in-transit, mTLS между агентами и шинами.
RBAC: per-tenant индексы/лейблы; изоляция неймспейсов/пространств.
Secrets hygiene: переменные окружения без секретов, отдельные секрет-менеджеры.
Legal Hold: механизм заморозки сегментов/индексов; write-once для спорных периодов.
Удаление/ретеншн: политики TTL по классам данных (prod/stateful/платежи/аудит).
Аудит-трейлы доступа к логам.

8) Надежность и пропускная способность

Буферизация и backpressure: локальные файлы/диски у агентов; ретраи с экспоненциальным backoff.
Idempotency: поля `ingest_id`/`log_id` для избежания дублей при повторах.
HA: минимум 3 ноды для ES-мастеров/ингестеров Loki; antiaffinity по AZ.
Квоты и rate-limits по tenant/service; защита от «штормов» логирования.
Схема уровня логов: `ERROR` ограниченно, `DEBUG` только временно через динамические флаги.

9) Производительность и тюнинг

• JVM heap 50% RAM (но ≤ ~30–32 ГБ на ноду), page cache важен.
• Умный rollover (по 20–50 ГБ/шард), `refresh_interval` ↑ для ingest-индексов.
• В Logstash избегать «тяжелых» grok; по возможности JSON-логирование на источнике.

• Правильный лейбл-сет — ключ к скорости.
• Большие чанки → дешевле хранение, но дороже память у ingester; балансируйте.
• Query-frontend + кэш (мем/Redis) для повторных запросов.

10) ФинОпс для логов (стоимость)

Снижение кардинальности полей/лейблов.
Сэмплинг DEBUG и динамические «лог-свичи».
Ротация: короткий hot, длинный cold в объектное.
Дедупликация и консолидированные сообщения (batch).
Архивация редко используемых логов в дешевые классы хранения.
Дашборд стоимости: объем/дата-стримы/лейблы/индексы/тенанты.

11) Корреляция с метриками и трассами (Observability 3-в-1)

Trace-ID/Span-ID в каждый лог (middleware на API шлюзах и в сервисах).
OpenTelemetry: единый контекст; экспортеры в Tempo/Jaeger, метрики в Prometheus/Mimir, логи — в Loki/ELK.
Быстрые сценарии: «алерт по метрике → прыжок в соответствующие логи → прыжок в трассу».

12) Мульти-тенантность и изоляция

Namespace-based изоляция (K8s labels), отдельные индекс-паттерны/лейблы `tenant`.
Разделение алертов/дашбордов/ретеншна по тенанту.
Биллинг по потреблению: объем ingest, storage, запросы.

13) Мониторинг и SLO для самого конвейера

SLO ingest: «99.9% логов доставлено < X сек».
SLO поиска: «p95 запросов < Y сек».
Технические метрики: queue depth, dropped logs, reprocess rate, error rate парсеров, отказ ingester/ES нод.

14) Типовые схемы развертывания

Managed: Elasticsearch Service/Opensearch, Grafana Cloud Loki.
Self-hosted K8s: StatefulSets для ES/Loki, anti-affinity по AZ, PersistentVolumes, объектное хранилище.
Edge-агенты (приложения в регионах): локальный буфер + TLS канал на центральный ingest.

15) Примеры конфигураций

15.1 Promtail (K8s, CRI JSON)

yaml scrape_configs:
- job_name: kubernetes-pods kubernetes_sd_configs:
- role: pod pipeline_stages:
- cri: {}
- json:
expressions:
level: level msg: message trace: trace_id
- labels:
level:
app:
namespace:
- match:
selector: '{namespace="prod"}'
stages:
- regex:
expression: '(?P<pan>\b[0-9]{12,19}\b)'
- replace:
expression: '(?P<pan>\b[0-9]{12,19}\b)'
replace: '[REDACTED_PAN]'
relabel_configs:
- action: replace source_labels: [__meta_kubernetes_pod_label_app]
target_label: app
- action: replace source_labels: [__meta_kubernetes_namespace]
target_label: namespace
- action: replace source_labels: [__meta_kubernetes_pod_node_name]
target_label: node

15.2 Logstash (ingest и маскирование)

ruby input {
beats { port => 5044 }
}
filter {
json { source => "message" skip_on_invalid_json => true }
mutate { add_field => { "env" => "%{[kubernetes][labels][env]}" } }
PII mutate {
gsub => [
"message", "\b[0-9]{12,19}\b", "[REDACTED_PAN]",
"message", "(?i)(authorization: Bearer)([A-Za-z0-9\.\-_]+)", "\1[REDACTED_TOKEN]"
]
}
}
output {
elasticsearch {
hosts => ["https://es-hot-1:9200","https://es-hot-2:9200"]
index => "logs-%{[fields][tenant]}-%{[app]}-%{+YYYY. MM. dd}"
ilm_enabled => true ssl => true cacert => "/etc/ssl/certs/ca. crt"
user => "${ES_USER}"
password => "${ES_PASS}"
}
}

16) Алертинг и дашборды (шаблоны)

Ошибки API: `rate({app="api",level="error"}[5m]) > threshold` → PagerDuty/Telegram.
Всплеск 5xx в Nginx/Envoy; дроп ingest у агентов; рост latency поиска.

• Объем логов по сервисам/тенантам.
• Топ-паттерны ошибок (код/исключение/endpoint).
• Стоимость по ретеншну/классам хранилища.

17) Проверки качества (лог-QA)

Контракты логирования: формат JSON, обязательные поля (`ts`, `level`, `service`, `env`, `trace_id`, `msg`).
Линтер логов в CI: запрет новых полей с высокой кардинальностью без согласования.
Канареечные сервисы: генерация эталонных логов для раннего обнаружения регрессий.

18) Частые ошибки и анти-паттерны

Лейблы Loki с высокой кардинальностью (`user_id`, `request_id`) → взрыв памяти.
Динамические поля в ES без мэппингов → «взрыв индексов».
DEBUG в проде «навсегда». Включайте по флагам и с TTL.
Отсутствие PII-редакции.
Один общий «монолитный» конвейер для всего — лучше сегменты по доменам.

19) План внедрения (итерациями)

1. MVP: агенты + один пайплайн (приложения), базовые дашборды, PII-редакция.
2. Расширение: сетевые/инфра-логи, алерты SLO, кореляция с трассами.
3. ФинОпс: ретеншн-матрица, отчет стоимости, оптимизация лейблов/индексов.
4. Мульти-тенант: пространства, RBAC, биллинг по потреблению.
5. Надежность: HA, disaster-drills, Legal Hold.

20) Чек-лист запуска в прод

• JSON-формат и обязательные поля во всех сервисах.
• Маскирование PII на агенте/ingest.
• Политики ретеншна/ILM или bucket-lifecycle.
• RBAC/пространства/тенанты.
• SLO ingest/поиска и алерты.
• Канареечные логи и тестовый прогон нагрузкой.
• Дашборды стоимости и отчет по владельцам сервисов.
• Runbooks: «что делать, если ingest упал/поиск медленный/шарды красные».

21) Мини-FAQ

Что выбрать — ELK или Loki?