Log management

Роль логов

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

В отличие от метрик, логи сохраняют отдельные события. В отличие от трассировки, запись лога не обязана принадлежать определённому запросу. Связь появляется через trace/span/request ID и другие безопасные атрибуты.

Структурированные события

Текстовая строка удобна человеку, но плохо подходит для систематического поиска. Структурированный формат, обычно JSON, выделяет поля:

{
  "timestamp": "2026-10-31T12:00:00Z",
  "level": "error",
  "service": "checkout",
  "env": "prod",
  "trace_id": "…",
  "event": "payment_failed",
  "duration_ms": 840
}

Уровень error сам по себе не объясняет влияние. Полезны единые имена событий, service/env/release, correlation ID и код результата. Пароли, токены, платёжные данные и персональные данные не должны попадать в событие.

Конвейер логов

Источник → collector → parse/normalize → redact/filter/sample
        → маршрутизация → хранилище → поиск и dashboards → alert

Collector может получать файлы, syslog, события приложения или OTLP. На этапе обработки приводят форматы, добавляют метаданные, удаляют секреты и отбрасывают заведомо бесполезные события. Изменения обработки должны быть версионируемыми и проверяемыми, иначе диагностические данные исчезнут незаметно.

Поиск и анализ

Базовые возможности log management:

• live tail для наблюдения текущего потока;
• фильтры по service, level, event, release и trace ID;
• просмотр соседних событий до и после ошибки;
• группировка похожих сообщений и pattern detection;
• агрегации и дашборды по частоте и длительности;
• переход к связанной трассе или исключению.

Запросный язык — SQL, LogQL, Lucene или другой — вторичен по отношению к качеству схемы событий. Без единых полей любой поиск превращается в набор хрупких регулярных выражений.

Retention и стоимость

Срок хранения выбирают по задачам: оперативная диагностика, расследование инцидентов, audit и аналитика могут требовать разных периодов. Не все события одинаково ценны.

Стоимостью управляют через:

• исключение шумных источников до хранения;
• разумный sampling без потери редких критичных ошибок;
• отдельные retention policies по типам данных;
• уровни хранения или объектное хранилище;
• контроль объёма и неожиданного роста источников.

Нельзя экономить удалением доказательств текущего инцидента или маскированием только после попадания секретов в долгосрочное хранилище.

Минимальная схема

1. Определить обязательные поля и запрещённые данные.
2. Централизовать application, reverse proxy и критичные infrastructure logs.
3. Добавить trace/request ID в приложение и propagation.
4. Проверить поиск одного запроса сквозь сервисы.
5. Настроить retention, redaction и контроль доступа.
6. Создать alerts только для событий с понятным действием.

Связанные инструменты

• Loki — хранение и запросы логов с labels.
• OpenTelemetry — получение, обработка и экспорт логов.
• Grafana — исследование логов рядом с метриками и трассами.
• Better Stack — структурированные события, фильтры и дашборды.

Связанные материалы

• Tracing — сквозной контекст запроса.
• Error tracking — специализированная обработка исключений.
• Alerting — log-based оповещения без лишнего шума.

Материалы и источники

• OpenTelemetry: Logs — роль логов и связь с другими сигналами.
• Better Stack: Log management — примеры структурирования, фильтрации и анализа.
• Grafana Loki: Documentation — labels, хранение и LogQL.