.net - logger - log4net threshold
Rastreo versus registro y cómo encaja log4net? (7)
Me pregunto cuál es la diferencia entre el registro y el rastreo.
¿La diferencia es básicamente que el seguimiento es un registro más detallado que brinda a los desarrolladores una herramienta para depurar aplicaciones en tiempo de ejecución?
He estado experimentando con log4net y haciendo logging. Ahora me pregunto si debería hacer el rastreo también y si pudiera / debería usar log4net para ese propósito. ¿Debo hacer un rastreo con log4net y hay algún nivel de rastreo para log4net loggers? ¿Debo usar un nivel de registro diferente para depurar y rastrear o puedo usar el mismo? ¿Puedes dar un ejemplo simple de cómo haría el registro y el seguimiento de un método simple?
Editar: A pesar de algunas respuestas útiles a continuación, todavía no estoy seguro de cómo debería estar haciendo el rastreo versus el registro.
Tengo el siguiente método en mi capa Business y quiero agregar logging / tracing a él. Me pregunto cómo hacerlo de manera eficiente. ¿El siguiente método es aceptable en términos de registro / rastreo? ¿Deberían los mensajes de registro ser de tipo Información en lugar de Depurar? ¿Los mensajes de depuración que estoy registrando se consideran traza? ¿Cómo lo cambiarías?
IEnumerable<Car> GetCars()
{
try
{
logger.Debug("Getting cars");
IEnumerable<Car> cars = CarAccessor.GetCars().ConvertAll(DataAccessToBusinessConverter);
logger.Debug("Got total of " + cars.Count + " cars");
} catch (Exception e) {
logger.Error("Error when getting cars", e);
throw new Exception("Unexpected error when getting cars");
}
}
Además, considere qué información se registra o rastrea. Esto es especialmente cierto para la información sensible.
Por ejemplo, aunque en general puede ser correcto registrar un error que indica
"El usuario ''X'' intentó acceder pero fue rechazado por una contraseña incorrecta",
no está bien registrar un error indicando
"Usuario ''X'' intentó acceder pero fue rechazado porque la contraseña ''secreto'' no es correcta."
Podría ser aceptable escribir dicha información sensible en un archivo de rastreo (y advertir al cliente / usuario acerca de ese hecho por "algunos medios" antes de pedirle que habilite el rastreo para la solución de problemas extendida en la producción). Sin embargo, para el registro, siempre tengo como política que dicha información sensible nunca se escriba (es decir, niveles INFO y superiores en log4net).
Esto debe ser aplicado y verificado por revisiones de código, por supuesto.
El registro es el término genérico para registrar información: el rastreo es la forma específica de registro utilizada para depurar.
En .NET, los objetos System.Diagnostics.Trace y System.Diagnostics.Debug permiten el registro simple de una cantidad de "detectores de eventos" que puede configurar en app.config. También puede usar TraceSwitches para configurar y filtrar (entre errores y niveles de información, por ejemplo).
private void TestMethod(string x)
{
if(x.Length> 10)
{
Trace.Write("String was " + x.Length);
throw new ArgumentException("String too long");
}
}
En ASP.NET, hay una versión especial de Trace (System.Web.TraceContext) que se escribirá en la parte inferior de la página ASP o Trace.axd. En ASP.NET 2+, también hay un marco de registro más completo llamado Health Monitoring.
Log4Net es una forma más rica y flexible de rastreo o registro que el seguimiento integrado, o incluso el monitoreo de estado de ASP. Like Diagnostics.Trace configura los detectores de eventos ("appenders") en config. Para un seguimiento simple, el uso es simple como el Trace incorporado. La decisión de usar Log4Net es si usted tiene requisitos más complicados.
private void TestMethod(string x)
{
Log.Info("String length is " + x.Length);
if(x.Length> 10)
{
Log.Error("String was " + x.Length);
throw new ArgumentException("String too long");
}
}
IMO ...
El registro no debe diseñarse para la depuración del desarrollo (pero inevitablemente se usa de esa manera)
El registro debe diseñarse para el monitoreo operativo y la resolución de problemas: esta es su razón de ser.
El rastreo debe diseñarse para la depuración del desarrollo y el ajuste del rendimiento. Si está disponible en el campo, se puede usar para la resolución de problemas operacionales de bajo nivel, pero ese no es su objetivo principal
Dado esto, los enfoques más exitosos que he visto (y diseñado / implementado) en el pasado no combinan los dos juntos. Es mejor mantener las dos herramientas separadas, cada una haciendo un trabajo lo mejor posible.
Yo diría que sí. El registro es la única manera de determinar lo que sucedió en el pasado: si un cliente llama y dice que algo no sucedió como se esperaba, sin un registro, todo lo que puede hacer es encogerse de hombros y tratar de reproducir el error. A veces eso es imposible (según la complejidad del software y la dependencia de los datos del cliente).
También existe la cuestión de iniciar sesión para la auditoría, se puede escribir un archivo de registro que contenga información sobre lo que está haciendo el usuario, para que pueda usarlo para reducir las posibilidades de depurar un problema, o incluso para verificar los reclamos del usuario (si obtener un informe de que el sistema está roto, xyz no sucedió, puede buscar en los registros para descubrir que el operador no pudo iniciar el proceso, o no hizo clic en la opción correcta para que funcione)
Luego está el registro de informes, que es lo que la mayoría de la gente cree que es el registro.
Si puede adaptar el resultado del registro, coloque todo en los registros y reduzca o aumente la cantidad de datos que se escriben. Si puede cambiar el nivel de salida de forma dinámica, entonces eso es perfecto.
Puede usar cualquier medio para escribir registros, sujeto a problemas de rendimiento. Encuentro que anexar a un archivo de texto es el mejor, más portátil, más fácil de ver y (muy importante) más fácil de recuperar cuando lo necesita.
log4net es muy adecuado para ambos. Diferenciamos entre el registro que es útil para el diagnóstico posterior a la liberación y el "seguimiento" para fines de desarrollo mediante el nivel de registro DEBUG. Específicamente, los desarrolladores registran su salida de rastreo (cosas que solo son de interés durante el desarrollo) usando Debug() . Nuestra configuración de desarrollo establece el nivel para DEPURAR:
<root>
<level value="DEBUG" />
...
</root>
Antes de lanzar el producto, el nivel se cambia a "INFO":
<level value="INFO" />
Esto elimina todos los resultados de DEPURACIÓN del registro de liberación, pero mantiene INFO / WARN / ERROR.
Existen otras herramientas de log4net, como filtros, registro jerárquico (por espacio de nombres), objetivos múltiples, etc., ya que hemos encontrado que el método simple anterior es bastante efectivo.
logging! = depuración
A veces, mantener los archivos de registro es necesario para resolver problemas con el cliente, prueban lo que sucedió en el lado del servidor.
El registro no es rastreo . Estas dos deberían ser bibliotecas diferentes con diferentes características de rendimiento. De hecho, he escrito una sola biblioteca de seguimiento con la propiedad exclusiva de que puede rastrear automáticamente la excepción cuando el método con seguimiento habilitado queda con una excepción. Además de esto, es posible resolver de una manera elegante el problema para activar excepciones en lugares específicos de su código.