Лучшие практики для регистрации действий пользователя в производстве

Я планировал регистрировать много разных вещей в моей производственной среде, например, когда пользователь:

• Вход в систему, выход из системы
• Изменить профиль
• Изменить настройки аккаунта
• Изменить пароль ... и т. Д.

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

public void LogMessageToFile(string msg)
        {

            System.IO.StreamWriter sw = System.IO.File.AppendText(
                GetTempPath() + @"MyLogFile.txt");
            try
            {
                string logLine = System.String.Format(
                    "{0:G}: {1}.", System.DateTime.Now, msg);
                sw.WriteLine(logLine);
            }
            finally
            {
                sw.Close();
            }
        }

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

Это не прямой ответ на вопрос, а скорее его расширение.

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

Когда я работал над проектом BravoX в Xerox в конце 70-х, мы записывали попиксельные движения мыши, чтобы выяснить, как пользователи могут использовать эту странную вещь, называемую WYSIWYG-редактор. Мы будем наблюдать за воспроизведением пользовательских сессий во время обеда. Это было чрезвычайно поучительно. Мы обнаружили шаблон использования, который мы назвали Чарли Браунинг - пользователь выбирал какой-то текст и делал его курсивом ... затем он отменял ... потом он повторял ... взад-вперед, взад-вперед. Оказывается, они пытались понять это на эмоциональном уровне. Таким образом, мы (Грег Кусник сделал код, если память не изменяет) добавили некоторые специфические оптимизации для поддержки именно этого поведения.

Без записи мы бы никогда не подумали сделать это.

Если бы я был вами, и я придерживался записи в текстовый файл, я бы использовал log4net и входил в определенный файл «UserActions.log». Таким образом, это не мешает вашей обычной регистрации. Используя log4net (или любую другую инфраструктуру ведения журналов), вы можете избежать повторного изобретения колеса и использовать приложения для прокручивания файлов, коды предупреждений / ошибок / отладки / информации, записи пакетных файлов и т. Д. Всегда хорошая идея встроить хороший вход в систему. приложение любого уровня производства.

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

Файлы журналов используются 1. для получения информации об отладке системных ошибок. 2. исследовать действия пользователя на предмет вреда или 3. понять, как люди используют систему, когда вы не можете смотреть их. С этим в мыслях:

• Записывать среду (например, переменные среды, другие настройки и т. Д.) При запуске приложения. Это полезно для устранения проблем.
• Зарегистрируйте пользователя и действие (отдельную часть URL) для каждого запроса.
• Записать все параметры для каждого запроса, КРОМЕ паролей. Мне нравится помещать разделители вокруг каждого параметра в журналах, например phone{(999)999-9999} email{aaa@aaa.com}. Пароли никогда не должны быть написаны в любом месте кроме как в базу данных, одним способом, криптографически защищенной хеш-функцией с уникальной солью для каждого пользователя и несколькими раундами хеширования (см. Сноску)
• При входе в систему вы должны регистрировать IP-адрес пользователя, идентификатор пользователя, имя, количество неудачных входов в систему, возможно, браузер, может быть идентификатор сеанса cookie, но не пароль.
• Не забудьте не регистрировать пароль на странице входа И на странице смены пароля, также вы не должны регистрировать секретный вопрос или ответ, если у вас есть такая функциональность. Любые другие пароли или ключи шифрования не должны регистрироваться. Рекомендуется записывать что-то вроде шести звездочек в журнал для этих параметров, чтобы вы могли видеть, что вы помните, чтобы скрыть эти данные.
• Мне нравится регистрировать общее время, необходимое для обработки каждого запроса: Done: 49ms
• Мне нравится регистрировать изменения в состоянии сеанса. Это должно быть редко.
• Как говорили другие, существуют отличные библиотеки для ведения журналов в файлах, не совсем уверенные в том, что они ведут в базы данных.
• Храните журналы надежно. Даже без паролей существуют законы штата, федеральные и международные законы о персонально идентифицируемой информации (см. Safe Harbor ), делающие данные журналов конфиденциальными.
• Возьмите резервные копии. Если вы позволяете им создавать резервные копии на все диски каждую ночь, не забудьте сохранить их в другом месте перед обновлением до нового сервера (не спрашивайте меня, как я это узнал).

Другие советы

Сноска. Чтобы войти в систему, хешируйте предоставленный пароль с тем же алгоритмом хеширования и солью из исходного хеша для этого пользователя. Если хэш предоставленного пароля совпадает с хэшем пароля, хранящимся в базе данных, он регистрируется в системе. Чтобы это работало, вы должны определить набор символов для вашего пароля, запретить символ замены Unicode и любые другие символы за пределами вашего набора.

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

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

Кроме того, для ведения журнала не сверните свои собственные, используйте ведение журнала Enterprise Library или Log4Net или аналогичные.

Просто общий совет. Может не иметь прямого отношения к вашему вопросу.

Это зависит от того, для чего вы собираетесь использовать логи? В основном журналы используются в производстве для обнаружения операций, которые вызывают ошибки. Если вы храните их для отслеживания действий пользователя, то это не является частью журнала. Это должно быть особенностью продукта на стороне сервера. Эти вещи тогда определенно должны войти в базу данных для дальнейшего изучения. Но журналы на стороне сервера, такие как «Произошла ошибка из-за пустого текста», не являются частью этой функции. Эти вещи должны идти в файловой системе. Они должны иметь следующее содержимое: - user_id, error_number, error_text, file_name, function_name, thread_id, system_date_time и любой другой контекст.

Сейчас я говорю только о логах в файлах.

1) Держите их асинхронными. Операция ввода / вывода является дорогостоящей.

2) Разработайте их как класс, а не как функцию. Будущие изменения будут легкими.

3) Держите их по одному, если это возможно. Синглтон сложен в многопоточности, поэтому проектируйте правильно.

4) Также лучше сохранить взаимодействие между logger и loggee простым. Большую часть времени отправьте message_number, чем фактический message_text, и позвольте регистратору получить сообщение с номера. Это поможет, если позже мы захотим внести изменения в общие форматы журналов.

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

Попробуйте Log4Net. Он позволяет вам войти в файлы или базу данных. Вот учебник !

Мы используем Log4Net во всех наших проектах.

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

Итак, шаг 1 - создать таблицу базы данных. Я предлагаю следующие поля:
* userID
* action (например, вход в систему, delete foo)
* Некоторый описательный текст (здесь разрешены нули)
* timestamp

Шаг 2. Создайте хранимую процедуру с вводом идентификатора пользователя, действия и описательного текста. Просто используйте текущее время, чтобы создать отметку времени.

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

Шаг 4. Создайте процедуру обслуживания, чтобы время от времени удалять старые сообщения из таблицы журналов. Возможно, удаляйте, когда старше X, запускайте каждую неделю или около того, как часть регулярного обслуживания БД (перестройка индекса и т. Д.).

Как только вы построите это один раз, вы сможете использовать код, используемый в других проектах.