Централізація логів

1) Навіщо централізувати логи

• прискорюють пошук коренів інцидентів (кореляція за request-id/trace-id);
• дозволяють будувати сигнальні алерти на симптомах (помилки, аномалії);
• дають аудит-слід (хто/коли/що зробив);
• знижують вартість за рахунок уніфікації ретенції і зберігання.

2) Базові принципи

1. Тільки структуровані логи (JSON/RFC5424) - ніяких «free-text» без ключів.
2. Єдина схема ключів: `ts, level, service, env, region, tenant, trace_id, span_id, request_id, user_id(masked), msg, kv…`.
3. Типова кореляція: прокидайте trace_id з gateway в бекенди і в логи.
4. Мінімум шуму: коректні рівні, семплінг, дедуплікація повторів.
5. Безпека by design: PII-маскування, RBAC/ABAC, незмінюваність.
6. Економіка: hot/warm/cold, стиснення, агрегації, TTL і rehydration.

3) Типові архітектури

EFK/ELK: (Fluent Bit/Fluentd/Filebeat) → (Kafka — опц.) → (Elasticsearch/OpenSearch) → (Kibana/OpenSearch Dashboards). Універсальний пошук і агрегації.
Loki-подібні (лог-індексація за мітками): Promtail/Fluent Bit → Loki → Grafana. Дешевше для великих обсягів, потужний label-фільтр + лінійний перегляд.
Хмари: CloudWatch/Cloud Logging/Log Analytics + експорт в холодне сховище (S3/GCS/ADLS) і/або в SIEM.
Data Lake підхід: шипери → об'єктне сховище (parquet/iceberg) → дешеві аналітичні запити (Athena/BigQuery/Spark) + онлайновий шар (OpenSearch/Loki) для останніх N днів.

Рекомендація: для прод-онколла тримати онлайновий шар (7-14 днів hot) і архівний (місяці/роки) в lake з можливістю rehydrate.

4) Схема і формат логів (рекомендація)

json
{
"ts":"2025-11-01T13:45:12.345Z",
"level":"ERROR",
"service":"payments-api",
"env":"prod",
"region":"eu-central",
"tenant":"tr",
"trace_id":"0af7651916cd43dd8448eb211c80319c",
"span_id":"b7ad6b7169203331",
"request_id":"r-7f2c",
"user_id":"",        // masked
"route":"/v1/payments/charge",
"code":"PSP_TIMEOUT",
"latency_ms":1200,
"msg":"upstream PSP timeout",
"kv":{"provider":"psp-a","attempt":2,"timeout_ms":800}
}

Стандарти: RFC3339 для часу, level з набору'TRACE/DEBUG/INFO/WARN/ERROR/FATAL', ключі в snake_case.

5) Рівні логування та семплінг

DEBUG - тільки в dev/stage; в prod по прапору і з TTL.
INFO - життєвий цикл запитів/подій.
WARN - підозрілі ситуації без впливу на SLO.
ERROR/FATAL - вплив на запит/користувача.

• rate-limit для повторюваних помилок (наприклад, 1/сек/ключ).
• tail-семплінг трас (залишати повні логи/трейси тільки для «поганих» запитів).
• динамічний: при штормі помилок знижувати деталізацію, зберігати зведені.

6) Доставка логів (агенти і шипери)

На вузлі: Fluent Bit/Filebeat/Promtail збирають stdout файлів/джурналів, роблять парсинг, маскування, буферизацію.
Мережеві черги: Kafka/NATS для згладжування піків, ретраїв і впорядкування.
Надійність: backpressure, дискові буфери, підтвердження доставок (at-least-once), ідемпотентні індекси (ключ-хеш).
Фільтрація на краю: відкидання «балаканини» і секретів до потрапляння в мережу.

7) Індексація та зберігання

Партіонування за часом (daily/weekly) + за'env/region/tenant'( через індекс-шаблони або лейбли).

• Hot (SSD, 3-14 днів): швидкий пошук і алерти.
• Warm (HDD/морозилка, 30-90 днів): іноді шукаємо.
• Cold/Archive (об'єктне, місяці/роки): комплаєнс і рідкісні розслідування.
• Стиснення та ротації: ILM/ISM (політики життєвого циклу), gzip/zstd, downsampling (агрегаційні таблиці).
• Rehydration: тимчасове підвантаження архівних партій в «гарячий» кластер для розслідування.

8) Пошук і аналітика: типові запити

Інцидент: фільтр за часом ×'service =...'×'level> = ERROR'×'trace _ id '/' request _ id'.
Провайдери: `code:PSP_` и `kv. provider:psp-a'з угрупованням по регіону.
Аномалії: зростання частоти повідомлень або зміна розподілів полів (ML-детектори, rule-based).
Аудит: `category:audit'+'actor '/' resource'+ результат.

9) Кореляція з метриками і трасуваннями

Однакові ідентифікатори: 'trace _ id/span _ id'у всіх трьох сигналах (метрики, логи, трейси).
Лінки з графіків: клікабельний перехід з панелі p99 до логів по'trace _ id'.
Анотації релізів: версії/канарки в метриках і логах для швидкої прив'язки.

10) Безпека, PII і комплаєнс

Класифікація полів: PII/секрети/фінанси - маскувати або видаляти на вході (Fluent Bit/Lua-фільтри, Re2).
RBAC/ABAC: доступ до індексів/лейблів за ролями, row-/field-level-security.
Незмінюваність (WORM/append-only) для аудиту та вимог регуляторів.
Ретенція і «право на забуття»: TTL/видалення по ключах, токенізація'user _ id'.
Підписи/хеші: цілісність критичних журналів (адмін-дії, платежі).

11) SLO і метрики пайплайна логів

Доставка: 99. 9% подій в hot-шар ≤ 30-60 сек.
Втрати: < 0. 01% на відрізку 24 год (за контрольними мітками).
Доступність пошуку: ≥ 99. 9% за 28 днів.
Латентність запитів: p95 ≤ 2-5 сек на типових фільтрах.
Вартість: $/1М подій і $/зберігання/ГБ в розрізі шарів.

12) Дашборди (мінімум)

Здоров'я пайплайна: вхід/вихід шипперів, ретраї, заповнення буферів, лаг Kafka.
Помилки за сервісами/кодами: топ-N, тренди, перцентили'latency _ ms'.
Аудит-активність: адмін-дії, провайдерські помилки, доступи.
Економіка: обсяг/день, індекс-приріст, вартість по шарах, «дорогі» запити.

13) Операції та плейбуки

Шторм логів: включити агресивний семплінг/rate-limit на агенті, підняти буфери, тимчасово перевести частину потоку в warm.
Дрейф схеми: алерт на появу нових ключів/типів, запуск узгодження схем (schema-catalog).
Повільний пошук: перезбирання індексів, збільшення реплік, аналіз «важких» запитів, архівування старих партій.
Інцидент безпеки: негайне включення незмінності, вивантаження артефактів, обмеження доступу за ролями, RCA.

14) FinOps: як не розоритися на логах

Приберіть вербозність: перетворіть багаторядкові stacktrace в поле'stack'і семплюйте повтори.
Увімкніть TTL: різний для'env '/' level '/' category'.
Використовуйте Loki/архів + on-demand rehydrate для рідкісного доступу.
Партії та стиснення: великі партії дешевше, але стежте за SLA пошуку.
Матеріалізуйте часті аналітичні звіти (щоденні агрегати).

15) Інструментальні приклади

Fluent Bit (маскування і відправка в OpenSearch)

ini
[INPUT]
Name       tail
Path       /var/log/app/.log
Parser      json
Mem_Buf_Limit   256MB

[FILTER]
Name       modify
Match
Remove_key    credit_card, password

[OUTPUT]
Name       es
Host       opensearch.svc
Port       9200
Index       logs-${tag}-${date}
Logstash_Format  On
Suppress_Type_Name On

Nginx access log в JSON с trace_id

nginx log_format json escape=json '{ "ts":"$time_iso8601","remote":"$remote_addr",'
'"method":"$request_method","path":"$uri","status":$status,'
'"bytes":$body_bytes_sent,"ua":"$http_user_agent","trace_id":"$http_trace_id"}';
access_log /var/log/nginx/access.json json;

OpenSearch ILM політика (hot→warm→delete)

json
{
"policy": {
"phases": {
"hot":  { "actions": { "rollover": { "max_age": "7d", "max_size": "50gb" } } },
"warm": { "min_age": "7d", "actions": { "forcemerge": { "max_num_segments": 1 } } },
"delete":{ "min_age": "90d", "actions": { "delete": {} } }
}
}
}

16) Чек-лист впровадження

• Прийнята схема полів і рівні логів; включена кореляція trace/request-id.
• Налаштовані агенти (Fluent Bit/Promtail) з маскуванням і буферами.
• Вибраний онлайновий шар (OpenSearch/Loki/хмара) і архів (S3/GCS + parquet).
• Політики ретенції ILM/ISM + hot/warm/cold, rehydrate-процес.
• RBAC/ABAC, незмінність для аудиту, журнал доступу.
• Дашборди пайплайна, алерти на втрати/лаг/дискові буфери.
• Плейбуки: шторм логів, дрейф схеми, повільний пошук, security-інцидент.
• Фінансові ліміти: $/1М подій, квоти на «дорогі» запити.

17) Анти-патерни

Текстові логи без структури → неможливість фільтрувати і агрегувати.
Гігантські stacktrace в INFO → вибух об'єму.
Відсутність кореляції → «тремтіння» по всіх сервісах.
Зберігання «все назавжди» → рахунок за хмару як за літак.
Секрети/PII в логах → комплаєнс-ризики.
Ручні правки індексів в проді → дрейф і тривалі простої пошуку.

18) Підсумок

Централізація логів - це система, а не просто стек. Стандартизована схема, кореляція, безпечні шипери, пошарове зберігання і суворі політики доступу перетворюють логи в потужний інструмент для SRE, безпеки і продукту. Правильні ретенції і FinOps зберігають бюджет, а SLO пайплайна і плейбуки роблять розслідування швидкими і відтворюваними.