Mejores prácticas para registrar acciones de usuario en producción

Estaba planeando registrar muchas cosas diferentes en mi entorno de producción, como cuando un usuario:

• Inicia sesión, cierra sesión
• Cambiar el perfil
• Editar configuración de la cuenta
• Cambiar contraseña ... etc.

¿Es esta una buena práctica para hacer en un entorno de producción? Además, ¿cuál es una buena manera de registrar todo esto? Actualmente estoy usando el siguiente bloque de código para iniciar sesión:

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

¿Esto estará bien para la producción? Mi aplicación es muy nueva, así que no espero millones de usuarios de inmediato ni nada, buscando las mejores prácticas para realizar un seguimiento de las acciones en un sitio web o si es incluso la mejor práctica.

Esta no es una respuesta directa a la pregunta, sino más bien una expansión.

Cuando inicia una nueva aplicación, le recomiendo registrar todo lo que hace el usuario: iniciar sesión, cerrar sesión, rasca su a **, todo. Si está basado en la web, considere usar mapas de calor para saber qué estaba haciendo su mouse.

Cuando estaba en el proyecto BravoX en Xerox a fines de los años 70, grabamos movimientos de mouse píxel por píxel para descubrir cómo los usuarios podrían usar esta cosa extraña llamada editor WYSIWYG. Observaríamos reproducciones de sesiones de usuarios durante el almuerzo. Fue extremadamente instructivo. Descubrimos un patrón de uso que llamamos Charlie Browning: el usuario seleccionaría algo de texto y lo pondría en cursiva ... luego lo deshacería ... luego lo rehacería ... adelante y atrás, adelante y atrás. Resulta que estaban tratando de entender estas cosas a nivel emocional. Entonces (Greg Kusnik hizo el código, si la memoria sirve) pusimos algunas optimizaciones específicas para admitir exactamente este comportamiento.

Sin la grabación nunca hubiéramos pensado hacer esto.

Si yo fuera usted y me quedara escribiendo en un archivo de texto, usaría log4net e iniciaría sesión en un archivo específico "UserActions.log". De esta manera no confunde su registro normal. Mediante el uso de log4net (o cualquier otro marco de registro) puede evitar reinventar la rueda y aprovechar los anexos de archivos, advertencia / error / depuración / códigos de información, escritura de archivos por lotes, etc. Siempre es una buena idea incorporar un buen inicio de sesión en cualquier aplicación de nivel de producción.

Sin embargo, en realidad, probablemente sea mejor almacenar toda esta información en una base de datos. El uso de una base de datos le permitirá ordenarlo, agregarlo y hacer estadísticas más fácilmente

Los archivos de registro se utilizan 1. para obtener información para la depuración de errores del sistema. 2. para investigar la actividad del usuario en busca de travesuras, o 3. para comprender cómo las personas usan el sistema cuando no puedes ir a verlo. Con eso en mente:

• Entorno de registro (por ejemplo, variables de entorno, otras configuraciones, etc.) en el inicio de la aplicación. Esto es útil para problemas de depuración.
• Registre el usuario y la acción (la parte distinta de la URL) para cada solicitud.
• Registre todos los parámetros para cada solicitud, EXCEPTO las contraseñas. Me gusta poner delimitadores alrededor de cada parámetro en los registros, por ejemplo phone{(999)999-9999} email{aaa@aaa.com}. Las contraseñas nunca deben escribirse en ninguna parte, excepto en la base de datos de una manera, función hash criptográficamente segura con sal única para cada usuario y múltiples rondas de hash (ver nota al pie)
• Al iniciar sesión, debe registrar la dirección IP del usuario, la ID de usuario, el nombre, el recuento de inicios de sesión fallidos, tal vez el navegador, tal vez la identificación de la sesión de cookies, pero nunca la contraseña.
• Recuerde no registrar la contraseña en la página de inicio de sesión Y la página de cambio de contraseña, ni debe registrar la pregunta o respuesta secreta si tiene esa funcionalidad. Cualquier otra contraseña o clave de cifrado no debe registrarse. Es una buena práctica escribir algo así como seis estrellas en el registro de estos parámetros para que pueda ver que recordó suprimir estos datos.
• Me gusta registrar el tiempo total que se tarda en atender cada solicitud: Done: 49ms
• Me gusta registrar cambios en el estado de la sesión. Estos deberían ser raros.
• Como han dicho otros, existen excelentes bibliotecas de registro para iniciar sesión en archivos, no estoy seguro de iniciar sesión en bases de datos.
• Almacene los registros de forma segura. Incluso sin contraseñas, existen leyes estatales, federales e internacionales sobre la información de identificación personal (consulte Safe Harbor ) que hacen que los datos de registro sean confidenciales.
• Tomar copias de seguridad. Si los deja fluir en una copia de seguridad de disco completo todas las noches, asegúrese de recordar hacer una copia de seguridad en otro lugar antes de actualizar a un nuevo servidor (no me pregunte cómo aprendí esto).

Otros consejos

Nota al pie: para iniciar sesión en alguien, agregue la contraseña proporcionada con el mismo algoritmo de hash y la sal del hash original para ese usuario. Si el hash de la contraseña suministrada coincide con el hash de la contraseña almacenado en la base de datos, entonces están conectados. Para que esto funcione, debe definir el conjunto de caracteres para su contraseña, no permitir el carácter de sustitución Unicode y cualquier otro carácter fuera de su conjunto.

No especifica si está utilizando una base de datos, pero si lo está y esa base de datos es SQL Server, puede agregar algo llamado AutoAudit y registrar automáticamente todas las interacciones con sus datos. Solo asegúrese de especificar solo aquellos objetos que desea auditar.

Pero de todos modos, no estaría tratando de codificar manualmente mi seguimiento, ya que terminaría siendo una pesadilla de mantenimiento.

Además, para iniciar sesión, no lo haga, use Enterprise Library Logging o Log4Net o similar.

Solo un consejo general. Puede no estar directamente relacionado con su pregunta.

¿Depende de para qué vas a usar los registros? La mayoría de los registros se utilizan en la producción para detectar las operaciones que causan los errores. Si los guarda para rastrear las acciones del usuario, eso no es parte del registro. Esa debe ser la característica del lado del servidor del producto. Estas cosas definitivamente deben ir a la base de datos para su posterior estudio. Pero los registros del lado del servidor, como "Se produjo un error porque parte del texto está vacío", no forman parte de la función. Estas cosas deben ir en el sistema de archivos. Deben tener los siguientes contenidos: usuario_id, número_error, texto_error, nombre_archivo, nombre_función, id_hilo, fecha_sistema_tiempo y cualquier otro contexto.

Ahora solo estoy hablando de los registros en los archivos.

1) Manténgalos asíncronos. La operación de E / S es costosa.

2) Diseñarlos como clase que función. Los cambios futuros serán fáciles.

3) Manténgalos solteros, si es posible. Singleton es difícil en multihilo, por lo que debe diseñarse correctamente.

4) También es mejor mantener simple la interacción entre logger y loggee. La mayoría de las veces envía el número_de_mensaje que el texto_mensaje real y deja que el registrador reciba el mensaje del número. Esto ayudará si más adelante queremos hacer cambios en los formatos de registro genéricos.

Normalmente el registrador y también las cosas que necesitamos registrar deben ser parte del diseño. He visto casos en los que hubo cambios en el diseño solo para asegurarme de que toda la información relevante se registre correctamente.

Pruebe Log4Net. Le permite iniciar sesión en archivos o bases de datos. ¡Aquí está el tutorial !

Utilizamos Log4Net en todos nuestros proyectos.

El uso de un archivo de registro presenta un par de problemas. En primer lugar, puede obtener errores cuando varios procesos intentan acceder al archivo. También puede tener problemas al intentar alternar o borrar el archivo mientras su sistema se está ejecutando. La forma de evitarlo es usar una base de datos.

Entonces, el paso 1 es crear una tabla de base de datos. Sugiero los siguientes campos:
* ID de usuario
* acción (por ejemplo, inicio de sesión, eliminar foo)
* Algún texto descriptivo (permitir nulos aquí)
* marca de tiempo

Paso 2, cree un procedimiento almacenado con entrada para ID de usuario, acción y texto descriptivo. Simplemente use la hora actual para crear la marca de tiempo.

Paso 3: escriba un método de registro en una biblioteca compartida conveniente para que sea fácil de incluir en todas partes y practicar la llamada a ese método según sea necesario. Es posible que también desee tener una lógica de indicador de nivel de registro para cambiar lo que se registra.

Paso 4, cree una rutina de mantenimiento para borrar mensajes antiguos de la tabla de registro de vez en cuando. Quizás elimine cuando sea anterior a X, ejecute cada semana aproximadamente como parte del mantenimiento regular de la base de datos (reconstrucción de índice, etc.).

Una vez que haya creado esto una vez, debería poder usar el código involucrado en otros proyectos.