Вход в базу данных вместо файлов журналов

Я заинтересован в отправке всего журнала приложений Rails в базу данных (MySQL или MongoDB) либо в дополнение, либо вместо файла журнала. Существует несколько причин, большинство из которых связаны с анализом файла журнала. Мы уже используем Google Analytics, но есть много вещей, которые мы хотим сделать, которые не работают в Google Analytics.

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

Наконец, я часто хочу изучить что-то ближе к поведению посетителя сайта: например, трассировка пути через сайт, чтобы я мог видеть, что на последней странице было, что пользователь просматривал до возникновения ошибки. Учитывая, что у нас есть несколько серверов приложений, отдельные файлы журналов делают эту реальную боль. Если все данные были в базе данных, я мог бы легко увидеть правильную последовательность страниц для данного посетителя. Я знаю, что Syslog будет одним из способов решить эту проблему (один файл/репозиторий журнала), но я хочу объединить это с лучшими способностями поиска, которые я связываю с поиском в базе данных.

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

В настоящее время я определяю, на каком уровне мне нужен этот журнал, потому что еще одна вещь, на которую я смотрел, - это написать небольшой фильтр Rack, который регистрирует все запросы. Это пропустит весь дополнительный вывод, из которого выгружается нормальное ведение журнала Rails (все SQL и вывод на кеш-хиты и промахи и т.д.), Но он достиг бы значительной части моей цели и, похоже, имеет преимущество не беспокоить что-нибудь еще в системе.

Во всяком случае, я не ищу ни одного правильного ответа, больше обсуждения и информации о том, что кто-то еще может делать в этом же свете.

ОТВЕТЫ

Ответ 1

Моя компания регистрирует некоторую структурированную информацию о трафике прямо в базе данных журнала MySQL. Эта база данных реплицируется вниз по течению в другую базу данных. Все аналитики завершают окончательную репликацию базы данных. Наш сайт поддерживает довольно много трафика. Пока что у него нет серьезных проблем. Тем не менее, наш ИТ-отдел имеет некоторые растущие опасения относительно масштабируемости текущей настройки и предполагает, что мы выгружаем информацию журнала в "правильные" лог файлы. Затем лог файлы будут повторно вставлены в те же таблицы базы данных вниз по течению. Это подводит меня к этому вопросу.:)

Вот некоторые из плюсов и минусов, которые я вижу относительно темы журнальных файлов и log-db (реляционных):

  • log файлы бывают быстрыми, надежными и масштабируемыми (по крайней мере, я слышал, что Yahoo! делает тяжелое использование файлов журналов для их аналитики отслеживания кликов).
  • Лог файлы легко поддерживать sys-admin.
  • log файлы могут быть очень гибкими, поскольку вы можете писать почти что-нибудь.
  • log файлы требуют интенсивного анализа и, возможно, настройки типа с уменьшенным отображением для извлечения данных.
  • Структуры log-db намного ближе к вашему приложению, что делает некоторые функции более быстрыми. Это может быть благословением или бичем. Вероятно, проклятие в долгосрочной перспективе, так как вы, скорее всего, окажетесь с очень сложной прикладной и аналитической базой кода.
  • log-db может уменьшить шумы и избыточность регистрации, так как log файлы вставляются только там, где log-db дает вам возможность выполнять обновление и ассоциированную вставку (нормализация, если вы смеете).
  • log-db может быть быстрым и масштабируемым, если вы идете с разделением базы данных и/или несколькими журнальными базами данных (воссоединяйте данные с помощью последующих реплик)

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

Недавно я изучал некоторые базы данных на основе ключа/документа, такие как Redis, Tokyo Cabinet и MongoDB. Эти быстро вставляемые базы данных потенциально могут быть сладким пятном, поскольку они обеспечивают постоянство, высокую (запись) пропускную способность и возможности запросов в разной степени. Они могут сделать процесс извлечения данных намного проще, чем синтаксический анализ и уменьшение количества карт на гигабайтах журнальных файлов.

В долгосрочной перспективе я считаю крайне важным иметь надежный склад данных аналитики. Освобождение данных приложений от аналитических данных и наоборот может быть большим WIN.

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

Edit:

rsyslog выглядит очень интересно. Это дает вам возможность напрямую писать в MySQL. Если вы используете Ruby, вам следует взглянуть на журнал регистрации. Он обеспечивает многозадачные возможности ведения журнала. Это действительно приятно.

Ответ 2

Если вы хотите изменить поведение журнала по умолчанию, просто создайте пользовательский объект журнала, который будет отвечать на все методы журнала Rails:

  • добавить
  • debug, warn, error, info, fatal, unknown

http://github.com/rails/rails/blob/9d7aae710384fb5f04129c35b86c5ea5fb9d83a9/activesupport/lib/active_support/buffered_logger.rb

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

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

ActiveRecord::Base.logger = YouLogger.new

Вы можете легко создать файл инициализации с именем logger.rb и записать там все свои пользовательские конфигурации. Таким образом, регистратор будет немедленно заменен при запуске Rails.

Ответ 3

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

Ответ 4

Крис

Думаю, комментарий Димы здесь важен. Довольны ли вы (1) наличием журнала доступа в БД (в режиме реального времени) или (2), вас больше интересует ведение журнала Rails/app?

Для (1), с Apache (по крайней мере), вы можете выполнить вход в базу данных, используя журналирование по каналам.

http://httpd.apache.org/docs/1.3/logs.html#piped

Я написал программу, которая работает в фоновом режиме, ожидая ввода, который он анализирует и записывает в БД Postgres. Мои файлы httpd.conf для этой программы с помощью директивы CustomLog.

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

Для (2) я не разработчик Rails, поэтому я могу говорить только об общих подходах. Если вы хотите регистрировать данные об окружающей среде или данные приложения или очень выборочные биты информации, вы можете рассмотреть возможность создания модуля веб-сервера. В зависимости от ваших конкретных потребностей вы также можете получить некоторую комбинацию условных правил ведения журнала и фильтрации в программе ведения журнала.

На самом деле все зависит от того, нужно ли вам решение, специфичное для Rails, или более общее решение для всего веб-сервера.

Ответ 5

пока до сих пор не был принят ответ, я дам свой вклад

Я разработал плагин для rsylog, чтобы сохранить журналы не в файлах, а в mongodb

весь исходный код, из rsyslog + плагин здесь https://github.com/vpereira/rsyslogd-mongo

чтобы скомпилировать его, вы должны просто запустить. /configure --help и просмотреть доступные параметры.

Ответ 6

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

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

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