Логи любят писать в момент боли: «давайте залогируем всё, потом разберёмся». Через месяц диск полный, поиск ничего не находит, а в строках — километры `debug` про парсинг каждого поля. Я видел сервисы, где инцидент тонул в собственном шуме быстрее, чем в реальной причине сбоя.
Полезная установка: лог — это сообщение будущему дежурному в три ночи, у которого осталось двадцать минут до эскалации. Ему нужны корреляционный id, кто пользователь или заказ, что пытались сделать и чем закончилось. Остальное чаще лучше отдать метрике или трейсу, а не ещё одной строке в Elasticsearch.
На практике я вычищаю три категории в первую очередь. Первая — логи в горячих циклах без семплирования. Вторая — логирование тел запросов целиком (привет, токены и персональные данные в plain text). Третья — одинаковые сообщения без контекста: сто раз `failed` без кода ошибки и без id сущности.
Что выкидывать первым
Уровни тоже часто врут. У нас `error` должен означать «надо смотреть», а не «ожидаемый 404 от клиента» или «ретрай, который штатно прошёл со второй попытки». Если алерт орёт из-за нормы — люди перестают верить алертам. Это хуже, чем отсутствие одного лога. Тест на осмысленность: возьмите последний инцидент и спросите, каких полей не хватило в первую минуту. Именно их добавляйте. После двух-трёх разборов список стабилизируется, и хочется выкинуть исторический шум.
Структурированные логи спасают, но только если поля стабильны. Сегодня `userId`, завтра `user_id`, послезавтра вложенный объект без договорённости — и парсеры разъехались. Договаривайтесь о словаре полей хотя бы внутри команды и не плодите синонимы от настроения автора.
Стабильные поля важнее красоты
Перед продом я люблю прогнать сценарий отказа и прочитать логи глазами, как будто я новый дежурный. Если за две минуты не понял, где оборвалась цепочка — логи ещё сырые. Короткая заметка «как мы логируем» из пяти строк иногда полезнее очередной библиотеки с красивыми адаптерами. Если логи в нескольких системах, опишите абзацем, где искать что. Иначе дежурный прыгает между Kibana, трейсом и чатом. Навигация по наблюдаемости — тоже часть логирования, просто про людей.
Семплирование и ретеншн — тоже часть дизайна. Хранить всё forever дорого и обычно никому не нужно. Решите, что должно жить сутки, что — две недели, что — квартал. Иначе через полгода вы платите за шум, который никто не читал.
Идеального объёма нет. Есть объём, при котором инцидент расследуется без шаманства и без пяти человек в созвоне. К нему и двигайтесь: режьте шум, добавляйте контекст, проверяйте на реальных фейлах, а не на теоретической полноте покрытия.
Ещё один практический жест: заведите «пример хорошего лога» прямо в README сервиса — две-три реальные строки из удачного разбора. Новым людям проще копировать живой образец, чем читать абстрактные правила про уровни. Я так быстрее выравниваю стиль, чем через линтеры сообщений, которых всё равно нет. И да, иногда полезно временно включить более подробный лог по флагу на одного пользователя, а не поднимать шум на весь прод. Точечная наблюдаемость бьёт ковровое «давайте всё debug».