> Как долго хранятся логи (Go)

Короткий ответ

Срок хранения логов не регламентирован жёстко и зависит от требований: безопасности, аудита, отладки и законодательства. Обычно это компромисс между ценностью данных и стоимостью хранения. Для backend-сервисов на Go типичны ротация по размеру или времени (например, 30 дней), retention-политики в централизованных системах (ELK, Loki) и обязательное хранение для compliance-требований (например, PCI DSS - 1 год, GDPR - по запросу). В production-среде срок задаётся явно через конфигурацию и автоматическую очистку.

Подробное объяснение

Срок хранения логов определяется несколькими факторами:

• Тип логов: access-логи (можно хранить 7-30 дней), error-логи (дольше, 30-90 дней), audit-логи (1-7 лет), debug-логи (часы или дни).
• Регуляторные требования: финансовые и медицинские системы обязаны хранить логи 1-7 лет. GDPR требует удалять персональные данные по запросу, поэтому логи с PII должны иметь механизм удаления.
• Бизнес-ценность: логи для анализа инцидентов и трендов хранят дольше, чем логи для отладки.
• Стоимость хранения: чем дольше храним, тем дороже. Поэтому используют tiered storage: горячие (fast, 7 дней), тёплые (30-90 дней), холодные (архив, до 1 года+).

В Go-приложениях логи обычно пишутся в stdout/stderr, а сбор и retention выполняет внешняя система (Loki, ELK, CloudWatch). На уровне приложения можно настроить ротацию файлов через lumberjack или logrotate, но это скорее для локальной разработки или простых деплоев.

На практике

• Определите retention-политику в конфигурации сервиса (например, переменная окружения LOG_RETENTION_DAYS).
• Используйте структурированные логи (JSON) с полем timestamp - это упрощает автоматическую очистку.
• Для compliance-логов добавьте отдельный поток с неизменяемым хранением (append-only) и отдельным retention.
• Настройте алерты на переполнение хранилища и на неожиданное удаление логов.
• Для локальной разработки достаточно 7 дней, для staging - 14, для production - 30+ в зависимости от SLA.

Пример кода

GO
// Пример настройки ротации файловых логов в Go
import (
    "gopkg.in/natefinch/lumberjack.v2"
    "log"
)

func setupLogger() {
    log.SetOutput(&lumberjack.Logger{
        Filename:   "/var/log/app.log",
        MaxSize:    100, // мегабайт
        MaxBackups: 3,
        MaxAge:     30, // дней
        Compress:   true,
    })
}

Для централизованного хранения - просто пишите в stdout, а retention задаётся в конфигурации Loki/ELK:

GO
log.Printf("user_id=%s action=login", userID)

Как отвечать на собеседовании

• Начните с "зависит от требований", затем перечислите ключевые факторы: тип логов, регуляторика, стоимость.
• Приведите конкретные цифры для разных категорий (access - 30 дней, audit - 1 год).
• Упомяните, что в Go-приложениях retention обычно не на уровне кода, а на уровне инфраструктуры.
• Если спросят про GDPR - скажите, что нужно уметь удалять логи по конкретному пользователю (например, через поле user_id и фоновую задачу).
• Покажите понимание trade-off: долгое хранение = больше данных для анализа, но выше стоимость и риски утечки.

Что проверяет интервьюер

• Понимание жизненного цикла логов, а не только "как писать в файл".
• Умение связывать технические решения с бизнес-требованиями и законодательством.
• Знание практик ротации и централизованного сбора логов.
• Способность аргументировать выбор конкретного срока хранения.

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

• Ответ "логи хранятся вечно" или "пока не кончится место" - показывает отсутствие системного подхода.
• Игнорирование compliance-требований (например, для платёжных систем).
• Предложение хранить все логи одинаково долго, без разделения по типам.
• Утверждение, что retention настраивается только в коде приложения - на самом деле чаще в инфраструктуре.
• Забывают про удаление PII по GDPR - это критично для европейских проектов.