Seguimiento de errores en aplicaciones web en vivo / producción

Question

Actualmente trabajo en una empresa que tiene muchas aplicaciones personalizadas que se realizan internamente. Actualmente no hay estándares para muchas cosas. Me gustaría implementar una forma de registrar / rastrear los errores que ocurren en este programa (la mayoría son asp.net).

Actualmente estoy pensando en manejar esto en Global.asax en el método de Error de aplicación. Primero intente guardar la información en una base de datos de registro / seguimiento de errores y, si eso falla, intente enviar un correo electrónico.

¿Qué tipo de información es la más útil para obtener del mensaje de error y otras variables de la aplicación (página, nombre de usuario, etc.)?

Actualmente estoy pensando en usar dos tablas, una para obtener el error general y la información de la aplicación, y una segunda que contiene la información de la excepción. Esta será una relación de uno a muchos para entregar las excepciones internas que pueden provenir de una excepción de nivel de aplicación.

Estoy seguro de que me faltan muchos detalles y me gustaría escuchar su estrategia para manejar este problema.

Answer 1

Jeff Atwood escribió un excelente Controlador de excepciones que debería consultar en CodeProject

Intentaré recopilar tanta información como sea posible. Información de la pila Información de la sesión Ubicación del error

También configuraría un servicio web al que llaman las aplicaciones para guardar la información de excepción en su sistema.

Answer 2

Creo que ELMAH puede ser lo que estás buscando.

Answer 3

Si usa una biblioteca de registro (como Log4Net), puede configurar varios agregadores de registro para que se registren en el correo electrónico, DB, archivo, registro de eventos, etc. mientras tiene una única llamada de registro en su código. Esta publicación cubre todo lo que necesita para obtener comenzado.

También hay Monitoreo de salud de ASP.NET .

EDITAR: otro póster mencionó ELMAH, que es ideal para registrar errores de ASP.NET y se puede "inyectar" dinámicamente en aplicaciones en ejecución.

Answer 4

Esto es lo que hago, y todavía tengo un error debido a un problema de correo electrónico.

Nunca mantengo nada en la base de datos, porque si la base de datos tiene un error, nunca tendré ese error en la causa de la base de datos, lógicamente, ¡la inserción fallará!

Por lo tanto, envío un correo electrónico a una dirección de correo electrónico especial como bugs@mydomain.com

Asunto : [Nombre de la aplicación] [Marca de tiempo: ddmmyyyy hhmmss] Mensaje : aplicación, mensaje de error, información de seguimiento de la pila y variables de sesión como el nombre de usuario y variables del servidor como Referer.

el mejor amigo de un desarrollador de ASP.NET es la información de rastreo de la pila , es aquí donde sabrá qué salió mal, cuál fue la llamada y dónde estaba llamando.

el único problema que tiene en este sistema, es que no obtendrá nada si el correo electrónico tiene un problema (alguna excepción al enviar el correo electrónico), y para eso empecé a agregar a una archivo XML mensual [errorLog_ mmm_yyyy.xml] también e hizo un simple " arrastrar y soltar " página con una vista de cuadrícula que cargó el XML para el mes y el año en que quise comprobar los errores.

try 
{
   // production code
}
catch(Exception ex)
{
   Utilities.Mail.SendError(ex);
}

o la mejor manera: añádalo a Application_Error en global.asax:

<%@ Application Language="C#" %>
<%@ Import Namespace="System.Diagnostics" %>
<script language="C#" runat="server">
void Application_Error(object sender, EventArgs e)
{
   //get reference to the source of the exception chain
   Exception ex = Server.GetLastError().GetBaseException();

   //log the details of the exception and page state to the
   //Windows Event Log
   EventLog.WriteEntry("myWebApplication name",
     "MESSAGE: " + ex.Message + 
     "\nSOURCE: " + ex.Source +
     "\nFORM: " + Request.Form.ToString() + 
     "\nQUERYSTRING: " + Request.QueryString.ToString() +
     "\nTARGETSITE: " + ex.TargetSite +
     "\nSTACKTRACE: " + ex.StackTrace, 
     EventLogEntryType.Error);

   Utilities.Mail.SendError(ex);
}
</script>

con el código anterior, agrega el error al registro de eventos, adjunto el error al archivo XML en la función SendError (Excepción).

Answer 5

Tenga mucho cuidado al registrar información potencialmente confidencial que haya llegado a través de https. El usuario esperará que esté cifrado de extremo a extremo (lo que puede ser un requisito legal). Asegúrate de no enviarlo por correo electrónico.

Normalmente diría que se registra toda la solicitud, incluidas las de obtención, publicación, cookies, estado del formulario (en ASPNET), agente de usuario, otros encabezados, fecha / hora, máquina del servidor, etc.

PERO, en algunos casos, podría dar lugar a que se registre cierta información que se supone que no debe registrar de forma permanente (como que los números de las tarjetas de crédito se transfieran a un proveedor de pagos). Enviarlo por correo electrónico es aún peor.

Vale la pena realizar una comprobación si HTTPS está activado y, de ser así, reduzca la cantidad de información que registra para evitar este problema. Acabo de enviar una cadena para indicar si el campo estaba vacío o no.

Answer 6

En realidad, suena como si hubieras pensado en la solución bastante bien.

Trabajo en la tienda de desarrollo web, así que además de los errores de registro, también me aseguro de que cualquier error crítico del sistema, como fallar consultas de db y similares, también se envíe por correo electrónico para que podamos saltar sobre ellos y corregirlos de inmediato.

Una alternativa a considerar sería enviar un informe por correo electrónico todos los días que proporcione información sobre cada error que se genere en cada aplicación y cualquier información relevante que desee recibir en el correo electrónico.

Registramos todos nuestros errores en una sola tabla para esa aplicación (por supuesto, es más fácil hacerlo cuando trabaja en aplicaciones donde todas las bases de datos están contenidas internamente), incluida la marca de tiempo del error y el texto completo de mensaje de excepción que también ha sido enviado por correo electrónico.

El mensaje de excepción contiene una función de rastreo para que sepa cuál fue la función de llamada original, así como los números de archivo y línea para todas las funciones de la pila. Esto hace que el seguimiento de cualquier error dado sea muy simple.

Answer 7

Cuando falla el inicio de sesión en la base de datos, puede escribir en el registro de eventos del servidor o en un archivo Log.txt. Su elección aquí depende en parte de si tiene acceso a los servidores web que los contienen.

Enviar correos electrónicos de notificación de error es una buena idea si necesita una respuesta rápida. Pero no hay una lista de los errores para analizarlos.

Lo hago creando una clase de excepción personalizada especial con propiedades que incluyen información del usuario (ID, nombre si está disponible), todas las variables de sesión, todas las variables de formulario (para que pueda ver cómo se rellenó el formulario y qué usuario ingresado), y alguna indicación más allá del seguimiento de la pila de dónde ocurrió el error (qué página, qué clase, qué método). Incluya también el nombre del procedimiento almacenado llamado y los parámetros enviados, o el propio SQL. También todas las propiedades de excepción (seguimiento de pila, etc.) Y los campos DisplayMessage y InternalMessage. El DisplayMessage se muestra al usuario. InternalMessage se registra en el registro y se muestra en la página de error personalizada cuando se encuentra en el modo de depuración.

Hago el inicio de sesión en Page_Error en la página base, y como un error en Application_Error.

A veces agrego un par clave-valor en web.config para contener mi dirección de correo electrónico (o una lista de distribución). Si hay un valor en esa clave, se envía un correo electrónico de notificación. Si no hay valor, no se envía correo electrónico. Luego, durante las pruebas o la producción temprana, puedo recibir una notificación personal inmediata del problema. Una vez transcurrido el período inicial, elimino la dirección de correo electrónico en web.config.

Answer 8

el registro es bueno, pero monitoreo de aplicaciones es mejor.

advertencia: soy el autor de CALM

Answer 9

Estábamos frustrados con las aplicaciones de informe de errores del sitio web que estaban allí, así que escribimos el nuestro en Clearwind Consulting. Es gratis y lo usamos internamente para nuestros proyectos. Proporciona información de error completa, como códigos de error completos, tipo de navegador, rastreo, un fragmento del código que causó el error, frecuencia de errores representada durante 30 días y más. En Clearwind, hacemos desarrollo de aplicaciones web. Necesitábamos una herramienta que nos proporcionara datos reales que pudiéramos utilizar de manera eficiente en nuestros sitios web.

Puede elegir cómo recibir una notificación de cuándo su sitio web da un error. Se puede utilizar RSS, correo electrónico o cualquier otro método que funcione mejor para obtener notificaciones de error. Y sí, puedes enviar los errores a tu iPhone mientras tomas una copa. Está completamente escrito en Django para que pueda usar JSON, RoR, XML, CSV, etc. si desea etiquetar o formatear sus datos. O simplemente visita el sitio web.

Si lo desea, visite www.areciboapp.com.

Es gratis, se agrega fácilmente a (o se elimina de) cualquier sitio web y brinda información real para que pueda corregir los errores, en lugar de solo 404. No es difícil vender aquí. Solo una invitación para que venga a ver si puede ayudarlo a usted y a su sitio web. Pensamos que podría.

Answer 10

Es una buena idea iniciar sesión en un registro de eventos personalizado en el servidor, así como en cualquier otro registro y amplificador; notificación. Si el error fue causado por un problema de infraestructura, el mismo problema también podría evitar que el controlador de errores envíe correos electrónicos o los guarde en una base de datos.