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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

---

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

• Хранение многих файлов журнала
• Является ли запись файлов журнала сервера в базу данных хорошей идеей?
• Использование SQL Server для регистрации приложений. Плюсы / минусы?
• Быстрый поиск в логах
• Отдельная производственная база данных для ведения журнала
• Вы входите в свою БД, где вы регистрируетесь, когда ваша БД не работает?

---

Edit:

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

Answer 2

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

• добавить
• отладка, предупреждение, ошибка, информация, фатальный, неизвестный

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

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

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

ActiveRecord::Base.logger = YouLogger.new

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

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

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

Answer 6

Крис,

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

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

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

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

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

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

В действительности все сводится к тому, нужно ли вам решение для Rails или более общее решение для всего веб-сервера.