НЕмитап Golang#1 Алексей Мичурин - Логирование как в Авито: go + slog
ฝัง
- เผยแพร่เมื่อ 29 พ.ค. 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 | Финал и ответы на вопросы в чате
крутой доклад, респект, больше такого контента
Спасибо, очень полезно!
Отличный доклад, спасибо!
Интересно, спасибо)
спасибо, было интересно
Thanks and Good Luck!
думаю userId это всё же второстепенный аргумент. Первостепенным должен быть traceId. А так живенько, полезно. Спасибо.
TraceId точно надо добавлять, если он есть. Но главное, иметь в логах информацию, которую сообщают пользователи/тестировщики.
Видео огонь, спасибо
Алексей, поделитесь, пожалуйста, своим конфигом для vim 🙏
Леша мой герой!)
Прикольно смотреть, как меняется подходы к разработке. Ранее вот эти примеры использовались, чтоб на собеседовании спрашивать какие SOLID принципы здесь нарушаются. Очень много вопросов возникает после просмотра, жаль не удалось посмотреть в прямом эфире.
- Почему логгер(интерфейсный слой) знает о какой-то бизнес логике? Если проблема лишь в том что какой-то программист захочет назвать поле по другому, что мешает этому программисту создать другую структуру данных? П.С. Из ваших слов в авито вы прокидываете мапу, тогда не понятно зачем пример с структурами...
- Зачем засорять контекст данными? Я думаю вытекающие проблемы понятны
- Почему выбрали именно slog?
Честно ожидал что будет как "Jaeger для трассировки в микросервисной архитектуре", а вышла на аудиторию, которая только начинает работать с golang
cfbr
Зачем 15 минут заставок?
Не возникает делима где логировать 27:05 ошибку, она всегда должна логироваться, она должна логироваться там где происходит. Это бред какой-то логировать её где-то на нижних уровнях. Представь, что ты используешь стороннюю библиотеку и она вместо того чтобы залогировать какую-то ошибку в себе, прокалывание её наверх, чтобы ты сам решал логировать её или нет. Такого я ни разу не видел в жизни. Да и логируется всегда весь контекс и стектрейс, который есть только в месте возникновения ошибки. Я посмотрел лекцию до конца и видел вариант с добавлением в специально созданную структуру контекста, но это лютая дичь! Вернёмся к моему другому примеру с 5000 логов, тебе нужно будет сделать 5000 обвёрток и чуть меньше структур для прокидывания контекста наверх? А сколько принципов программирования и проектирования это нарушает? +-10 штук. А если у тебя часть кода будет лежать в одном модуле, а часть в другом, нужно будет в вызывающем модуле всё логировать? А если его начнут использовать ещё кто-то?
Да и бред про устоявшуюся команду меня паразил. А что если ваш сторожила уволится?
Да и возвращать ошибку на каждом уровне это ещё тот спагетти. Уже давно выработан подход к обработке ошибок, почитайте книгу Чистый код, главу про обработку ошибок, когда возникает ошибка, она сразу логируется и возвращается исключение, которое перехватывается где-то на верхнем уровне. Да, в го нет исключений, но есть паники, которыми можно реализовать тот же самый подход.
Такой бы код (даже с учётом примеров) у меня никогда бы не прошёл ревью.
В общем, лекция хорошая для новичков, кто вообще не знает о структурировании легировании, но для опытных она будет бесполезной.
паниками реализовывать исключение - ты чего)) это очень дорого, поэтому бессмысленно
Смешно говорит, что код безупречен, а в нём десяток функций которые просто логируют. Так, если в приложении будет 10000 файлов и 5000 комментариев, нужно будет сделать 5000 функций обвёрток для лога?
Привет, не совсем так. Одна функция на ключ, а не на файл )
Thanks and Good Luck!