¿Cuánto para iniciar sesión en una aplicación y cuánto es demasiado?

Question

¿Solo me pregunto cuánta gente se registrará en sus aplicaciones?

he visto esto:

"Me suelen gusta usar el registro de errores nivel para registrar las excepciones que son capturado por la aplicación voy a utilizar el nivel de registro INFO como". La primera nivel" esquema de depuración para mostrar cada vez que entrar o salir de un método. a partir de ahí me utilizar el nivel de registro de depuración para rastrear información detallada. el FATAL nivel de registro se utiliza para las excepciones que no he podido coger en mi basado en web aplicaciones. "

Qué tenía este ejemplo de código con él:

Public Class LogSample 

    Private Shared ReadOnly Log As log4net.ILog = log4net.LogManager.GetLogger(GetType(LogSample)) 

    Public Function AddNumbers(ByVal Number1 As Integer, ByVal Number2 As Integer) As Integer 

     Dim intResults As Integer 

     Log.Info("Starting AddNumbers Method...") 
     Log.Debug("Number1 Specified: " & Number1) 
     Log.Debug("Number2 Specified: " & Number2) 

     intResults = Number1 + Number2 

     Try 

     intResults = Number1 + Number2 

     Catch ex As Exception 

     Log.Error("Error Adding Nubmers.", ex) 

     End Try 

     Log.Info("AddNumbers Method Complete.") 

     Return intResults 

    End Function 

End Class 

Pero esto sólo parece añadir tanto al método. Por ejemplo, una clase que normalmente sería tal vez 7 líneas de código se convierte de repente en 12 líneas de código. El método también pierde algo de su claridad y simplicidad.

Pero al decir que el beneficio de tener la sesión iniciada puede ser bueno. Para el monitoreo del desempeño ejemplo, en un sistema de producción, persiguiendo a los insectos aberrantes en la producción (no es que usted tendría todo esto activado el registro todo el tiempo.

Por lo tanto me pregunto qué hace la gente? Saludos Anthony

Answer 1

Tiene razón en que esto hace que el código sea más difícil de leer y mantener. Una recomendación es considerar buscar en una herramienta de AOP (Programación Orientada a Aspectos) para separar su lógica de registro de su lógica de aplicación. Castle Windsor y Spring son dos que vienen a mente dentro de la comunidad .Net que desee investigar.

Answer 2

Desde una seguridad s El registro de tandpoint puede ser un tema interesante. Escribí un blog entry en CSO Online hace un tiempo después de un par de ataques DDOS. Esta es la sección donde hablé de la explotación forestal, espero que ayude un poco:

Técnicas como la limitación de registro, escriben sólo los registros, y el uso de servidores de registro puede reforzar la seguridad retroactiva de un sistema. Después de que se haya producido un posible ataque DDoS , la compañía sin duda querrá investigar el ataque . Una investigación es solo posible si se ha utilizado el nivel correcto de logging. Demasiado y los registros se llenarán rápidamente, que podría ser el motivo del DoS en primer lugar. Demasiado poco y los registros de no servirán de nada porque no contienen suficiente información para capturar al criminal .

Answer 3

Es más el lado arte de la programación.

No desea registrar todo. Pero querrá registrar las partes más importantes del sistema.

Simplemente piense en su programa en un sentido amplio y trate de identificar qué información va a querer en caso de que algo se interrumpa en la producción.

Para empezar, todos los módulos lógicos centrales de su aplicación deben tener funcionalidad de registro. Las partes decorativas, p. La interfaz de usuario/animación no debería necesitar registro.

En mi humilde opinión, el registro de cada método de entrada/salida es excesivo y también producirá un ruido sobre todo porque solo puede incrustar un seguimiento de la pila.

Y para el rendimiento, utilice un perfilador .

Answer 4

... hey, ¿recibo una insignia por haber sido mencionado como el tema en una pregunta de SO? 8^D

Pero en serio, una cosa que quiero aclarar sobre el comentario de registro anterior es que parte de mi justificación para el registro "detallado" se basa en el hecho de que estoy aprovechando las características de log4net.

En la muestra que proporcioné, ese método se registra diariamente en el modo WARN. Lo que significa que lo único que se registra "por defecto" es si ocurre una excepción. Si recibo una llamada de uno de mis clientes sobre un error en la aplicación, no es necesario que me lean algún mensaje críptico en la pantalla, salteo al registro y puedo ver qué está pasando. La mayoría de las veces, la respuesta está ahí.

¿Qué sucede si la respuesta no está disponible? Log4net me permite actualizar mi archivo de configuración (no es necesario volver a compilarlo, no es necesario tener acceso a algún archivo especial del sistema en el servidor web con la aprobación del administrador del sistema) y pasar al modo INFO. Ahora comienzas a ver una segunda capa de registro. Tal vez el código nunca llegó a un cierto ciclo. Tal vez la recuperación de datos tenía un conjunto de registros vacío. Este segundo nivel de depuración es útil, y el registro solo se vuelve un poco más grande. Una vez hecho esto, puedo cambiar la configuración nuevamente y volver al registro de luz.

Naturalmente, si las cosas son REALMENTE locas, entonces voy al nivel de depuración completo, y quiero saber qué informa cada variable, con qué DataRows estoy trabajando y qué está sucediendo en la aplicación. En mi lugar de trabajo actual, no tenemos la capacidad de realizar la depuración remota en nuestras aplicaciones web, y no siempre podemos acceder a la base de datos de producción sin aumentar potencialmente los datos, por lo que tener esta depuración completa es la mejor opción.

Estoy de acuerdo con la mayoría de las personas que el exceso de registro puede realmente anular una aplicación y causar más problemas de los que vale. Si no recomendaría este tipo de registro detallado en una aplicación, a menos que la aplicación lo justifique por razones de seguridad. Sin embargo, ser capaz de aprovechar el registro detallado cuando sea necesario y sin tener que recompilar mi código ES un GRAN beneficio en mi opinión, y si tiene un marco que puede permitirlo fácilmente (como log4net), entonces digo que se ponga agradable y detallado y es bastante fácil filtrar mentalmente las referencias de código de registro si tiene que volver al código mismo.

Pido disculpas si sueno a la defensiva o despotricando, no lo digo en absoluto. Solo quería brindar más información sobre cómo y por qué configuré mi registro utilizando log4net en el método mencionado. 8^D

Answer 5

Como mínimo debes registrar errores y llamadas a componentes externos ... La muestra que proporcionas es lo que yo llamaría DEMASIADOS registros ... No hay motivo para iniciar sesión que estés en un inicio de un método, o al final de un método, o incluso los parámetros que se pasaron al método ... Es un desperdicio de espacio en disco, el archivo de registro se pondrá muy grande en muy poco tiempo ...

RWendi

Answer 6

No es fácil decidir cuánto tala es suficiente. Demasiado código de registro en una función como en su ejemplo entierra el código lógico real. Demasiadas entradas de registro hacen que el registro sea ruidoso. ¡Pero muy poco de registros no es muy útil!

Para .NET, puede usar la biblioteca de AOP, PostSharp, para ayudar a registrar la entrada y salida de una función junto con los valores de los argumentos y más.

Para obtener ayuda con la determinación de la cantidad para iniciar sesión su aplicación, echa un vistazo a este artículo "System Logging and Log Analysis "por Marcus Ranum.

Espero que esto ayude.