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

Question

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

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

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

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

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

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

Спасибо

Answer 1

У вас есть много вариантов, так что я буду говорить от моего опыта работы стартапа около 50ок пользователей, 100k активного каждого месяца, который, кажется, в вашем диапазоне.

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

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

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

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

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

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

Advanced использует

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

Закрытие

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

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

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

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

Answer 2

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

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

Answer 3

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

Существует этот, который доступен на packagist: https://packagist.org/packages/psr/log

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

Answer 4

Мы ведем с отличным инструментом Graylog.

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

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

На самом деле войти в graylog легко с помощью упомянутого выше php-lib monolog.

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

Answer 5

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

Answer 6

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

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