Регистрация на сервере - в базе данных или в лог-файле?

Question

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

Я планирую регистрировать некоторую базовую информацию для каждого запроса (тип запроса, IP-адрес запроса, отслеживание сеанса). Для некоторых запросов будет предоставлена ​​расширенная информация (подробности о том, какой тип запроса был сделан), и, если будут какие-либо ошибки, я тоже буду их регистрировать.

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

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

Answer 1

Во-первых, используйте библиотеку журналов, например SLF4J / Logback, которая позволяет вам принимать это решение динамически. Затем вы можете настроить файл конфигурации и направить некоторые или все ваши сообщения журнала в каждое из нескольких различных мест назначения.

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

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

Файлы журналов могут быть считаны в специальные аналитические базы данных, где вы можете использовать, например, Hadoop для сопоставления / сокращения анализа данных журналов.

Answer 2

Mix file.log + db будет лучшим. Войдите в базу данных, которую вам, возможно, потребуется проанализировать, например, среднее количество пользователей в день и т. Д. И используйте file.log для хранения отладочной информации.

Answer 3

Вход в БД только в том случае, если она приносит доход.

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

Все остальное идет в файловую систему.

Вход в файловую систему для отладки. Это вообще личное дело. Детали реализации. Не подлежит обмену.

Apache записывает множество файлов в файловую систему. Не дублируйте это.

Журналы контроля доступа отправляются в файловую систему. Вам редко захочется взглянуть на них подробно.

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

Answer 4

Если вы выберете формат файла журнала, который будет разбираться, то вы можете войти в файл и затем иметь внешний процесс (возможно, запускаемый cron), который обрабатывает ваши файлы журнала и вставляет детали в базу данных. Это можно организовать в тот момент, когда нагрузка на ваше приложение и базу данных низкая.

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

Answer 5

Мы всегда регистрировали данные в отдельной базе данных.

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

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

Logger предоставляет вам множество способов управления ведением журнала, и хотя пакет по умолчанию не имеет средства ведения журнала базы данных, написать такой обработчик событий не составит труда.

Answer 6

Похоже, что многие из вас записывают некоторые события в базу данных. Я делаю то же самое, но это добавляет немного задержки. Кто-нибудь из вас входит в базу данных через очередь сообщений? Если да, что вы используете для организации очередей и какова ваша архитектура регистрации? Я использую Java / J2EE.

Answer 7

Действительно, кажется важным, что вы можете позже переключаться между журналами БД / Файлов. Регистрация в базе данных, кажется, намного медленнее, чем регистрация в простом текстовом файле, что может стать важным при большом трафике журналов. Я сделал библиотеку (которая может действовать автономно или как обработчик), когда у меня было такое же требование. Он входит в базу данных и / или файлы и позволяет архивировать критические сообщения (и архив может, например, быть базой данных, в то время как все входит в текстовые файлы) Это может спасти вас от кодирования другого с нуля ... Смотрите: Библиотека rrlog

Answer 8

Мы делаем оба.

Мы регистрируем оперативную информацию / прогресс / и т. Д. в лог-файл. Стандартный файл журнала.

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

Answer 9

Тип ведения журнала зависит от того, что вы собираетесь делать с данными и как вы собираетесь это делать. Вход в базу данных полезен, если вы собираетесь построить систему отчетности на основе этого журнала базы данных. В противном случае вы можете регистрировать вещи в определенном формате, который вы можете проанализировать позже, если хотите использовать данные для некоторого анализа. Например, из файлового журнала вы можете анализировать только необходимую информацию и генерировать CSV по мере необходимости. Если вы планируете использовать db logger, как уже предлагалось, используйте его отдельно от вашего приложения db.

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

Answer 10

Я бы в первую очередь использовал ведение журнала в файловой системе, как рекомендует большинство других ответов. С пакетом журналирования Python вы можете легко создать обработчик базы данных, адаптировав предложение здесь . Вы также можете создать пользовательский экземпляр Filter и прикрепить его к обработчику базы данных - это позволит вам точно определить во время выполнения, какие события вы фактически записываете в базу данных. В соответствии с другими ответами, я бы сказал, что действительно стоит записать некоторые типы событий в базу данных для последующего анализа.

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