¿Cuánta información registrar de errores? [cerrado]

Question

En la empresa para la que trabajo, he creado una clase de registro de errores para manejar los errores en mi aplicación ASP.net. Es una clase personalizada porque no se nos permite instalar software adicional en nuestros servidores (nLog, log4net, etc.).

Actualmente lo uso en dos de mis proyectos y he visto algunos buenos resultados. Ahora mismo estoy atrapando los errores que causan errores de página y de aplicación. Envía y almacena el mensaje de error y todas las excepciones internas.

El problema que tengo ahora es que recibo errores que no estoy muy seguro de cómo reproducir. No he escuchado ningún informe de errores de ninguno de mis usuarios. No estoy seguro de lo que están haciendo, o incluso si están viendo estos errores.

Estoy pensando en crear un Registro de eventos en cada página o en las que deseo información adicional. Manteniéndolo como una variable de sesión en la página, y escribiendo eventos en él (inicio / final de funciones, cambios de variables, etc.). Entonces solo si se llama a un error para que se envíe junto con el mensaje de error para ver si proporciona una mejor imagen de lo que está sucediendo. Espero que hacerlo de esta manera no me proporcione toneladas de registros de eventos cuando todos los usuarios accedan a la aplicación, solo quiero que ocurra justo antes de que ocurra el error con un usuario.

¿Conoces algún error que deba vigilar con un método?

¿Tiene algún consejo sobre qué buscar?

Actualización:

@Saret: Entiendo de dónde viene con esa respuesta y estoy de acuerdo. Soy bastante nuevo en esta empresa y todavía necesito aprender cómo hacen las cosas. En el pasado he tenido conversaciones con mis compañeros de trabajo sobre cómo sería genial tener este producto o usar este proyecto de código abierto. El problema radica en que trabajamos en sistemas seguros y obtener la aprobación para obtener estas cosas lleva mucho tiempo, la cubierta superior y lidiar con toda la burocracia. Analizaré la situación aún más porque creo que es importante tener un buen sistema de registro de errores, actualmente no se está utilizando nada.

@Jim Blizard: quería intentar alejarme del registro / almacenamiento de todo en algún lugar para regresar y averiguar qué es importante para la situación que causó el error. No quise caer en la sobrecarga de información de la que se habla en la óptica que Roberto Barros vinculó. Mi método de pensamiento actual es mantener una cadena en la memoria en cada página y, si se produce un error, en el evento Page_Error de las páginas, tome esa cadena y adjúntela a la excepción que se está registrando. De esa manera, solo estoy registrando el error / las excepciones que ocurrieron y almacenando el registro de eventos con ese error. Si no sucede nada, el registro que se estaba creando se coloca en el depósito de bits y no se vuelve a ver.

@Roberto Barros: Gracias por ese enlace, recuerdo haberlo leído en algún lugar pero se me olvidó guardarlo.

Answer 1

Es posible que esta no sea la respuesta exacta que está buscando, pero ¿por qué desarrollar su propio mecanismo de registro de errores cuando existen herramientas poderosas (que usted menciona) que manejan todos estos problemas clave para usted?

Puedo apreciar que no tiene permiso para instalar software adicional, pero ¿no está registrando bibliotecas solo clases como su código personalizado? ¿Dónde está la diferencia fundamental? Pensaría que el tiempo dedicado a preocuparse por la implementación de un marco de registro podría ser mejor gastado en defender y hacer un caso de negocios para una solución de registro decente.

Answer 2

Una vez trabajé para una agencia que no permitía la instalación de nada que no fuera puramente mi propio código o sus (horribles) objetos COM. Si tiene este tipo de limitación, vea si puede obtener la fuente de log4net e incluirla en su proyecto.

No hay nada mejor que log4net actualmente cuando se trata de registro.

Answer 3

Personalmente adopté el siguiente enfoque para registrar errores (y solo registrar errores) en una aplicación asp.net:

• utilizar Application_Error void protegido (objeto remitente, EventArgs e) {     Server.Transfer (" ~ / Support / ServerErrorSupport.aspx " ;, true); } (Hago un Server.Transfer para conservar todos los datos publicados.)

• Genere un ID de error que sea único para este error (por lo que se pueden agrupar los informes posteriores para el mismo error). El ID es un hash calculado a partir de una cadena concatenada que consta de: archivo, método, líneaNr y error.Message. Obtengo los valores de archivo, método y línea Nr a través de una expresión regular en el seguimiento de pila.

• Registro todos los datos siguientes en una estructura xml (según el tipo de datos, almaceno el valor de forma diferente, tipos de valor = > ToString (), ISerializable = > serialize, ...):

  1. MachineName: Application.Server.MachineName
  2. PhysicalRoot: Application.Server.MapPath (" ~ / ")
  3. RequestUrl: Application.Request.Url.ToString ()
  4. ApplicationSettings: WebConfigurationManager.AppSettings
  5. ConnectionSettings: WebConfigurationManager.ConnectionStrings
  6. QueryString: Application.Request.QueryString
  7. FormPost: Application.Request.Form
  8. Session: Application.Session
  9. HttpHeaders: Application.Request.Headers

• Guarde la estructura xml como un archivo local que contenga el ID de error y una marca de tiempo. Elegí este enfoque porque:

  • Puedo enviar la relación (archivo xml) a mí mismo (durante la prueba / depuración muy fácil)
  • almacenarlo localmente o en una base de datos durante la producción
  • porque el archivo es solo un (dump to hd), no mucho puede salir mal durante la creación del informe de error (como una conexión de servidor, problemas de db, etc.), solo asegúrese de tener permisos de escritura.
  • Además, en la página servererrorsupport.aspx, después de guardar el archivo xml, el usuario tiene la opción de incluir información adicional y agregar una dirección de correo electrónico para mantenerse actualizado sobre el progreso con respecto al error. Esto se adjunta al documento xml.
  • Utilizo un archivo xslt para formatear los datos de error (xml) en un informe de error agradable.

Answer 4

Por errores, soy un gran fanático de registrar MUCHO. Cuando las cosas van mal la información es muy valiosa. Mantendría el registro completo en un solo lugar (archivo de texto o tabla de base de datos) con un identificador de sesión para agrupar eventos relevantes juntos.

Answer 5

Esto es lo que me gusta registrar:

• nivel de error / depuración (información, depuración, problema, bloqueo, etc.)
• tiempo
• texto descriptivo (generalmente una línea)
• seguimiento de la pila (si es posible)
• datos (usuario, sesión, valores de variables, etc.)

La forma más sencilla es escribir en un archivo de texto, pero puede ser bueno tenerlo en una base de datos. También puede utilizar el registro de eventos de Windows. Algunas cosas a tener en cuenta. Hmm ... Necesitarás borrar tus registros periódicamente.

Historia divertida: una vez tuvimos un registrador de errores que se registraba en la base de datos, pero teníamos malas credenciales en la base de datos, lo que causó un error que luego se registró ... Terminé obteniendo desbordamientos de pila de la recursión (IIRC).