Целесообразно ли логирование выносить в отдельную базу?

Question

[Друг]

Сейчас мы начали отслеживать изменение любых моделей и логировать это в базу данных. Например, отслеживать все действия пользователя. База пухнет и для бэкэнд разработчика выкачивать дамп базы для локальной разработки становится проблемой. Да и основную базу подвергать лишней нагрузке тоже нежелательно.

Целесообразно ли вести логирование в отдельной базе данных?
В данной ситуации у нас используется Laravel

Comments

[Александр Аксентьев]

Вы что-то неправильно делаете раз вам надо выкачивать дампы продакшна, да ещё и часто раз это стало надоедать.

[Slava Rozhnev]

Пишите логи в файлы или в MongoDB

[HellWalk]

Зависит от многих параметров, банально - на сколько закрыт весь тех.долг, и на сколько есть свободное время.

Если техдолга нет (тесты написаты, документация написана, костылей нет, CI/CD настроен) и есть время - можно заморочиться с отдельным хранилищем для логов. Если же есть техдолг - я бы занялся лучше им, а логи можно вынести и потом, когда, например, база будет не справляться от нагрузки. Но тут от самой нагрузки зависит, если у вас 5 пользователей в сутки - это через 10 лет может случиться, или не случиться вовсе.

[FanatPHP]

Давно на тостере не было вопросов, от которых волосы на голове дыбом.
Причем как от вопроса, так и от ответов.

Вопрос, конечно, и сам в первую очередь гениальный, системы "зачем мне холодильник, если я не курю?". В огороде бузина, а в Киеве дядька. Смешались в кучу логи, модели, ларавели, дампы. И особенно умиляет судьба нищастного бэкенд разработчика.
Но что самое смешное - в нем нет самого главного - как потом эти логи используются? Отображаются ли в интерфейсе? Делается ли по ним поиск? Насколько отображение завязано на остальную информацию из БД? Используются ли эти логи хоть как-то вообще?

Ну и ответы - в стиле Тостера, "я не гинеколог, я сантехник, но вот моё экспертное мнение!"

[Друг]

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

[FanatPHP]

что значит "просто"? Что значит "не зависит"? Пользователь удалил товар из раздела. В лог пишется емейл пользователя и названия товара и раздела? или всё-таки ид пользователя, товара и раздела? Если второе, то откуда брать информацию по этим id?

Answer 1

[Gennady S]

А в чем загвоздка? Проблем с этим нет, если журналы грузят базу, то используйте отдельную. И даже не классическую базу, а MongoDB, например, или иные инструменты.

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

Comments

[FanatPHP]

осталось узнать, каким местом хранение логов в in-memory датабазе решит хоть одну проблему автора
философы такие философы

[Gennady S]

FanatPHP, what? MongoDB — не база в памяти (и что за язык: "in-memory датабазе", это должно выглядеть оригинально, эпатажно, забавно или что?).

К ответу на вопрос. Ничего не решит, речь лишь о том, что можно использовать любой инструмент (чтобы автор вопроса посмотрел шире, чем на возможный выход из одного пространства в другое, в рамках одной физической СУБД на одном физическом сервере).

PS К слову, MongoDB шустрая при записи больших объемов информации и поэтому довольно часто используется как инструмент журналирования.

Answer 2

[Дмитрий Свиридов]

Можете создать слейв-реплику - и дамп снимать с неё. Тогда нагрузки на прод не будет. Другое дело, что вообще не ясно, почему для локальной разработки разработчикам разрешается снимать дамп прода. У разработчиков туда вообще по-хорошему доступа быть не должно (только у ответственных лиц). Для локальной разработки должен быть специально подготовлен дамп, причём желательно чтобы в нём были ненастоящие данные или обезличенные (например, имейлы пользователей заменены на фейковые).

Comments

[FanatPHP]

блин, вы каким все местом читаете?
нагрузка не при снятии дампа, а при логировании. много запросов на вставку.

[Vitsliputsli]

FanatPHP, так ведь в вопросе значится "Сейчас мы начали отслеживать изменение любых моделей и логировать это в базу данных. Например, отслеживать все действия пользователя. База пухнет и для бэкэнд разработчика выкачивать дамп базы для локальной разработки становится проблемой".
Т.е. проблема именно в создании дампа продакшен сервера со всеми данными для использования в локальной разработке.

Дмитрий Свиридов, дамп обезличенных продовых данных - это хорошо, но это нужно для тестирования, для проверки поведения на реальных продовых данных, а не для разработки.

[Дмитрий Свиридов]

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

[Дмитрий Свиридов]

FanatPHP, лично я того, что вы пишете, в вопросе не вижу.

[Друг]

почему это разработчику нельзя снимать дамп рабочей базы? а как же отлавливание багов? Разработчик целый день сидит в дебагере и отлавливает баги повторяя путь который проделал пользователь.

[Vitsliputsli]

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

Answer 3

[Алекс Белов]

Наверное в целом вести логи в SQL БД не очень задумка.

Порекомендую Вам MongoDB. Это no-SQL решение, в целом ориентированное как раз на регистрацию событий. Меньше нагрузки на сервер, меньше проблем с деплоем обновлений на прод.

Comments

[FanatPHP]

ещё один видный теоретик
с каких пор свалка системы "вали все в кучу", которая встаёт колом если не влезает целиком в оперативную память, стала "системой регистрации событий"?

[FanatPHP]

Я конечно понимаю, что как-то глупо задавать вопросы человеку, который сам себя называет программистом нетрадиционной ориентации.
Но я тут посмотрел, вы другим рекламируете свою "CMS", и я не могу удержаться от вопроса: скажите, вы хоть когда-нибудь слышали такое словосочетание, "sql инъекция"? Ну может быть краем уха хотя бы?

[Алекс Белов]

FanatPHP, Встречный вопрос... Вы пользовались MongoDB?

[Алекс Белов]

FanatPHP, В унисон второму комментарию... Не мог не заметить, что Вы всех считаете тупыми. Это говорит о Вас больше чем Вам могло бы показаться.

Если я или мои ответы, или мой код Вам не нравиться - работайте над собой. (:

[FanatPHP]

Не всех. Но людей, которые в 2021 пишут код, за который было бы стыдно в 2001 и не видят в этом проблемы - определённо

[Алекс Белов]

FanatPHP, забавно читать замечания про код от человека который в примерах приводит код со смешанной логикой и представлением...

P.S. Вы к почти к каждому ответу оставили комментарий, где всем пытались доказать, что вы тут самый умный... Заспамить Вы конечно умеете... Но вот, что до "самого"... то пока что вы победитель в номинации "затычка" https://ru.wiktionary.org/wiki/%D0%B2_%D0%BA%D0%B0...

[FanatPHP]

Номинация пишется через "о".

Вы что сказать-то хотели? Что уже исправили инъекции?

[Алекс Белов]

FanatPHP, Вы только что подтвердили своё участие в номинации %)

P.S. А что до иньекций то вы сначала попробуйте, а потом уж поднимайте крик ;)

[FanatPHP]

пентест денег стоит. оплатите- я найду вам уязвимости

я посмотрел код, этого достаточно. по коду там инъекция на инъекции и инъекцией погоняет
если вы себя успокаиваете, воткнув где-то костыль типа тех, которые ищут слово union во входящих данных, то мне вас жалко.
а уж пользователей этой дырявой поделки - тем более. потому что им-то про ваши костыли ничего неизвестно, они просто используют код

Answer 4

[Кирилл Горелов]

ЧТо-то никто не предлагает крутой вариант с иластиком....
Буду первым.

Comments

[FanatPHP]

а каким местом тут поисковый индекс?

[Кирилл Горелов]

FanatPHP, не обязательно его использовать как для поиска, хотя наверняка для проверок логов сам поиск и потребуется.Он так же отлично справится и с хранением самих логов.

Я где читал кейс, парни иластик прикручивали к битриксу, для хранения товаров. Так что и для логов, я думаю подойдет...

[FanatPHP]

чтобы поисковый индекс к чему-то прикрутить, это то что-то должно существовать в природе.
"прикрутить эластик к битриксу" - это не какая-то гениальная военная хитрость, а самый стандартный юзкейс.
потому что в битриксе УЖЕ есть товары, которые индексируются эластиком.
В эластик, если что, не пишут данные - он сам их читает. Если они есть.

а у автора логов ещё нет. индексировать нечего. читать неоткуда.

[Vitsliputsli]

FanatPHP, в Эластик вполне пишут данные, через его API. Для логов это не нужно, гораздо эффективней, чтобы он сам их парсил, но в принципе писать можно.

[Vitsliputsli]

Т.е. стандартный вариант: пишем логи просто в файл, чтобы было удобно читать запускаем какую-нибудь Кибану в связке с Эластиком, который будет парсить файл лога и предоставлять поиск.
Но это просто вариант, как автор предполагает использовать лог неизвестно.

[Друг]

Vitsliputsli, кибана жрет много ресурса.

[Vitsliputsli]

Друг, жрет много относительно чего? К примеру, PHPStorm тоже не мало жрет, но выбираем его и без вариантов.
Это всего лишь вариант, все дело в том, что нужно конкретно вам. Для кого-то эти "много ресурса" мелочи окупающиеся удобством, а кто-то будет мучиться с grep, чтобы не потратить лишний Гб памяти.

Answer 5

[Vitsliputsli]

Для разработки база должна разворачиваться из миграций, т.е. не должно быть никакой зависимости от прода. Если не используете их, то пора начать. Чтобы не писать их все с нуля, создайте дамп структуры и разворачивайте его, а новые изменения уже в миграциях. Необходимые для разработки и тестирования данные заполняйте фикстурами.
Что касается логов в базе, то нужно понимать, как вы их используете, и уже исходя из этого выбирать решение.