Логирование задач: zap и slog рядом

Библиотека объявляет маленький интерфейс: type Logger interface { Info(msg string, keysAndValues ...interface{}); Error(err error, msg string, keysAndValues ...interface{}) } и опцию cron.WithLogger(l). Логирование cron начинается с честного факта: если WithLogger не передать, логгером будет PrintfLogger поверх log.New(io.Discard, ...), то есть все события уходят в никуда — ни паники Recover, ни тики не увидят свет. Второй факт: PrintfLogger печатает только ошибки, а для Info-событий нужен VerbosePrintfLogger — иначе вы подключили логгер, который молчит на тиках. Какие события библиотека отдаёт: start и stop при запуске и остановке, added и removed при регистрации и снятии записи, wake при пробуждении цикла и run — строка на каждое срабатывание с номером записи и моментом следующего тика. Это удобный каркас диагностики: вопрос «а задача вообще запланирована» закрывается строками added и run. Сами события несут только идентификаторы и время — бизнес-детали добавляете вы.

Ни zap, ни slog не реализуют cron.Logger из коробки, поэтому между ними и планировщиком ставится адаптер — структура с двумя методами. Для slog связка естественна: методы Info и Error принимают msg и пары ключ-значение, и slog.Info(msg, kv...) с ними совпадает почти дословно. Для zap удобнее SugaredLogger: Infow и Errorw принимают те же пары, а в Errorw ошибку передают первой парой err. Адаптер лучше писать один на сервис и держать рядом с конфигурацией логгера — место, где его найдут все новые задачи. Уровни переводятся честно: события библиотеки — это Info, ошибки Recover и ошибок парсинга — Error. Если сервис уже ведёт поля окружения через zap.With и Named, адаптеру можно присвоить имя cron, чтобы события планировщика отличались в поиске от HTTP-запросов. Базовую семантику уровней напомнит урок про уровни логов, а детали полей — урок про структурные поля zap.

Лог задачи становится полезным, когда поля повторяются от задачи к задаче и совпадают с метриками. Минимальный набор: job — имя из конфига, длительность тика, исход — ok или описание ошибки, при ретраях — номер попытки. Старт тика логировать целиком нет смысла: событие run от планировщика уже есть, а повторная строка только удваивает объём; информативнее запись после завершения. Уровни распределяются так: успешный тик — Info, пропуск и задержка от обёрток — Warn, ошибка и паника — Error. Выигрывает от того же правила, что и HTTP: одна запись на операцию со всеми полями, а не россыпь Println по ходу. Ошибки из глубины задачи оборачивают через fmt.Errorf с контекстом — механику %w и errors.Is разбирал урок про оборачивание ошибок. Согласованность с метриками проверяется просто: те же значения поля job и те же исходы, что и в CounterVec, — тогда связка «алерт поднял метрику, лог нашёл причину» работает без ручного сопоставления.

Логи задач go-сервиса живут в паре с метриками: одна сторона показывает, что деградация есть, вторая — почему. Рабочий сценарий: алерт поднялся по росту ошибок выгрузки, дежурный фильтрует логи по полю job=pull-orders и окну времени алерта, находит строку ошибки с кодом внешнего сервиса. Эта связка работает, только если поля совпадают: значение job в логе равно значению лейбла job в CounterVec, а исход в логе совпадает с лейблом status. Приём корреляции логов и метрик на примере веб-сервиса разобран в уроке про логи и метрики; для cron он ложится один в один. Второй уровень связи — трейс: если сервис раздаёт request id на HTTP-запросы из урока про request id, задачам, которые дёргают API, полезно передавать свой id вызова — тогда лог задачи и лог внешнего запроса сшиваются. Ошибки и стектрейсы в zap — отдельная настройка, которую подробно делал урок про ошибки и стеки.

Спорная привычка, которую стоит оспорить: логировать завершение каждого тика каждой задачи на Info. Двадцать задач с пятиминутным интервалом дают почти шесть тысяч записей в сутки только о благополучных тиках, и в них тонут записи о том, что действительно случилось. Мера разумности простая: лог должен уменьшать время разбора, а не увеличивать объём поиска. Для стабильных задач достаточно событий библиотеки — run в verbose-логгере показывает, что тик состоялся, без вашей записи; свою строку пишут при отклонении от нормы: длительность выше порога, ошибка, повтор. Второй инструмент против шума — сэмплирование: если запись нужна на каждый тик, например для аудита, их гасят сэмплером из урока про сэмплирование zap. Граница, которую нельзя переступить: Warn и Error сэмплировать не стоит — это те записи, ради которых лог существует. Баланс пересматривают после инцидентов: если дежурный листает девять экранов ради одной строки ошибки, настройки шумят.