Допустимо ли хранить логи nodejs приложения в mysql бд или есть решения лучше?

Question

[Vadim Stepanenko]

Разрабатываю веб сервис на fastify и хочу грамотно настроить логгирование. Во всех предыдущих пет-проектах я вызывал console.log и при возникновении ошибок просто смотрел консоль. Минус такого решения - при перезапуске сервиса консоль очищается.

Появилась идея писать логи в отдельную бд, прокидывать туда лейблы (info,error,critical) и прочую полезную информацию, чтобы можно было легко эти логи изучать.

Но может есть более элегантные решения при котором разбор логов не будет адским занятием?

Comments

[Дмитрий]

Писать в файлы

[Сергей delphinpro]

Допустимо.
Есть, но это не точно.

Answer 1

[Dmitry Roo]

Есть более элегантное решение.
Называется Elastic Stack

Comments

[Adamos]

Посмотрев, что такое ELK.
Вспомнил, как в теле-ЧГК пригласили команду французов и играли с ними в поддавки, задав такой, например, вопрос - что означает поговорка "элегантный, как рояль?".
Запомнилось как жесткий редакторский факап (рояль по-французски - "le piano à queue", и вместо детского вопроса получился гроб), но речь не об этом.
Просто как логгер для легкого веб-сервиса ELK, похоже, будет как раз элегантным - как рояль.
В однушке ;)

[Дмитрий]

Adamos, как и мускул

[Adamos]

Дмитрий, мускуль на одноядерном одногиговом VPS тихо шуршит в уголке.
Elastic, если вообще запустится на таком слабом железе - загонит в этот уголок всех остальных :)

[Дмитрий]

Adamos, да я про то, что с пушки по воробьям. Пусть оно в файлы пишет и можно даже logrotate прикрутить

[Dmitry Roo]

Adamos, зачем же одноядерный и одногиговый? Нужно кластер собирать под это дело.
Кстати, Vadim Stepanenko, а сколько у вас логов то генерируется? (например за минуту)

[Сергей Горностаев]

Adamos, да, Ëлка сложная и прожорливая, но к счастью у неë есть легковесные альтернативы, вроде Zinc.

[Adamos]

Сергей Горностаев, хорошая новогодняя тема, однако - "как правильно водить хоровод вокруг серверной, когда ставишь там Ёлку" %)
А я вот, признаться, именно сегодня обнаружил, что такими темпами (по пол-гига в сутки последнюю неделю) у меня логи на VPS сожрут все оставшееся место и остановят сайт нахрен аккурат в праздники. Тут как-то не до Ёлок...

[Dmitry Roo]

Adamos, так деды же ещё говаривали - готовь ёлку летом...

Answer 2

[Everything_is_bad]

Но может есть более элегантные решения при котором разбор логов не будет адским занятием?

писать логи стандартными средствами системы, следующий этап ELK, но это точно не для пет-проектов

Answer 3

[Vitaly Karasik]

Есть - уже лет 10+ назад придумали БД для логов. Самые популярные сегодня - Elastic (== ELK в прошлом) и Loki.
Есть куча облачных сервисов на базе этих БД.
Все современные логгеры поддерживают log shipping по сети.

Answer 4

[rPman]

Логи нужно не просто писать в какую-то базу, а делать их машиночитаемыми, иначе смысла нет.

Пишут тут что это нужно только если у тебя миллионы запросов и гигабайты логов.. все это чушь (не совсем, просто если у тебя маленький проект, пользу логи будут приносить редко), а вот централизованная работа с логами со всех своих инстансев и даже проектов, очень даже неплохо, облегчает мониторинг, облегчает разработку, облегчает поиск проблемных пользователей/ситуаций и т.п... но ценою ресурсов на это.

А так, первым шагом можно вместо записи в базу данных, просто писать в jsonl (построчно по json на событие), по меньше упаковки в человекочитаемые строки и побольше читаемые машиной, постаравшийсь полностью исключить вывод сообщений об ошибках в stdout/stderr, и над именованием файлов подумать, что бы удобнее с ними было работать.

Answer 5

[Billander]

Писать в файлы так как их можно прочитать где угодно, вытащить с убитой системы и тд, самое идеальное решение (не зря логи все в файлах), причем продумать формат так что бы его можно было легко спарсить через утилиты cli, мне очень нравится формат логов nginx (поэтому советую присмотреться к нему). В любом случае все мониторинговые системы, будут брать данные из коллекторов логов и тд. Можно конечно написать для любимого стака отдельный коннектор, что бы вывод следовал конкретной идеологии(например что бы лог писался сразу в TSDB), но это уже как плюшка мне кажется.

Answer 6

[shurshur]

Смотря что именно логгируется и для чего используется. Например, во многих CMS (админпанели, блоги итд) существует "логгирование действий пользователей" и оно традиционно использует базу. Ибо именно из базы удобнее и проще всего через web это показывать.

Но логи для админа или разработки или службы поддержки писать в базу - это скорее всего будет плохим решением.

Также плохое решение использовать console.log. Нужно использовать специальные библиотеки для логгирования, они есть под любые развитые языки. Например, такие, как winston для node.js. Библиотки позволяют настраивать уровень логгирования, транспорт (файлы/syslog/итд), что позволит написанный один раз код потом не переделывать под другие реалии (запуск в кубере, запуск для тестов на машине разработчика итд итп).

В процессе развития и роста можно будет уже приделывать Elastic/OpenSearch, vector, greylog, logstash итд итп в зависимости от потребностей. Для пет-проекта это, скорее всего, не нужно. Но даже для пет-проекта полезно учиться правильным практикам. Чтобы потом хорошо делать в больших и сложных.