#django #logging #ip-address #trace
#django #протоколирование #ip-адрес #трассировка
Вопрос:
Я хочу отслеживать действия пользователя на моем веб-сайте, регистрируя их запросы в базу данных в виде обычного текста в Django.
Я считаю, что нужно написать пользовательский декоратор и поместить его в каждое представление, которое я хочу отслеживать. Однако у меня есть некоторые проблемы в моем дизайне. Прежде всего, является ли такое ведение журнала mecahinsm разумным или из-за того, что моя таблица журналов будет быстро увеличиваться, это вызывает некоторые проблемы с подготовкой? Во-вторых, каким должен быть дизайн моей таблицы журналов?
Я хочу сохранить ключевые слова, если пользователь вызывает search
представление, или сохранить идентификатор элемента, если пользователь вызывает details of item
представление. Кроме того, IP-адреса пользователей должны быть сохранены, но как я могу отделить пользователей, если они подключаются через один IP-адрес, как во многих компаниях.
Я рад подробно объяснить, если вы считаете, что мой вопрос неясен.
Спасибо
Ответ №1:
Я бы этого не сделал. Если это производственная служба, то перед ней работает надлежащий веб-сервер, верно? Apache, или nginx, или что-то в этом роде. Это может выполнять ведение журнала, и может делать это хорошо, и может записывать в форму, которая не будет раздувать вашу базу данных, и есть множество аналитических инструментов для анализа журналов.
Вам придется дублировать многие из этих функций в вашем декораторе, например, когда вы хотите включить или выключить его или изменить уровень журнала. Единственное, что вы получите, делая все это в django, — это возможность сверхтонкого контроля, например, регистрировать только просмотры сообщений в блогах с номерами идентификаторов больше X или что-то в этом роде. Но, как правило, вам не нужен такой уровень детализации, и вы бы регистрировали все и выполняли любую очистку на этапе анализа. В настоящее время вы не указали никаких причин, по которым вам нужно сделать это из Django.
Если вы действительно хотите это в СУБД, чтение файла журнала apache в Postgres или MySQL или один из этих дорогостоящих довольно тривиально.
Ответ №2:
Одна вещь, которую вы должны иметь в виду, это то, что базы данных SQL не обеспечивают вам очень хорошую производительность записи (по сравнению с чтением), поэтому, если вы испытываете большие нагрузки, вам, вероятно, следует поискать лучшее решение в памяти (например, какое-нибудь хранилище ключей-значений, такое как redis).
Но имейте в виду, что, особенно если вы будете использовать решение, отличное от sql, вы должны знать, что вы хотите делать с собранными данными (просто отобразите что-то вроде «журнала» или выполните более глубокий поиск / запрос данных).
Если вы хотите идентифицировать разных пользователей с одного и того же IP-адреса, вам, вероятно, следует искать решение на основе файлов cookie (если вы используете структуру сеансов django, сеансы по умолчанию идентифицируются через файл cookie, поэтому вы можете просто использовать сеансы). Другим решением может быть ведение журнала «асинхронно» через javascript после загрузки страницы в браузере (что может дать вам больше возможностей для идентификации пользователя и избежать дополнительной нагрузки при создании страницы).