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

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

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

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

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

11 Solutions collect form web for “Ведение журнала сервера – в базе данных или в журнале?”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Python - лучший язык программирования в мире.