Журналы базы данных и журналы файлов
Я создал веб-приложение PHP+MYSQL и сейчас пытаюсь внедрить систему ведения журнала для хранения и отслеживания некоторых действий каждого пользователя.
Цель этого заключается в следующем: отслеживайте активность сеанса каждого пользователя, регистрируя IP+время+действие, затем смотрите, к каким страницам он обращался позже, регистрируя время+имя страницы; для каждого пользователя будет файл в формате: журнал{идентификатор пользователя}_{месяц}.журнал
Затем каждый журнал будет просматриваться только владельцем веб-сайта через пользовательская панель администратора, и данные будут использоваться только в целях безопасности (например, чтобы показать пользователю, вошел ли он с другого IP-адреса или кто-то другой вошел с другого IP-адреса, и чтобы увидеть, к каким областям веб-сайта пользователь обращался во время сеанса входа в систему).
В настоящее время у меня есть таблица MYSQL MyISAM, в которой я храню идентификатор пользователя, IP, время, действие, а приложение все еще не запущено, но у нас будет очень много пользователей (более 100 тыс.), и использование базы данных для этого решения похоже на самоубийство.
Итак, что вы предлагаете? Как следует вести протоколирование? Использование файлов, использование таблицы в текущей базе данных, использование отдельной базы данных? Существуют ли какие-либо фреймворки ведения журнала файлов, доступные для PHP?
Как тогда следует выполнять чтение файла? Прочитать результаты по строкам?
Спасибо
6 answers
У вас есть много вариантов, поэтому я расскажу о своем опыте запуска стартапа с примерно 500 тыс. пользователей, 100 тыс. активных каждый месяц, что, похоже, находится в вашем диапазоне.
Мы регистрировали действия пользователя в базе данных MySQL.
- Запрашивать ваши данные очень легко и быстро (при условии хороших индексов)
- Мы работали на Azure и имели выделенный MySQL (с ведомыми устройствами и т. Д.) Для хранения всех пользовательских данных, включая журналы. Пространство не было проблемой.
- Регистрация в MySQL может быть медленной, в зависимости от всего, что вы регистрируете, поэтому мы просто отправили журнал в Redis и попросили приложение Python прочитать его из Redis и вставить в MySQL в фоновом режиме. Это привело к тому, что ведение журнала практически не повлияло на время загрузки.
Мы решили войти в MySQL для действий пользователя, потому что:
- Мы хотели выполнять запросы по чему угодно в любое время без особых усилий. Структурированный формат журналов действий пользователей сделал это невероятно простым.
- Это также позволяет вам для отображения определенных журналов пользователям, если вам это потребуется.
- Когда мы вводили значки, нам не нужно было анализировать текстовые журналы, чтобы награждать значками тех, кто выполнил определенное действие X раз. Мы просто написали запрос к журналам действий пользователей, и значки были выданы. Таким образом, добавление функций, основанных на действиях, также было простым.
Мы использовали ведение журнала файлов для нескольких журналов приложений - или вещей, которые мы не запрашивали ежедневно, - таких как приложение Python, пишущее в база данных, доступ к веб-серверу и журналы ошибок и т.д.
Мы использовали Logstash для обработки этих журналов. Он может просто подключиться к файлу журнала и передать его на ваш сервер Logstash. Logstash также может запрашивать ваши журналы, что довольно круто.
Расширенные возможности использования
Мы использовали Slack для командной коммуникации и интегрировали с ним приложение для написания баз данных Python, это позволило нам отправлять критические ошибки на канал (через их API), где кто-то мог действовать исправьте немедленно.
Закрытие
Мое предложение состояло бы в том, чтобы не думать об этом сейчас, войти в MySQL, запросить и посмотреть статистику. Обновите, промойте и повторите. Вы хотите, чтобы цикл между развертыванием и обновлением был быстрым, поэтому принятие решений на основе быстрого SQL-запроса упрощает его.
В основном то, чего вы хотите избежать, - это войти на сервер, найти журнал и grep пройти через него, чтобы найти что-то, чего вы достигли выше.
Это то, что мы сделали, это все еще работает так, и мы не планируем менять его в ближайшее время. У нас не было никаких проблем, когда мы не могли найти ничего, что нам было нужно. Если произойдет массовый всплеск пользователей, и мы увеличим число активных пользователей до 1 миллиона в месяц, то мы можем изменить его.
Пожалуйста, обратите внимание: каким бы способом вы ни решили войти в систему, если вы сохраняете данные POST, убедитесь, что никогда не делайте этого для информации о кредитной карте, если вы не соответствуете требованиям. Или, скорее, используйте JavaScript Stripe библиотеки.
Если вы уверены, что чтение журнала будет в основном ориентировано на одного пользователя за раз, вам следует рассмотреть возможность разделения таблицы журналов: http://dev.mysql.com/doc/refman/5.1/en/partitioning-range.html использование вашего идентификатора пользователя в качестве ключа разделения.
Максимальное количество разделов 1024, у вас будет один раздел, в котором будет храниться 1/1000 из ваших 100 тыс. пользователей, что вполне разумно.
Существуют ли какие-либо фреймворки ведения журнала файлов, доступные для PHP?
Вот это доступно на packagist: https://packagist.org/packages/psr/log
Обратите внимание, что это не структура ведения журнала файлов, а API для регистратора, основанный на стандарте PSR-3 с рис. Так что, если хотите, это "стандартный" интерфейс регистратора для PHP. Вы можете создать регистратор, реализующий этот интерфейс, или выполнить поиск в packagist для других регистраторов, реализующих это интерфейс (либо файловый, либо основанный на MySQL). В packagist есть несколько других лесорубов (чайная чашка, лесное хозяйство), но было бы предпочтительнее использовать тот, который соответствует стандарту PSR.
Мы ведем журнал с помощью замечательного инструмента Graylog.
Он масштабируется так высоко, как вы хотите, имеет отличные инструменты для визуализации данных, невероятно быстр даже для сложных запросов и огромных наборов данных, а базовый механизм поиска (elasticsearch) не содержит схем. Последнее может быть преимуществом, поскольку вы получаете больше возможностей для расширения своих журналов без проблем, которые могут дать вам mysql-схемы.
Graylog, elasticsearch и mongodb (который используется для сохранения конфигурация graylog и его веб-интерфейс) легко развертываются с помощью таких инструментов, как puppet, chef и тому подобное.
На самом деле войти в graylog легко с помощью уже упомянутого монолога php-lib.
Конечно, большим недостатком здесь является то, что вам придется изучить кучу новых инструментов и программного обеспечения. Но, на мой взгляд, оно того стоит.
Суть дела в том, что данные, которые вы пишете, не будут изменены. По моему опыту в этом сценарии я бы использовал либо:
- MySQL с механизмом хранения blackhole. Установите его правильно, и он будет невероятно быстрым!
- Кластер Riak (решение NoSQL) - хотя для вас это может быть кривой обучения, в конечном итоге вам все равно может потребоваться.
Использовать системный журнал;) Настройте его на другом сервере, и он сможет регистрировать все ваши процессы отдельно (например, сеть, серверы, sql, apache и ваш php). Это может быть полезно для вас и сократить время, затрачиваемое на отладку. :)