Знакомство с slog: зачем структурированные логи

Беда текстовых логов не в том, что их плохо пишут, а в том, что строка — плоский формат. Чтобы ответить на вопрос «сколько заказов упало на оплате за последний час», дежурный собирает конвейер из grep, cut и awk, а в худшем случае тянет регулярку, потому что часть значений слеплена пробелами посреди фразы. Каждый сервис в компании лепит строки по-своему: один начинает с даты, второй — с уровня, третий вставляет всё после двоеточия, и парсер, написанный для первого сервиса, на втором выдаёт мусор. Разбор ломается молча: поле переименовали — фильтр перестал находить записи, но узнает об этом человек только на следующем инциденте. А попробуйте сгруппировать ошибки по пользователю или посчитать длительность обработки, если она вшита в середину фразы «обработано за 137 мс». Всё это лечится одним изменением контракта: лог пишется не как фраза, а как запись с именованными полями, и машина сама делает то, что раньше делали глаза.

Ответом экосистемы стал пакет log/slog, вошедший в стандартную библиотеку в версии Go 1.21. До этого выбор делали между сторонними логгерами: zap от Uber, zerolog, logrus, — и каждая команда таскала свой набор обёрток поверх них. Slog договорился о вещах более важных, чем скорость: единый API уровней и атрибутов, заменяемый обработчик вывода и ноль внешних зависимостей. Вызов логирования выглядит как сообщение с парами «ключ — значение»: slog.Info("заказ оформлен", "id", 42). Уровень говорит, насколько важна запись, атрибуты несут поля, а Handler решает, во что превратить запись: строку, JSON или корпоративный формат. Логирование в go долгие годы было слабым местом стандартной библиотеки — теперь это слой, на котором строят и собственные обёртки, и миграцию со старых пакетов. Если раньше вопрос «какой у вас логгер go» означал выбор зависимости, то теперь у него есть ответ по умолчанию.

Второй вопрос, без которого непонятна ценность структуры: где логи живут на проде. Ответ неожиданно скучный: приложение почти не заботится о месте. Сервис пишет в стандартный вывод, и дальше подключается окружение. Docker собирает stdout и stderr каждого контейнера в файл на хосте — драйвер по умолчанию называется json-file, а docker logs показывает содержимое. Для сервисов под systemd поток ловит journald, записи читаются через journalctl -u имя-сервиса. Дальше по конвейеру стоит коллектор — Promtail, Fluent Bit или Vector, — который отправляет записи в хранилище: Loki, Elasticsearch или что-то самописное. Именно там структурные поля превращаются в индекс, по которому за секунды ищут по идентификатору заказа и уровню. Запись в файлы из приложения, ротация и права на диск — тема двадцать четвёртого урока с командами Docker и journald. Сейчас важно запомнить принцип: stdout наружу, структуру внутрь, сбор — окружению.

Мнение, с которым можно спорить на кухне: структурированные логи нужны не всякому проекту. CLI-утилите, которая печатает прогресс, или скрипту на сто строк достаточно fmt и stderr: у них нет дежурных, инцидентов и миллиона записей в сутки, а структура лишь разбухает код. Граница переезда конкретная: сервис живёт дольше недели, его перезапускают в чужое время суток, и есть человек, который ночью отвечает на вопрос «что сломалось». Тогда стоимость настройки slog — один импорт и несколько строк — исчезает на фоне первой же ночи, когда разбор занял минуты вместо часов. Пользователям logrus и zap тоже не нужно ничего переписывать сегодня: обе библиотеки спокойно соседствуют с slog, и миграцию обычно делают по слоям, а не одним коммитом. Про переезд со старого пакета log написан отдельный десятый урок, а про уровни по окружению — восемнадцатый.