Meilleures pratiques pour la journalisation des actions des utilisateurs en production

Je prévoyais d'enregistrer beaucoup de choses différentes dans mon environnement de production, des choses comme lorsqu'un utilisateur:

• Se connecte, se déconnecte
• Change de profil
• Modifier les paramètres du compte
• Changer le mot de passe ... etc

Est-ce une bonne pratique à faire sur un environnement de production? C'est aussi un bon moyen de consigner tout cela. J'utilise actuellement le bloc de code suivant pour me connecter:

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();
            }
        }

Est-ce que ce sera ok pour la production? Mon application est très nouvelle, donc je ne m'attends pas à des millions d'utilisateurs tout de suite ou quoi que ce soit, à la recherche des meilleures pratiques pour suivre les actions sur un site Web ou si c'est même sa meilleure pratique.

Ce n'est pas une réponse directe à la question, mais plutôt une extension de celle-ci.

Lorsque vous lancez une nouvelle application, je recommande de vous connecter à tout ce que l'utilisateur fait: connectez-vous, déconnectez-vous, grattez leur a **, tout. Si elle est basée sur le Web, envisagez d'utiliser des cartes thermiques pour savoir ce que faisait leur souris.

Quand j'étais sur le projet BravoX chez Xerox à la fin des années 70, nous avons enregistré des mouvements de souris pixel par pixel pour comprendre comment les utilisateurs pourraient utiliser cette chose étrange appelée un éditeur WYSIWYG. Nous regardions les enregistrements des sessions utilisateur pendant le déjeuner. C'était extrêmement instructif. Nous avons découvert un modèle d'utilisation que nous appelions Charlie Browning - l'utilisateur sélectionnait du texte et le rendait en italique ... puis il annulait ... puis il recommençait ... d'avant en arrière, d'avant en arrière. Il s'avère qu'ils essayaient de comprendre ce genre de choses au niveau émotionnel. Nous avons donc (Greg Kusnik a fait le code, si la mémoire est bonne) mis en quelques optimisations spécifiques pour prendre en charge exactement ce comportement.

Sans l'enregistrement, nous n'aurions jamais pensé faire ça.

Si j'étais vous et que je m'en tenais à l'écriture dans un fichier texte, j'utiliserais log4net et je me connecterais dans un fichier "UserActions.log" spécifique. De cette façon, il n'embrouille pas votre journalisation normale. En utilisant log4net (ou tout autre cadre de journalisation), vous pouvez éviter de réinventer la roue et tirer parti des ajouts de fichiers roulants, avertir / erreur / déboguer / codes info, écriture de fichiers batch, etc. C'est toujours une bonne idée de créer une bonne connexion à toute application au niveau de la production.

En réalité, il est probablement préférable de stocker toutes ces informations dans une base de données. L'utilisation d'une base de données vous permettra de la trier, de l'agréger et de générer des statistiques plus facilement

Les fichiers journaux sont utilisés pour obtenir des informations sur les erreurs système de débogage. 2. pour rechercher l'activité des utilisateurs pour des méfaits, ou 3. pour comprendre comment les gens utilisent le système lorsque vous ne pouvez pas les regarder. Dans cet esprit:

• Environnement de journalisation (par exemple, vars d'environnement, autres paramètres, etc.) au démarrage de l'application. Cela est utile pour les problèmes de débogage.
• Connectez l'utilisateur et l'action (la partie distincte de l'URL) pour chaque demande.
• Enregistrez tous les paramètres pour chaque demande, SAUF pour les mots de passe. J'aime mettre des délimiteurs autour de chaque paramètre dans les journaux par exemple phone{(999)999-9999} email{[email protected]}. Les mots de passe ne doivent jamais être écrits nulle part que dans la base de données d'une manière, fonction de hachage cryptographiquement sécurisée avec un sel unique pour chaque utilisateur et plusieurs cycles de hachage (voir note de bas de page)
• Lors de la connexion, vous devez enregistrer l'adresse IP de l'utilisateur, l'ID utilisateur, le nom, le nombre d'échecs de connexion, peut-être le navigateur, peut-être l'ID de session de cookie, mais jamais le mot de passe.
• N'oubliez pas de ne pas enregistrer le mot de passe sur la page de connexion ET la page de changement de mot de passe, et vous ne devez pas enregistrer la question ou la réponse secrète si vous disposez de cette fonctionnalité. Aucun autre mot de passe ou clé de cryptage ne doit être enregistré. C'est une bonne pratique d'écrire quelque chose comme six étoiles dans le journal pour ces paramètres afin que vous puissiez voir que vous vous êtes souvenu de supprimer ces données.
• J'aime enregistrer le temps total nécessaire pour répondre à chaque demande: Done: 49ms
• J'aime enregistrer les modifications de l'état de la session. Celles-ci devraient être rares.
• Comme d'autres l'ont dit, il existe d'excellentes bibliothèques de journalisation pour la journalisation dans des fichiers, pas sûr de la journalisation dans des bases de données.
• Stockez les journaux en toute sécurité. Même sans mots de passe, il existe des lois nationales, fédérales et internationales sur les informations personnelles identifiables (voir Safe Harbor ) qui rendent les données de journal confidentielles.
• Faites des sauvegardes. Si vous les laissez couler dans une sauvegarde complète tous les soirs, n'oubliez pas de les sauvegarder ailleurs avant de passer à un nouveau serveur (ne me demandez pas comment j'ai appris cela).

Autres astuces

Note de bas de page: Pour vous connecter, hachez le mot de passe fourni avec le même algorithme de hachage et le sel du hachage d'origine pour cet utilisateur. Si le hachage du mot de passe fourni correspond au hachage de mot de passe stocké dans la base de données, ils sont connectés. Pour que cela fonctionne, vous devez définir le jeu de caractères pour votre mot de passe, interdire le caractère de substitution Unicode et tout autre caractère en dehors de votre jeu.

Vous ne spécifiez pas si vous utilisez une base de données mais si vous l'êtes et que cette base de données est SQL Server, vous pouvez ajouter quelque chose appelé AutoAudit et consigner automatiquement toutes les interactions avec vos données. Assurez-vous de ne spécifier que les objets que vous souhaitez auditer.

Mais de toute façon, je n'essaierais pas de coder manuellement mon suivi car cela finirait par un cauchemar de maintenance.

De plus, pour la journalisation, ne lancez pas le vôtre, utilisez Enterprise Library Logging ou Log4Net ou similaire.

Juste un conseil général. Peut ne pas être directement lié à votre question.

Cela dépend de quoi allez-vous utiliser les journaux? La plupart du temps, les journaux sont utilisés dans la production pour détecter les opérations qui provoquent les erreurs. Si vous les conservez pour suivre les actions de l'utilisateur, cela ne fait pas partie du journal. Cela doit être la fonction côté serveur du produit. Ces choses doivent ensuite définitivement être enregistrées dans la base de données pour une étude ultérieure. Mais les journaux côté serveur comme "Une erreur s'est produite car du texte est vide" ne font pas partie de la fonctionnalité. Ces choses doivent aller dans le système de fichiers. Ils doivent avoir le contenu suivant avec eux: - user_id, error_number, error_text, file_name, function_name, thread_id, system_date_time et tout autre contexte.

Maintenant, je ne parle que des journaux dans les fichiers.

1) Gardez-les asynchrones. Le fonctionnement des E / S est coûteux.

2) Concevez-les comme classe plutôt que fonction. Les changements futurs seront faciles.

3) Gardez-les singleton, si possible. Singleton est difficile en multi-thread, donc concevez correctement.

4) Il est également préférable de garder l'interaction entre l'enregistreur et le loggee simple. La plupart du temps, envoyez le message_number que le message_text réel et laissez l'enregistreur récupérer le message à partir du numéro. Cela sera utile si nous souhaitons ultérieurement apporter des modifications aux formats de journaux génériques.

Normalement, l'enregistreur et les éléments que nous devons enregistrer doivent faire partie de la conception. J'ai vu des cas où il y avait des changements dans la conception juste pour m'assurer que toutes les informations pertinentes sont enregistrées correctement.

Essayez Log4Net. Il vous permet de vous connecter à des fichiers ou à une base de données. Voici le tutoriel !

Nous utilisons Log4Net dans tous nos projets.

L'utilisation d'un fichier journal présente quelques problèmes. Premièrement, vous pouvez obtenir des erreurs lorsque plusieurs processus tentent d'accéder au fichier. Vous pouvez également rencontrer des problèmes lorsque vous essayez de faire défiler ou d'effacer le fichier pendant que votre système fonctionne. La solution consiste à utiliser une base de données.

Ainsi, l'étape 1 consiste à créer une table de base de données. Je suggère les champs suivants:
* userID
* action (par exemple, ouverture de session, supprimer foo) * Du
texte descriptif (autoriser les valeurs nulles ici)
* horodatage

Étape 2, créez une procédure stockée avec une entrée pour l'ID utilisateur, l'action et le texte descriptif. Utilisez simplement l'heure actuelle pour créer l'horodatage.

Étape 3, Écrivez une méthode de journalisation dans une bibliothèque partagée pratique afin qu'il soit facile de l'inclure partout et de commencer à appeler cette méthode si nécessaire. Vous pouvez également avoir une logique d'indicateur de niveau de journalisation pour modifier ce qui est consigné.

Étape 4, Créez une routine de maintenance pour effacer de temps en temps les anciens messages de la table de journalisation. Peut-être supprimer lorsque plus ancien que X, exécuter chaque semaine environ dans le cadre d'une maintenance régulière de la base de données (reconstruction d'index, etc.)

Une fois que vous avez construit ceci une fois, vous devriez pouvoir utiliser le code impliqué dans d'autres projets.