¿Cuál es la mejor manera de administrar el registro de errores para excepciones?

Introducción

Si se produce un error en un sitio web o sistema, por supuesto, es útil registrarlo y mostrar al usuario un mensaje cortés con un código de referencia para el error.

Y si tiene muchos sistemas, no desea que esta información se distribuya: es bueno tener un solo lugar centralizado para ello.

En el nivel más simple, todo lo que se necesita es una identificación incremental y un volcado serializado de los detalles del error. (Y posiblemente el "lugar centralizado" sea una bandeja de entrada de correo electrónico).

En el otro extremo del espectro, quizás haya una base de datos completamente normalizada que también le permite presionar un botón y ver un gráfico de errores por día, o identificar cuál es el tipo de error más común en el sistema X, si el servidor A tiene más base de datos errores de conexión que el servidor B, y así sucesivamente.

A lo que me refiero aquí es registrar errores / excepciones a nivel de código por un sistema remoto, no un seguimiento de problemas "basado en humanos", como se hace con Jira, Trac, etc.

Preguntas

Estoy buscando ideas de desarrolladores que han usado este tipo de sistema, específicamente con respecto a:

• ¿Cuáles son las características esenciales que no podría prescindir?
• ¿De qué sirve tener funciones que realmente le ahorren tiempo?
• ¿Qué características pueden parecer una buena idea, pero en realidad no son tan útiles?

Por ejemplo, yo diría que una función "mostrar duplicados" que identifica la ocurrencia múltiple de un error (sin preocuparse por los detalles "sin importancia" que pueden diferir) es bastante esencial.
Un botón para "crear un problema en [Jira / etc] para este error" suena como un buen ahorro de tiempo.

Solo para repetir, lo que busco es experiencias prácticas de personas que han usado tales sistemas, preferiblemente respaldados por qué una característica es increíble / terrible.
(Si va a teorizar de todos modos, al menos marque su respuesta como tal).

He estado en un proyecto donde con errores de cliente registrados usando la biblioteca de Microsoft Enterprise . Todas las excepciones se envían a nuestro buzón. En el asunto del correo agregamos un código hash de error serializado para evitar mensajes duplicados. Por supuesto, uno podría almacenar mensajes serializados en la base de datos, etc.

Le recomiendo que consulte la biblioteca de Microsoft Enterprise y Log4Net .

Algunas características de Log4Net

• Soporte para múltiples marcos
• Salida a múltiples objetivos de registro
• Arquitectura de registro jerárquico
• Configuración XML
• Configuración dinámica
• Contexto de registro
• Arquitectura probada
• Diseño modular y extensible • Alto rendimiento con flexibilidad

En el caso de las aplicaciones de bases de datos, algún tipo de ID (como <TABLE>:<PrimaryKeyID>) que le permite rastrear los registros en la base de datos relacionados con el alcance donde se detectó la excepción.

Lo hice con Oracle y PL / SQL, registrando la ID en una tabla de base de datos dentro de la aplicación, desde el controlador de excepciones.

Gran parte de lo que usted describe (es decir, las partes específicas de registro) se implementan en la biblioteca empresarial, como Amir Rezaei ha señalado. Todo lo demás parece ser más de la parte analítica (es decir, qué hacer con los registros después).

En mi caso, creé algunas aplicaciones pequeñas y scripts sql que facilitaron algunas cosas. Estas son algunas de las cosas que realmente me gustaron:

• Agrupar los mismos errores juntos (es decir, 100 usuarios experimentaron el mismo error al mismo tiempo es un informe de error con una nota de cuántas ocurrencias hubo)
• Archivar automáticamente un ticket en el rastreador de casos (nunca logró hacer esto 'con solo hacer clic en un botón' pero siempre quise hacerlo)
• Nombre de usuario del usuario del software (no solo la máquina, que está disponible con la mayoría de los registradores). En algunos casos, las cuentas de usuario automatizadas causaron problemas, mientras que en otros, usuarios específicos fueron la causa de los problemas. "Necesito ver a Mike hacer un trabajo, él sigue causando un error específico".
• "Acciones del usuario": tenía una pila global que mantendría un rastro de cada pulsación de botón / botón accionable tal como lo hizo el usuario y lo agregó a los registros de errores. La reproducción del error fue a menudo un caso de caminar a través de esa traza y realizar los mismos pasos que el usuario (esperaba construir un generador de prueba CodedUI que analizara la traza y realizara los pasos automáticamente, pero nunca lo hizo)

A veces, la información de registro es demasiado voluminosa para ser almacenada en el disco. Un enfoque que he visto es escribir sus entradas de registro en un firehose (en, digamos, perl) algo como esto:

# Create socket.
my $sock = IO::Socket::INET->new(
    Proto       => 'udp',
    PeerAddr    => $bcastaddr,
    Broadcast   => 1,
) or die "Can't create socket ($bcastaddr): $!";

while (<>) {
    chomp;
    unless (/File\ does\ not\ exist:/) {
        $sock->send("$eventtype:$_") or warn "Can't send: $!";
    }
}

entonces un analista puede averiguar qué quiere mirar.

Aquí hay algunas cosas que aprendí del monitoreo de errores en nuestras aplicaciones:

• Ser capaz de seguir un archivo de registro continuo (generalmente uso log4net / log4j para iniciar sesión en aplicaciones y BareTail para seguir el registro) es realmente útil para poder verificar el estado actual de un sistema
• Para ver cuándo se introdujeron los problemas y la velocidad a la que ocurren, es bueno tenerlos en una base de datos con marcas de tiempo para que pueda ejecutar informes.
• La capacidad de enviar alertas por correo electrónico / sms / voz es muy útil para garantizar que los sistemas se mantengan activos, pero debe tener la capacidad de personalizar fácilmente qué tipos de errores lo alertan. Si recibe 800 correos electrónicos de error al día, seguramente perderá el mensaje "Oh, no, el centro de datos está en llamas".

He tenido excelentes resultados para log4net porque hace que sea muy fácil iniciar sesión en varios lugares y también facilita los cambios en la configuración de registro.

elmah es un sistema de registro de errores de código abierto para aplicaciones ASP.NET y se puede agregar a un sistema existente (usando NuGet http://nuget.codeplex.com/ ) de manera rápida y fácil. Es compatible con varios backends y funciones de notificación.

No conozco a nadie que lo haya agregado a una aplicación de escritorio, ya que se ejecuta como un sitio web, pero no hay nada que le impida ejecutarlo como un servicio y publicar sus excepciones a través de la web.

http://code.google.com/p/elmah/

ELMAH (Módulos y controladores de registro de errores) es una instalación de registro de errores para toda la aplicación que es completamente conectable. Se puede agregar dinámicamente a una aplicación web ASP.NET en ejecución, o incluso a todas las aplicaciones web ASP.NET en una máquina, sin necesidad de volver a compilar o volver a implementar.

Una vez que ELMAH se ha introducido en una aplicación web en ejecución y se ha configurado adecuadamente, obtiene las siguientes facilidades sin cambiar una sola línea de su código:

• Registro de casi todas las excepciones no manejadas.
• Una página web para ver de forma remota todo el registro de excepciones recodificadas.
• Una página web para ver de forma remota los detalles completos de cualquier excepción registrada, incluidas las trazas de pila de colores.
• En muchos casos, puede revisar la pantalla amarilla original de la muerte que ASP.NET generó para una excepción dada, incluso con el customErrorsmodo desactivado.
• Una notificación por correo electrónico de cada error en el momento en que ocurre.
• Una fuente RSS de los últimos 15 errores del registro ...