GH GambleHub

Конвеєри логів: 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 за розміром/часом.

ILM (hot/warm/cold/frozen):
  • 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) Продуктивність і тюнінг

ELK:
  • JVM heap 50% RAM (але ≤ ~ 30-32 ГБ на ноду), page cache важливий.
  • Розумний rollover (по 20-50 ГБ/шард),'refresh _ interval'↑ для ingest-індексів.
  • У Logstash уникати «важких» grok; по можливості JSON-логування на джерелі.
Loki:
  • Правильний лейбл-сет - ключ до швидкості.
  • Великі чанки → дешевше зберігання, але дорожче пам'ять у 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?

Contact

Зв’яжіться з нами

Звертайтеся з будь-яких питань або за підтримкою.Ми завжди готові допомогти!

Telegram
@Gamble_GC
Розпочати інтеграцію

Email — обов’язковий. Telegram або WhatsApp — за бажанням.

Ваше ім’я необов’язково
Email необов’язково
Тема необов’язково
Повідомлення необов’язково
Telegram необов’язково
@
Якщо ви вкажете Telegram — ми відповімо й там, додатково до Email.
WhatsApp необов’язково
Формат: +код країни та номер (наприклад, +380XXXXXXXXX).

Натискаючи кнопку, ви погоджуєтесь на обробку даних.