Комментарии 36
Фразой «выбросить и забыть» автор предлагает вообще не использовать дебажные логи?
Интересно как рещается проблема «отладки» нового функционала или предполагается, что скилл разработчиков настолько высок, что все проблемы решаются без наличия настолько низкоуровневых логов, в принципе?
Раздел про tracing интересен, но я не уверен, что все проблемы можно обработать сторонними сервисами.
Или я что-то упускаю?
Или подход, что новая бизнес-логика после какого-то уровня сложности обязана реализовываться в другом сервисе?
По опыту когда сервис устаканился и работает находят баги, соответственно, нужно дебажить, зачастую, логами. Не правильнее ли грамотно настроить систему логирования, а не ограничиваться только сообщениями об ошибках в коде, ведь и сама логика работы в сервисе может быть довольно сложной даже без учета ошибок и всякого мониторинга?
Не правильнее ли грамотно настроить систему логирования…Эта мысль похожа на фразу «Не правильнее ли сразу написать систему без ошибок», но я с вами согласен. Вот только как найти баланс между размерами логов (гигабайты логов каждый день?) и их будущей полезностью (каждую команду логгировать?) — вопрос довольно сложный.
У них было 250 000 строк логов в секунду. Что вы собрались там отлаживать? Вы даже десятую часть из этого прочесть не сможете.
Отлаживать надо в dev-окружении, а на продакшене смотреть метрики, как я понимаю.
У нас доходит до 40тб логов за день (и кстати эластик с этим справляется) и при этом отлаживать по логам всё ещё помогает.
Я собирался бы отлаживать бизне-логику, как обычно.
Зачастую, достаточно пары(десятков) секунд, чтобы локализовать проблему. Думаю, что даже самый просто греп справится с несколькими миллионами строк.
Конечно, я понимаю, что у крутых пацанов прод и дев ведут себя одинаково, и с боевых серверов только графики на презенташки экспортируют, но категоричность "дебаг логи в мусорник" хотелось бы услышать какой-то аргумент кроме "парсить долго, а проблему надо на проде решать срочно".
Тоже не совсем понял про just in case логи.
Зачастую они и дают понять контекст ошибок.
Что-то мне кажется, что Sentry не особо поможет прислав мне какой-нибудь InvalidOperationException, который возникает при определённых аргументах в методе, а по логам я как раз смогу увидеть/понять что предшествовало ошибке.
Или вы предлагаете заменить just in case логи на трейсинг?
В общем-то сентри об этом и пишут здесь
https://sentry.io/vs/logging/
Те же business info (количество запросов от одного юзера на конкретный сервис), application performance (скорость выполнения запроса), errors (количество errors за N время) данные вполне можно получать в виде метрик — выйдет гораздо дешевле, быстрее и более информативно, ввиду бОльшей гибкости за счет дешевизны метрик.
Я не отрицаю пользу логов, но почему не использовать то и другое, вместо затрат на парсинг логов?
а выделенной железной машине стояло приложение, которое читало топик Kafka и писало в файлы на диск.
…
Сложно даже подсчитать количество попыток приготовить Elasticsearch. Предполагаю, что мы не умеем его готовить. Но это и не то, что нам нужно, если для его использования, как хранилища логов, требуются особые способности (скилы).
— удивительно, мой велосипед, трудоемкостью в одну человеко-неделю, забирал лог сообщения из ActiveMQ (тут похоже на ваше решение) и клал их в Lucene (индексы создавались ежедневно). Как профит — все хранится также в ФС, плюс поиск по логам на основе запросов Lucene (в эластике они же) и отсутствие каких либо настроек. Правда под нагрузкой в 250 000 записей в секунду я его не тестил) В моем случае, наверное уперся бы в скорость записи на диск, а дальше переполнилась бы очередь в ActiveMQ
Во всей презентации нет ответа на очевидный вопрос: а эластик и логстэш? Не то, чтобы я большой фанат явы, но впечатляющие 18Гб логов в сутки это куда менее пугающие 200kb в секунду, которые прекрасно перевариваются даже однонодовой конфигурацией ELK.
Логи позволяют понимать, как работает код, который ты (кто-то) написал. Если ты и так понимаешь, как работает твой (чей-то) код, то логи не нужны. Но чаще присутствует иллюзия понимания, чем само понимание.
18 ТБ логов в день...
Это с каким уровнем логирования? Как по мне, так на prod'е trace/debug (обычно) не нужны, а если "250К строк в секунду" это уровня warn/err, то — ой!
Вполне допускаю, что trace/debug могут использоваться для сбора каких-то метрик, но, как правильно отметил автор публикации, профилирование != логирование.
Клиентские запросы логгировать например, по которым потенциально потом некие расследования вести.
Резонно. Возможно, есть смысл уровень "info" выделять в отдельный канал, либо сохранение запросов-ответов вынести в отдельную бизнес-функцию. В общем, это тема "на подумать".
У эластика есть ИИ для анализа логов.
Вообще было бы интересно почитать историии про его использование
Перед тем как писать этот мерзкий велосипед(а любой велосипед мерзкий), нужно посмотреть, как часто и зачем логами пользуются. И на основе этого, что-то писать или не писать ничего вообще. А так вы сделали какие-то свои предположения.
Перед тем как говорить, что я там пишу какую то метрику, надо узнать, а как эта метрика будет использоваться и какие решения можно на основе ее принять.
Чтобы работать с логами однообразно сформировали собственный JSON-формат. Он закрывает большинство потребностей в дальнейшей работе с логами.
Не хотите глянуть на формат tree? Тут я о нём рассказывал: https://youtu.be/vBqJWQzPB3Y?t=5652
Если вкратце сравнить с JSON:
- Не тратится время на экранирование и разэкранирование строк.
- Компактный как минифицированный JSON.
- Наглядный как YAML.
- Крайне простой, что позволяет быструю его обработку.
Ваш пример лога мог бы выглядеть так:
info
time \2006-01-02T15:04:05.000+07:00
message \base message
+ custom_field \
\my custom
\multiline message
context \r.y.a.w.r.b.MySuperClass
request_id \7328467235678463578634578678456783647
thread \123
Логи не нужны?