¿Qué debo iniciar sesión en la aplicación de producción

Question

Estoy comenzando un nuevo proyecto y estoy pensando en qué cosas debería estar registrando. El archivo de registro solo está destinado a ayudar a los desarrolladores a encontrar errores. El caso de uso es que cuando se lanza una excepción no controlada se envía una notificación al desarrollador, que tiene acceso al archivo de registro y stacktrace.

¿Qué cosas debería incluir en el archivo de registro? Iniciar sesión en todo no va a funcionar. Sé que es difícil de decir, ya que la respuesta probablemente requiera un conocimiento profundo del sistema. Así que supongo que realmente estoy pidiendo "mejores prácticas". Por favor da ejemplos específicos.

¿Depende también del tipo de aplicación, como la aplicación cliente de escritorio, el servidor de escritorio o un servidor web?

Answer 1

En general

• Si registrar los valores DateTime (no estamos hablando de campos de cabecera de fecha y hora de los marcos de registro) asegurarse de que los registre en un formato significativo. "ToString()" generalmente no es suficiente si necesita información sobre Local vs. Utc o sobre milisegundos (utilizo "aaaa-MM-dd HH: mm: ss.fff zzz", YMMV)
• Si registra excepciones, ir por "ToString()" en lugar de cualquier otra cosa. Controversial tal vez, pero mira here por razones.

Acerca de información detallada o detallada, como ya han dicho otros, hay que tener cuidado. No se trata solo de que las personas tengan derecho a leer los registros de producción obteniendo más información de la necesaria, sino que piense en el caso de que cualquier intruso en un sistema pueda obtener información valiosa para registros excesivamente detallados (por lo que no registraría un conjunto de los permisos de los usuarios con el error de que no tiene uno en particular, se sugirió en otra respuesta).

Puede depender de su entorno o cliente lo que se considera sensible, pero los ejemplos son: - Entrada de usuario real en los mensajes de error. - Conjuntos de permisos de usuario, etc. - sentencias SQL, especialmente con los parámetros reales - solicitud XML/estructuras de respuesta

Encontrando la granularidad derecho de información de registro es siempre una solución de compromiso entre la cantidad de información registrada, el rendimiento que cuesta no sólo escribir, sino también a producir esta información en código y la sensibilidad de esa información. Y esa es la razón por la cual cualquier sistema de registro serio tiene "niveles" o "categorías".

Puede registrar información potencialmente delicada en un "nivel" o "categoría" que se puede activar durante el desarrollo pero sin producción. Si realmente desea exagerar, puede escribir una entrada EventLog cuando su aplicación detecte que dicho registro está habilitado, para que no se "filtre" durante la producción.

Finalmente, considere utilizar un marco de trabajo de registro que permita cambiar esos niveles o categorías durante el tiempo de ejecución. De esta forma, puede habilitar más información si es necesario, de forma controlada, sin interrumpir el trabajo de la aplicación o restablecer una situación que desea inspeccionar por la necesidad de reiniciar primero la aplicación.

Answer 2

La primera regla es "¡No registre información confidencial!". Por ejemplo: número de seguro social, números de tarjeta de crédito, contraseñas, etc. No sabe quién puede obtener permisos para verlo y esto puede traerle algunos problemas legales.

Es útil para registrar la comunicación con componentes de terceros (por ejemplo, servicios web, etc.). Podrá proporcionar información útil al proveedor externo o a usted en caso de que surja un problema.

Es útil rastrear muy brevemente las acciones que realizan los usuarios ... ir a una página en particular ... hacer algunas cosas. Entonces, si un cliente lo llama por teléfono y le dice que algo anda mal con su producto, puede verificar lo que está haciendo ahora.

En nuestra compañía, es una práctica común realizar un seguimiento de cuánto tarda en completarse una consulta de base de datos. Esta es la forma de identificar cuellos de botella en algún momento o identificar algunos problemas con su sistema (servidor de aplicaciones o servidor de base de datos).

También puede rastrear algunos intentos de romper los ataques de DOS de su sistema, bots de fuerza bruta ... y así sucesivamente.

Espero que ayude!

Answer 3

Eche un vistazo a la documentación para algo como nLog. Le dará algunas ideas sobre lo que debe registrar y cómo se puede controlar.

Answer 4

Registre el nombre del método que arrojó la excepción y los parámetros que estaba usando (es decir, estado). Registre la identificación y los privilegios del usuario. En un escenario web, registre la dirección IP y los encabezados.

Answer 5

El registro hace que el código sea más largo y menos claro. Así que sea flojo, no inicie sesión hasta que lo necesite.

Podría ser una buena idea enviar correos electrónicos con excepciones no controladas directamente a los desarrolladores y no registrar nada en absoluto.

Answer 6

El registro es su Salvador cuando se trata de la situación de "todo el infierno se rompió" en la producción. Como dijiste, requiere más conocimiento de la aplicación, pero sobre todo debes pensar en un par de cosas.

1. Registre todas las excepciones y errores. Nada debería escapar.
2. Considerar el inicio de sesión del usuario y la acción de cierre de sesión. Esta es una buena información para supervisar su aplicación en busca de ataques maliciosos y cosas así.
3. No puede registrar todos los métodos excepto usted si el sistema está diseñado correctamente y si tiene un único punto de entrada para su comunicación entre n capas, entonces puede registrar ese método. es decir, Guardar, Eliminar, Actualizar métodos, etc.
4. También proporcione un poco de logging inside si # código de depuración para que pueda activar la depuración en la producción y producir más registros si es necesario. Esto es muy útil especialmente cuando se trabaja en el entorno de desarrollo y la base de datos de producción de depuración.

Answer 7

Tengo dos entornos separados donde los requisitos de registro son totalmente diferentes.

1. aplicación de Office

Aquí se registre excepciones, las cosas comunes como el inicio de sesión, se inicia la aplicación, etc. además de la edición/borrado/inserción de objetos. Lo suficiente para comprobar qué pasó cuando las cosas se disparan. Registramos lo suficiente para poder reproducir el caso. Se permite que el registro crezca sin límites en nuestro caso, por lo que podemos verificar si hay problemas de regreso.

2. Aplicación industrial.

Aquí registramos casi todo más el fregadero de la cocina. Este es un servicio flexible que debe funcionar 24 horas al día, 7 días a la semana, por lo que incluso una simple advertencia puede ser un indicio de un desastre futuro. Un ejemplo es que tuvimos algunos tiempos de espera extraños y no cumplimos con los requisitos de restricción de tiempo. Al final, el archivo de registro nos dio la información: guardar un archivo de texto de unos 100 bytes a veces tomó más de 5 segundos. Por lo general, los problemas que se presentan son cosas en las que nunca pensaste, ¡así que lo que debes hacer es iniciar sesión, iniciar sesión o iniciar sesión! Los registros se limpian automáticamente después de unos días.

Lo que también hicimos fue implementar un nivel de registro que el usuario final puede establecer: si se establece en detallado, guardamos todos los registros, si se establece en mínimo solo se producen errores. Entonces, después de unas pocas semanas de funcionamiento estable, disminuimos lentamente el nivel de registro hacia el mínimo y nos detenemos allí con los que nos comportamos.

Así que yo diría: depende de su aplicación.