Ведение журнала сервера - в базе данных или в журнале?

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

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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

Ответ 4

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

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

Ответ 5

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

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

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

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

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

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

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

Ответ 6

На всякий случай, если вы решили настроить стандартный регистратор Python для входа в базу данных, этот рецепт может дать вам начало: Вход в учетную запись Jabber.

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

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

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

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

Ответ 10

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

Ответ 11

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