НЕмитап Golang#1 Алексей Мичурин - Логирование как в Авито: go + slog
HTML-код
- Опубликовано: 28 май 2024
- Всем привет! Это новый формат на канале avito.tech - НЕмитап. Наши инженеры рассказывают про инструменты и подходы, которые используют в работе, и отвечают на ваши вопросы.
Алексей Мичурин расскажет про логирование и подход к нему, который выбрали в Авито. Обсудим, что такое структурированное логирование, поговорим о его возможностях и подходах. Расскажем, почему мы остановились именно на своём подходе, и какие у этого есть плюсы и подводные камни.
Тезисы:
• Что такое структурированное логирование.
• Какие есть подходы и какие из них иcпользует Авито.
• Пример реализации авитовского подхода на основе стандартного log/slog.
• Логирование ошибок с полным контекстом.
• Бенифиты подхода Авито.
• Подводные камни и опасности: и как от них подстраховаться.
• Кратко о возможностях log/slog, которые мы в Авито не используем, но вам они могут понравиться.
Подборка ресурсов:
• Демо-проект Алексея: clc.to/E0WXOw
• Логгер Golang: pkg.go.dev/log/slog
00:00 | Заставка
05:50 | Вступление
06:50 | Как выглядели логи раньше, и что сейчас
08:18 | Go 1.21: log/slog
09:35 | Пример 1: используем slog
11:19 | Пример 2: структурированные логи
13:46 | Пример 3: дидактический
20:12 | Пример 4: развиваем интерфейс
22:21 | Пример 5: перемены в логировании
23:40 | Пример 6: совершенствуем идею
25:38 | Пример 7: ошибка при отправке sms
31:36 | Пример 8: кастомная ошибка
44:31 | Вопрос от зрителей: нормально ли писать в логи номера телефонов?
46:40 | Финал и ответы на вопросы в чате
AvitoTech - это команда инженеров Авито. Подпишитесь на наш канал, соцсети и блоги, чтобы узнавать больше о технологиях Авито 👇🏻
ВК: avitotech
Телеграм: t.me/+wU3vnNnqr7JlZDIy
Хабр: habr.com/ru/company/avito
Медиум (eng): / avitotech
Гитхаб: github.com/avito-tech
RuTube: rutube.ru/channel/30462632/
Дзен: dzen.ru/avitotech
Сайт: avito.tech
#golang #немитап
00:00 | Заставка
05:50 | Вступление
06:50 | Как выглядели логи раньше, и что сейчас
08:18 | Go 1.21: log/slog
09:35 | Пример 1: используем slog
11:19 | Пример 2: структурированные логи
13:46 | Пример 3: дидактический
20:12 | Пример 4: развиваем интерфейс
22:21 | Пример 5: перемены в логировании
23:40 | Пример 6: совершенствуем идею
25:38 | Пример 7: ошибка при отправке sms
31:36 | Пример 8: кастомная ошибка
44:31 | Вопрос от зрителей: нормально ли писать в логи номера телефонов?
46:40 | Финал и ответы на вопросы в чате
крутой доклад, респект, больше такого контента
Отличный доклад, спасибо!
Спасибо, очень полезно!
Интересно, спасибо)
спасибо, было интересно
думаю userId это всё же второстепенный аргумент. Первостепенным должен быть traceId. А так живенько, полезно. Спасибо.
TraceId точно надо добавлять, если он есть. Но главное, иметь в логах информацию, которую сообщают пользователи/тестировщики.
Thanks and Good Luck!
Леша мой герой!)
Видео огонь, спасибо
Алексей, поделитесь, пожалуйста, своим конфигом для vim 🙏
Прикольно смотреть, как меняется подходы к разработке. Ранее вот эти примеры использовались, чтоб на собеседовании спрашивать какие SOLID принципы здесь нарушаются. Очень много вопросов возникает после просмотра, жаль не удалось посмотреть в прямом эфире.
- Почему логгер(интерфейсный слой) знает о какой-то бизнес логике? Если проблема лишь в том что какой-то программист захочет назвать поле по другому, что мешает этому программисту создать другую структуру данных? П.С. Из ваших слов в авито вы прокидываете мапу, тогда не понятно зачем пример с структурами...
- Зачем засорять контекст данными? Я думаю вытекающие проблемы понятны
- Почему выбрали именно slog?
Честно ожидал что будет как "Jaeger для трассировки в микросервисной архитектуре", а вышла на аудиторию, которая только начинает работать с golang
Не возникает делима где логировать 27:05 ошибку, она всегда должна логироваться, она должна логироваться там где происходит. Это бред какой-то логировать её где-то на нижних уровнях. Представь, что ты используешь стороннюю библиотеку и она вместо того чтобы залогировать какую-то ошибку в себе, прокалывание её наверх, чтобы ты сам решал логировать её или нет. Такого я ни разу не видел в жизни. Да и логируется всегда весь контекс и стектрейс, который есть только в месте возникновения ошибки. Я посмотрел лекцию до конца и видел вариант с добавлением в специально созданную структуру контекста, но это лютая дичь! Вернёмся к моему другому примеру с 5000 логов, тебе нужно будет сделать 5000 обвёрток и чуть меньше структур для прокидывания контекста наверх? А сколько принципов программирования и проектирования это нарушает? +-10 штук. А если у тебя часть кода будет лежать в одном модуле, а часть в другом, нужно будет в вызывающем модуле всё логировать? А если его начнут использовать ещё кто-то?
Да и бред про устоявшуюся команду меня паразил. А что если ваш сторожила уволится?
Да и возвращать ошибку на каждом уровне это ещё тот спагетти. Уже давно выработан подход к обработке ошибок, почитайте книгу Чистый код, главу про обработку ошибок, когда возникает ошибка, она сразу логируется и возвращается исключение, которое перехватывается где-то на верхнем уровне. Да, в го нет исключений, но есть паники, которыми можно реализовать тот же самый подход.
Такой бы код (даже с учётом примеров) у меня никогда бы не прошёл ревью.
В общем, лекция хорошая для новичков, кто вообще не знает о структурировании легировании, но для опытных она будет бесполезной.
паниками реализовывать исключение - ты чего)) это очень дорого, поэтому бессмысленно
Зачем 15 минут заставок?
cfbr
Смешно говорит, что код безупречен, а в нём десяток функций которые просто логируют. Так, если в приложении будет 10000 файлов и 5000 комментариев, нужно будет сделать 5000 функций обвёрток для лога?
Привет, не совсем так. Одна функция на ключ, а не на файл )
Thanks and Good Luck!