Что такое логирование и зачем оно нужно

Логирование — это последовательная запись событий и состояния системы в виде сообщений (логов). Логи фиксируют происходящее внутри приложений, инфраструктуры и пользовательских транзакций: что произошло, когда, где и в каких условиях. Логи — сырьё для диагностики, аудита, наблюдаемости и аналитики.

Основные цели логирования

• Отладка и расследование инцидентов — восстановить хронологию событий, найти причину ошибки.

• Мониторинг и алертинг — по логам строят метрики и правила (ошибки, исключения, паттерны).

• Постмортем и RCA — данные для разбора инцидента (кто, что, в какое время).

• Аудит и соответствие — сохранение действий пользователей и изменений конфигурации для безопасности и регуляторов.

• Бизнес-аналитика — события пользователей, воронки, конверсии (лог как источник событий).

Виды логов

• Application logs — сообщения приложения (ошибки, события бизнес-логики).

• Access logs — запросы к HTTP/ресурсам (обычно web-серверы).

• Audit logs — действия пользователей/админов (аутентификация, изменение прав).

• System / OS logs — журналы ОС, daemons.

• Transaction / DB logs — записи транзакций или WAL в БД.

Формат и уровни

• Формат: unstructured (текст) vs structured (JSON, key=value). Структурированные логи проще парсить, индексировать и извлекать поля.

• Уровни (severity): TRACE / DEBUG / INFO / WARN / ERROR / FATAL. Уровни помогают фильтровать и выбирать, что сохранять и куда алертить.

Что логировать (рекомендации)

• временную метку в UTC;

• уникальный request_id / correlation_id для связывания событий в распределённой системе;

• уровень и имя компонента/сервиса;

• контекст (user_id, tenant_id) — только если это безопасно с точки зрения приватности;

• входные параметры (без секретов), статус ответа, коды ошибок, duration;

• stacktrace при исключениях;

• хост, контейнер, версия приложения (release);

• ссылки на трассы (trace_id) если используются распределённые трейсеры.

Лучшие практики

• использовать структурированные логи (JSON) с согласованной схемой;

• стандартизировать поля (timestamp, service, env, level, trace_id, request_id, user_id, message);

• избегать логирования секретов и чувствительных персональных данных; если нужно — маскировать/хешировать;

• устанавливать политику ретеншна и ротации (log rotation, compression) и управлять стоимостью хранения;

• применять sampling и rate-limiting для очень «шумных» эндпоинтов;

• централизовать (shippers: Fluentd/Fluent Bit, Filebeat, Promtail) и агрегировать (Elasticsearch, Loki, Splunk, BigQuery);

• обеспечивать быстрый доступ к логам через индексацию и дашборды;

• связывать логи с метриками и трейсингом (observability triad) для полного контекста;

• писать понятные и однозначные сообщения: short message + structured fields.

Производительность, стоимость и безопасность

Логи генерируют IO и занимают место — высокочастотные лог-события могут повлиять на производительность и бюджет. Планируйте хранение, архивирование и контроль доступа; шифруйте передачи и хранение, ведите аудит доступа к логам.

Примеры JSON-лога

{
"timestamp":"2025-08-12T10:23:45.123Z",
"service":"orders-api",
"env":"prod",
"level":"ERROR",
"request_id":"abc123",
"trace_id":"trace-xyz",
"user_id":"u-789",
"message":"Failed to process order",
"error":"DBTimeout: deadline exceeded",
"duration_ms":1240,
"host":"app-3"
}

Как логирование интегрируется в наблюдаемость

Логи дают детальные, высококардинальные события; метрики — агрегированные показатели; трейсинг — путь запроса через сервисы. Вместе они дают полноту картины: лог помогает понять «что именно пошло не так», метрики — «как часто/насколько критично», трейсинг — «где в цепочке».

Типичные ошибки

• отсутствие correlation_id → сложность связывать события;

• слишком много подробных логов в проде → стоимость и шум;

• логирование секретов → утечки;

• разрозненные форматы → плохая парсимость;

• отсутствие ретеншна и архивации → правовые и финансовые риски.