Как писать логи правильно: с точки зрения инженерных практик

К логам стоит относиться так же, как к любой другой инженерной задаче.
А любую задачу мы решаем, исходя из:

• проблемы,
• рисков,
• затрат,
• требований, как функциональных, так и нефункциональных.

Если начать думать о логах именно в такой парадигме, довольно быстро становится понятно:

• какие логи писать,
• какие не писать,
• куда их отправлять,
• как долго хранить.

Сбор требований

У логов есть несколько "заказчиков", и у каждого из них свои ожидания.

1. Разработчик
Логи нужны для:

• отладки;
• инцидентов;
• понимания поведения системы в рантайме.

2. Регулятор / аудитор
Его интересуют:

• аудит действий;
• воспроизводимость событий;
• хранение логов в течение заданного срока (1-3-5 лет);
• неизменяемость и полнота данных.

3. Платформенные инженеры (platform / SRE)
Они добавляют очень важные ограничения:

• нельзя писать бесконечное количество логов;
• нельзя хранить все в горячем и дорогом хранилище;
• есть лимиты на ingest, storage и retention;
• есть требования к структуре и формату логов.

4. Специалист по информационной безопасности (InfoSec / iSec)
Он почти всегда скажет следующее:

• персональные данные нельзя писать и хранить в полном виде;
• чувствительные данные (номера карт, токены, секретные ключи, credentials) писать нельзя вообще;
• нужно учитывать риск компрометации доступов и утечек;
• данные должны быть либо усеченные, либо агрегированы, либо исключены

Итог: что мы имеем на входе

Если собрать требования от всех участников, становится очевидно, что логи должны:

• быть полезными для отладки и анализа инцидентов;
• покрывать регуляторные требования по аудиту и хранению;
• не создавать неконтролируемых затрат на хранение и ingest;
• не нарушать требования по безопасности и работе с чувствительными данными;
• быть структурированными и предсказуемыми;
• иметь понятный срок жизни (retention);
• быть разделены по назначению (observability != audit).

С этого момента логирование перестает быть "давайте просто все залогируем, на всякий случай", и превращается в осознанную инженерную систему, где каждое сообщение имеет цель, стоимость и владельца.