Best practice per la registrazione delle azioni dell'utente in produzione

Avevo intenzione di registrare molte cose diverse nel mio ambiente di produzione, ad esempio quando un utente:

• Accede, disconnette
• Cambia profilo
• Modifica impostazioni account
• Cambia password ... ecc

È una buona pratica da fare in un ambiente di produzione? Inoltre, qual è un buon modo per registrare tutto questo. Attualmente sto utilizzando il seguente blocco di codice per accedere a:

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

Andrà bene per la produzione? La mia applicazione è molto nuova, quindi non mi aspetto che milioni di utenti subito o niente, cercando le migliori pratiche per tenere traccia delle azioni su un sito Web o se anche le sue migliori pratiche.

Questa non è una risposta diretta alla domanda, piuttosto un'espansione su di essa.

Quando avvii una nuova app, ti consiglio di accedere a tutto ciò che l'utente fa: accedi, esci, gratta un **, tutto. Se è basato sul web, considera l'utilizzo di mappe di calore in modo da sapere cosa stava facendo il mouse.

Quando ero al progetto BravoX di Xerox alla fine degli anni '70, abbiamo registrato i movimenti del mouse pixel per pixel per capire come gli utenti potevano usare questa strana cosa chiamata editor WYSIWYG. Guardavamo le riproduzioni delle sessioni degli utenti durante il pranzo. È stato estremamente istruttivo. Scoprimmo un modello d'uso che chiamavamo Charlie Browning: l'utente selezionava del testo e lo rendeva in corsivo ... quindi annullava ... quindi ripeteva ... avanti e indietro, avanti e indietro. Si scopre che stavano cercando di capire queste cose a livello emotivo. Quindi noi (Greg Kusnik ha fatto il codice, se la memoria serve) abbiamo inserito alcune ottimizzazioni specifiche per supportare esattamente questo comportamento.

Senza la registrazione non avremmo mai pensato di farlo.

Se fossi in te e continuassi a scrivere su un file di testo, userei log4net e accederei a un file "UserActions.log" specifico. In questo modo non confonde la normale registrazione. Usando log4net (o qualsiasi altro framework di registrazione) è possibile evitare di reinventare la ruota e sfruttare le appendici dei file di rolling, avvisare / errori / debug / codici informativi, scrivere file batch, ecc. È sempre una buona idea incorporare un buon logging in qualsiasi applicazione a livello di produzione.

In realtà, tuttavia, è probabilmente meglio archiviare tutte queste informazioni in un database. L'uso di un database ti permetterà di ordinarlo, aggregarlo e fare statistiche su di esso più facilmente

I file di registro vengono utilizzati 1. per ottenere informazioni per errori di sistema di debug. 2. per cercare attività dell'utente per malizia, o 3. per capire come le persone usano il sistema quando non puoi andare a guardarle. Con quello in mente:

• Registra l'ambiente (ad es. Varianti di ambiente, altre impostazioni, ecc.) All'avvio dell'applicazione. Questo è utile per problemi di debug.
• Registra l'utente e l'azione (la parte distinta dell'URL) per ogni richiesta.
• Registra tutti i parametri per ogni richiesta TRANNE le password. Mi piace mettere dei delimitatori attorno a ciascun parametro nei registri, ad es phone{(999)999-9999} email{aaa@aaa.com}. Le password non devono mai essere scritte da nessuna parte tranne che nel database in un modo, crittograficamente sicure con funzione hash con sale unico per ogni utente e più cicli di hash (vedi nota a piè di pagina)
• Quando accedi, dovresti registrare l'indirizzo IP dell'utente, l'ID utente, il nome, il conteggio degli accessi non riusciti, forse il browser, forse l'id della sessione dei cookie, ma mai la password.
• Ricordarsi di non registrare la password nella pagina di accesso E nella pagina di modifica della password, né di registrare la domanda segreta o la risposta se si dispone di tale funzionalità. Qualsiasi altra password o chiave di crittografia non deve essere registrata. È buona norma scrivere qualcosa come sei stelle nel registro per questi parametri in modo da poter vedere che si è ricordato di sopprimere questi dati.
• Mi piace registrare il tempo totale necessario per soddisfare ogni richiesta: Done: 49ms
• Mi piace registrare le modifiche allo stato della sessione. Questi dovrebbero essere rari.
• Come altri hanno detto, ci sono ottime librerie di log là fuori per la registrazione su file, non sono sicure per la registrazione su database.
• Conservare i registri in modo sicuro. Anche senza password, esistono leggi statali, federali e internazionali relative alle informazioni di identificazione personale (vedi Safe Harbor ) che rendono riservati i dati di registro.
• Prendi i backup. Se li lasci scorrere in un backup completo dell'unità ogni notte, ricordati di ricordarti di eseguirne il backup da qualche altra parte prima di eseguire l'aggiornamento a un nuovo server (non chiedermi come l'ho imparato).

Altri consigli

Nota a piè di pagina: per accedere a qualcuno, esegui l'hash della password fornita con lo stesso algoritmo di hashing e il salt dell'hash originale per quell'utente. Se l'hash della password fornita corrisponde all'hash della password memorizzato nel database, allora sono connessi. Per far ciò, è necessario definire il set di caratteri per la password, non consentire il carattere di sostituzione Unicode e qualsiasi altro carattere esterno al set.

Non specifichi se stai utilizzando un database, ma se lo sei e quel database è SQL Server, puoi aggiungere qualcosa chiamato AutoAudit e registrare automaticamente tutte le interazioni con i tuoi dati. Assicurati di specificare solo quegli oggetti che vuoi controllare.

Ma comunque, non tenterei di codificare manualmente il mio tracciamento perché finirà per essere un incubo per la manutenzione.

Inoltre, per la registrazione, non creare il proprio, utilizzare Enterprise Library Logging o Log4Net o simili.

Solo un consiglio generale. Potrebbe non essere direttamente correlato alla tua domanda.

Dipende da cosa userete i log per? Principalmente i log vengono utilizzati nella produzione per rilevare le operazioni che causano gli errori. Se li stai conservando per tenere traccia delle azioni dell'utente, non fa parte del registro. Questa deve essere la funzionalità lato server del prodotto. Queste cose quindi devono sicuramente andare nel database per studi successivi. Ma il lato server registra "L'errore si è verificato poiché un testo è vuoto" non fa parte della funzione. Queste cose devono andare nel file system. Devono avere i seguenti contenuti: - user_id, error_number, error_text, file_name, function_name, thread_id, system_date_time e qualsiasi altro contesto.

Ora sto solo parlando dei registri nei file.

1) Mantenerli asincroni. L'operazione di I / O è costosa.

2) Progettali come classe che funzione. I cambiamenti futuri saranno facili.

3) Tienili singleton, se possibile. Singleton è difficile in multi-thread, quindi progettare correttamente.

4) Meglio anche mantenere semplice l'interazione tra logger e loggee. Il più delle volte invia message_number rispetto a message_text effettivo e lascia che il logger riceva il messaggio dal numero. Questo aiuterà se in seguito desideriamo apportare modifiche nei formati di log generici.

Normalmente il logger e anche le cose che dobbiamo registrare dovrebbero far parte del progetto. Ho visto casi in cui ci sono stati cambiamenti nel design solo per assicurarmi che tutte le informazioni rilevanti siano registrate correttamente.

Prova Log4Net. Ti consente di accedere a file o database. Ecco il tutorial !

Usiamo Log4Net in tutti i nostri progetti.

L'uso di un file di registro presenta un paio di problemi. Innanzitutto potresti ricevere errori quando più processi tentano di accedere al file. È inoltre possibile che si verifichino problemi quando si tenta di scorrere o cancellare il file mentre il sistema è in esecuzione. Il modo per aggirare questo è usare un database.

Quindi, il passaggio 1 è creare una tabella di database. Suggerisco i seguenti campi:
* userID
* azione (es. Accesso, elimina pippo)
* Alcuni testi descrittivi (consentire qui i null)
* timestamp

Passaggio 2, Creare una procedura memorizzata con input per userID, azione e testo descrittivo. Basta usare l'ora corrente per creare il timestamp.

Passaggio 3: scrivere un metodo di registrazione in una comoda libreria condivisa in modo che sia facile da includere ovunque e iniziare la pratica di chiamare quel metodo come richiesto. È possibile che si desideri avere anche una logica flag di livello di registrazione per modificare ciò che viene registrato.

Passaggio 4, Creare una routine di manutenzione per eliminare periodicamente i vecchi messaggi dalla tabella di registrazione. Forse eliminare quando più vecchio di X, eseguire ogni settimana circa come parte della normale manutenzione del DB (ricostruzione dell'indice, ecc.).

Dopo averlo creato una volta, dovresti essere in grado di utilizzare il codice coinvolto in altri progetti.