Журналы базы данных и журналы файлов

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

Цель этого заключается в следующем: отслеживать активность каждого пользовательского сеанса, регистрируя IP + время + действие, а затем просматривать страницы, к которым он обратился позже, путем ведения журнала + pagename; для каждого пользователя будет файл в формате: log {userid} _ {month}.log

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

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

Итак, что вы предлагаете? Как вести регистрацию? Используя файлы, используя таблицу в текущей базе данных, используя отдельную базу данных? Существуют ли какие-либо фреймворки файлов для PHP?

Как следует читать файл? Прочитать результаты по строке?

Спасибо

Ответ 1

У вас есть много вариантов, поэтому я расскажу из своего опыта, запускающего запуск с примерно 500 тыс. пользователей, каждый месяц активен в 100 тыс., что, кажется, находится в вашем диапазоне.

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

  • Запрос ваших данных очень прост и быстр (при условии хороших индексов)
  • Мы выполнили Azure и имели специальный MySQL (с ведомыми устройствами и т.д.) для хранения всех пользовательских данных, включая журналы. Пространство не было проблемой.
  • Вход в MySQL может быть медленным, в зависимости от всего, что вы регистрируете, поэтому мы просто нажали журнал на Redis и имели Приложение Python читает его из Redis и вставляет в MySQL в фоновом режиме. Это привело к тому, что регистрация в основном не влияла на время загрузки.

Мы решили войти в MySQL для действий пользователя, потому что:

  • Мы хотели запускать запросы на что-либо в любое время без особых усилий. Структурированный формат журналов действий пользователя сделал это невероятно легко.
  • Он также позволяет отображать определенные журналы для пользователей, если потребуется.
  • Когда мы вводили значки, нам не нужно было разбирать текстовые журналы, чтобы награждать значки тем, кто выполнял определенное действие X раз. Мы просто написали запрос к журналам действий пользователя, и были отмечены значки. Поэтому добавление функций, основанных на действиях, было простым.

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

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

Расширенное использование

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

Закрытие

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

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

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

Обратите внимание на: какой бы способ вы ни выбрали, если вы сохраняете данные POST, обязательно не делайте этого для информации о кредитной карте, если только вы не согласны. Или скорее используйте Stripe библиотеки JavaScript.

Ответ 2

Если вы уверены, что чтение журнала будет в основном нацелено на одного пользователя за раз, вы должны подумать о том, чтобы разделить свою таблицу журналов: http://dev.mysql.com/doc/refman/5.1/en/partitioning-range.html используя ваш user_id в качестве ключа секционирования.

Максимальное количество разделов - 1024, у вас будет один раздел, в котором будет храниться 1/1000 ваших пользователей в 100 тыс., что является чем-то разумным.

Ответ 3

Существуют ли какие-либо фреймворки файлов для PHP?

Это доступно в пакете: https://packagist.org/packages/psr/log

Обратите внимание, что это не среда регистрации файлов, а API для регистратора на основе стандарта PSR-3 из фиг. Итак, если вам нравится, это "стандартный" логический интерфейс для PHP. Вы можете создать регистратор, который реализует этот интерфейс или выполняет поиск в packagist для других регистраторов, которые реализуют этот интерфейс (как на базе файлов, так и на основе MySQL). Есть несколько других регистраторов на упаковке (чаша, лесное хозяйство), но было бы предпочтительнее использовать тот, который придерживается стандарта PSR.

Ответ 4

Мы ведем журнал с помощью отличного инструмента Graylog.

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

Graylog, elasticsearch и mongodb (который используется для сохранения конфигурации graylog и его веб-интерфейса) легко развертываются с помощью таких инструментов, как марионетка, шеф-повар и т.д.

Фактически запись в graylog легко с помощью уже упомянутого монологи php-lib.

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

Ответ 5

Суть в том, что данные, которые вы пишете, не будут изменены. По моему опыту в этом сценарии я бы использовал либо:

  • MySQL с движком хранения черной дыры. Установите его правильно и быстро, быстро!
  • Riak Cluster (решение NoSQL) - хотя это может быть кривая обучения для вас, это может быть одно, что вам, возможно, понадобится в конечном итоге.

Ответ 6

Использовать SysLog;) Настройте его на другом сервере, и он может регистрировать все ваши процессы отдельно (например, сети, серверы, sql, apache и ваш php). Это может быть полезно для вас и сократить время отладки.:)