Стратегия агрегации логов

Действуй как Observability Engineer. Спроектируй стратегию агрегации логов для {{stack}}. Текущий объём: {{log_volume}}.

Что сделать

1. Structured logging в JSON, не plaintext. Логи без структуры — это grep-only, без структуры нельзя строить дашборды и алёрты.

   • Канонический формат: {"ts": "...", "level": "info", "msg": "...", "service": "...", "trace_id": "...", "span_id": "...", "user_id": "...", "request_id": "..."}.
   • Один лог = одна строка JSON. Не multi-line stack trace без \n escape — иначе агрегатор парсит как N строк.
   • Library: zap (Go), structlog (Python), pino (Node), logback-json (JVM). Не console.log с string concat.
   • Levels: ERROR (actionable, page-able) / WARN (degradation, retry succeeded) / INFO (state transition) / DEBUG (verbose, prod off). FATAL только если процесс сейчас умрёт.

2. Что логировать (и что НЕ логировать). Логирование — это контракт между «инженером в инциденте» и «инженером, написавшим код 6 месяцев назад».

   • Логируй: boundary events (request in/out, DB call, external API call), state transitions, ошибки с контекстом, бизнес-инварианты (order created, payment captured).
   • Не логируй: PII в plaintext (email/SSN/CC), passwords, JWT в полном виде, request bodies > 1 KB (truncate или sample).
   • Context propagation: trace_id / request_id прокидывается через все слои (HTTP headers → middleware → DB query log). Без этого корреляция = grep-головоломка.
   • Sampling для high-volume: успешные health checks → 1%, errors → 100%. INFO в hot path → adaptive sampling.

3. Storage tiers (hot / warm / cold). Один tier для всего = либо разоришься, либо потеряешь данные. Логи стареют — план под это.

   • Hot (0-7 дней): SSD, fast query (Elastic, Loki с in-memory cache, Datadog standard). Сюда летит весь стрим. Стоимость: ~$2-5/GB/мес.
   • Warm (7-30 дней): компрессия, slower query (Elastic frozen, Loki long-term, Datadog Flex Logs). Запрос за минуты, не секунды. ~$0.5-1/GB/мес.
   • Cold (30-365 дней): object storage (S3/GCS) с парсингом on-demand (Athena, BigQuery). Compliance/forensics, не для алёртов. ~$0.02-0.05/GB/мес.
   • Auto-migration policy между tier'ами — ILM policy в Elastic, retention в Loki, archive в Datadog.

4. Где хранить (выбор стека). Зависит от объёма, бюджета и кто пользователь.

   • Loki: дешёво (index только по labels, content в object storage), хорош с Grafana, ограниченный full-text. Подходит < 5 TB/день, команды с уже Prometheus/Grafana.
   • Elasticsearch/OpenSearch: богатый full-text, дорого по compute и storage, операционный overhead (cluster, sharding, ILM). 5-50 TB/день.
   • Datadog/New Relic/Splunk: managed, дорого ($1.5-3/GB ingestion), zero ops. Хорош для < 1 TB/день или enterprise с бюджетом.
   • ClickHouse: для очень больших объёмов и аналитики над логами, требует команды для эксплуатации.
   • Не миксуй 3 системы «потому что исторически» — централизуй или мигрируй по плану, иначе troubleshooting = jumping between UIs.

5. Cost optimisation. Логи — обычно top-3 cost item в observability бюджете. Контролируй или утонешь.

   • Drop at source. Дешевле всего НЕ отправить лог. Filter в agent (Fluent Bit, Vector): убирай DEBUG, health-checks, k8s-noise.
   • Sampling at source. 200-OK request → 1% sample, error → 100%. Сохраняет сигнал, режет шум 90%+.
   • Index только то, что query'им. В Elastic — doc_values=false для полей, по которым никогда не фильтруем.
   • Cardinality control. Не клади user_id в metric labels (Loki/Datadog metrics) — взорвёт cost. В body лог — ок.
   • Monthly cost review: top-10 services by ingest, top-10 labels by cardinality. Talk to owner если кто-то прыгнул в 3x.

Anti-patterns

• ❌ Logs as event store («мы реконструируем state из логов») — логи теряются и сэмплятся, это не source of truth.
• ❌ logger.info(JSON.stringify(huge_object)) — раздувает ingest, ломает парсинг.
• ❌ Один глобальный индекс на всё — медленные query, нельзя гранулярно ретеншнить.
• ❌ Логирование с уровнем DEBUG в проде «на всякий случай» — 10x cost, нечитаемые дашборды.
• ❌ PII в логах без redaction — GDPR / HIPAA violation, штрафы, юристы.

Формат вывода

## Log schema (canonical fields)
| Field | Type | Required | Notes |

## What to log / not log
| Event type | Log? | Level | Sample rate | Notes |

## Storage tiers
| Tier | Retention | Backend | Query latency | Cost/GB |

## Cost levers (top 5)
| Lever | Current waste | Action | Saving estimate |

## Migration plan (if changing stack)
1. Phase 1: ...
2. Phase 2: ...

## Cardinality / cost audit (monthly)
- [ ] Top services by ingest
- [ ] Top labels by cardinality
- [ ] PII scan results

Принцип: логи нужны для двух вещей — отвечать на «что произошло» в инциденте и поставлять контекст для traces/metrics. Всё, что не служит этим целям, — кандидат на удаление, не на сохранение.