Кращі практики реєстрації дій користувачів у виробництві

Я планував вносити багато різних речей у моє виробниче середовище, такі речі, як користувач:

• Вхід, журнали вимкнено
• Змінити профіль
• Редагування налаштувань облікового запису
• Змінення пароля ... тощо

Це хороша практика робити виробничі умови? Також який хороший спосіб занести все це. Зараз я використовую наступний блок коду для входу в систему:

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
• Мені подобається вносити зміни до стану сеансу. Вони повинні бути рідкісними.
• Як говорили інші, тут є чудові бібліотеки для реєстрації файлів, не впевнені в реєстрації в базах даних.
• Зберігайте журнали надійно. Навіть без паролів існують державне, федеральне та міжнародне законодавство про персональну інформацію (див. Безпечний порт) ), що робить дані журналу конфіденційними.
• Зробіть резервні копії. Якщо ви дозволяєте їм переходити в резервну копію повного диска щовечора, не забудьте запам'ятати їх де-небудь ще до оновлення до нового сервера (не питайте, як я це дізнався).

Інші поради

Примітка. Щоб увійти до когось, введіть хеш наданого пароля з тим же алгоритмом хешування та сіль з оригінального хеша для цього користувача. Якщо хеш наданого пароля відповідає хешу паролів, що зберігається в базі даних, тоді вони ввійшли.

Ви не вказуєте, чи використовуєте ви базу даних, але якщо ви є, і це база даних - SQL Server, ви можете додати щось, що називається AutoAudit, і автоматично записувати всі взаємодії зі своїми даними. Просто переконайтеся, що вкажіть лише ті об’єкти, які ви хочете перевірити.

Але я б не намагався вручну зашифрувати моє відстеження, оскільки це закінчиться кошмаром технічного обслуговування.

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

Просто загальна порада. Може не мати прямого відношення до вашого питання.

Це залежить від того, для чого ви збираєтеся використовувати журнали? В основному журнали використовуються у виробництві для виявлення операцій, що викликають помилки. Якщо ви зберігаєте їх для відстеження дій користувача, це не є частиною журналу. Це має бути особливістю сервера продукту. Тоді ці речі, безумовно, повинні зайти в базу даних для подальшого вивчення. Але журнали на стороні сервера типу "Помилка сталася, коли деякий текст порожній", не є частиною функції. Ці речі потрібно пройти у файловій системі. У них повинен бути такий вміст: - user_id, error_number, error_text, file_name, function_name, thread_id, system_date_time та будь-який інший контекст.

Зараз я кажу лише про журнали у файлах.

1) Тримайте їх асинхронними. Операція вводу / виводу коштує дорого.

2) Сконструюйте їх як клас, ніж функцію. Майбутні зміни будуть легкими.

3) Тримайте їх одноразово, якщо можливо. Однотонний складний у багатопотокових, тому розробляти правильно.

4) Також краще, щоб взаємодія між реєстратором та лоджею була простою. Більшу частину часу надсилає повідомлення_кілька, ніж фактичне message_text, і нехай реєстратор отримає повідомлення від номера. Це допоможе, якщо пізніше ми хочемо внести зміни у загальні формати журналу.

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

Спробуйте Log4Net.Позволяє входити у файли чи базу даних. Ось Підручник !

Ми використовуємо Log4Net у всіх наших проектах.

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

Отже, крок 1 - створити таблицю бази даних. Я пропоную наступні поля:
* userID
* дія (наприклад, вхід, видалення foo)
* деякий описовий текст (дозволити тут нулі)
* часова мітка

Крок 2: Створіть збережену процедуру з введенням для користувача ID, дії та описового тексту. Просто використовуйте поточний час, щоб створити штамп часу.

Крок 3: Напишіть метод журналу в зручну спільну бібліотеку, щоб його було легко включити скрізь і ввійти в практику виклику цього методу за необхідності. Можливо, ви хочете мати логіку прапора рівня реєстрації, а також змінити те, що входить у систему.

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

Після того, як ви створили це один раз, ви повинні мати можливість використовувати код, що бере участь в інших проектах.