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

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 пайплайна и плейбуки делают расследования быстрыми и воспроизводимыми.