(Windows) Manejo de excepciones: al registro de eventos o a la base de datos?

Question

He trabajado en tiendas donde implementé Exception Handling en el registro de eventos y en una tabla en la base de datos.

Cada uno tiene sus méritos, de los cuales puedo destacar algunas basado en mi experiencia:

registro de eventos

• Industria ubicación estándar para excepciones (+)
• Facilidad de extracción de madera (+)
• puede registrar los problemas de conexión de base de datos aquí (+)
• puede construir informe y aplicaciones de visualización en la parte superior del registro de eventos (+)
• tiene que ser eliminados de vez en cuando, si mucho se informa allí (-)
• No es tan extensible como SQL registro [añadir campos personalizados como el nombre del método en SQL] (-)

SQL/Base de datos

• puede manejar grandes volúmenes de datos (+)
• puede manejar insertos de volumen rápidos de excepciones (+)
• ubicación de almacenamiento individual para excepción en el entorno de equilibrio de carga (+)
• muy personalizable (+)
• un poco más fácil de construir informes/notificaciones fuera del almacenamiento de SQL (+)
• diferente de donde se almacenan excepciones típicas (-)

Me estoy perdiendo cualquier consideración principales ?

Estoy seguro de que algunos de estos puntos son discutibles, pero tengo curiosidad por saber qué ha funcionado mejor para otros equipos, y por qué está muy interesado en la elección.

Answer 1

Debe diferenciar entre el registro y el seguimiento. Si bien las líneas son un poco confusas, tiendo a pensar en iniciar sesión como "cosas que no son de desarrollador". Cosas como excepciones no controladas, archivos corruptos, etc. Definitivamente no son normales, y deberían ser un problema muy poco frecuente.

El rastreo es lo que le interesa a un desarrollador. Los rastreos de la pila, los parámetros del método, que el servidor web devolvió un estado HTTP de 401.3, etc. Estos son realmente ruidosos y pueden producir una gran cantidad de datos en una pequeña cantidad hora. Normalmente tenemos diferentes niveles de rastreo para reducir el ruido.

Para iniciar sesión en una aplicación de cliente, creo que los registros de eventos son el camino a seguir (tendría que verificarlo dos veces, pero creo que ASP.NET Health Monitoring también puede escribir en el registro de eventos). Los usuarios normales tienen permisos para escribir en el registro de eventos, siempre que tenga la configuración (que es instalada por un administrador de todos modos) cree el origen del evento.

La mayor parte de sus ventajas para el registro de SQL, mientras que la verdadera, no son aplicables a registro de eventos:

• puede manejar grandes volúmenes de datos: lo que realmente tienen grandes volúmenes de excepciones no controladas u otro alto fallas de nivel?
• Puede manejar insertos de volumen rápido de excepciones: Una sola excepción no controlada debe hacer que su aplicación baje, es intrínsecamente limitada. Otros eventos interesantes para no desarrolladores deberían agregarse de manera similar.
• Muy personalizable: El mensaje en un Registro de eventos es prácticamente texto libre. Si necesita más información, simplemente apunte a un archivo de texto o XML estructurado o registro de archivo binario
• Un poco más fácil de generar informes/notificaciones fuera del almacenamiento de SQL: Los informes están integrados con el Visor de registro de eventos, y los sistemas de notificación son , ya sea inherente (debido a un bloqueo de la aplicación) o mezclado con otras notificaciones realmente críticas, hay pocas excusas para perder un mensaje del registro de eventos. Para aplicaciones corporativas u otras aplicaciones en red, hay mil y 1 aplicaciones diferentes que ya eliminan los registros de eventos en busca de errores ... es probable que su administrador de sistemas ya esté usando uno.

Para trazar , de los cuales los detalles específicos de una excepción o errores es una parte de, me gusta archivos planos - que son fáciles de mantener, fácil de grep, y se pueden importar a SQL para análisis si me gusta

90% del tiempo, no los necesita y están configurados para ADVERTENCIA o ERROR. Pero, cuando los configure en INFO o DEPURAR, generará un tonelada de datos. Un RDBMS tiene una gran sobrecarga: por rendimiento (ACID, concurrencia, etc.), almacenamiento (registros de transacciones, unidades SCSI RAID-5, etc.) y administración (copias de seguridad, mantenimiento del servidor, etc.), todas ellas innecesario para los registros de seguimiento.

Answer 2

Una nota sobre cómo escribir en el registro de eventos: que requiere ciertos permisos para los usuarios de su aplicación que en algunos entornos pueden estar restringidos por defecto.

Donde estoy, hacemos la mayor parte de nuestro registro en una base de datos, con archivos planos como respaldo. Es bastante agradable, podemos hacer cosas como obtener un feed RSS de una aplicación para ver durante unos días cuando hacemos un cambio.

Answer 3

Una cosa que debe considerar sobre el registro de eventos es que hay productos que pueden monitorear los registros de eventos de sus servidores (como Microsoft Operations Manager) e inteligentemente hacer notificaciones, y recopilar estadísticas sobre sus contenidos.

Un "menos" de registro basado en SQL es que agrega otra capa de dependencias a su aplicación, que puede o no ser siempre aceptable. He hecho ambas cosas en mi carrera. Una o dos veces incluso utilicé una cola de mensajes basada en MSMQ para poner en cola los eventos de registro y vaciar la cola en una base de datos MSSQL para eliminar la necesidad de que mi software cliente tenga una conexión con el DB.

Answer 4

No registraría directamente en la base de datos.Como dices, los problemas de la base de datos se vuelven complicados para iniciar sesión :)

Me conectaría al sistema de archivos y luego tendría un trabajo que incluye inserciones masivas desde los archivos a la base de datos. Personalmente, me gusta tener los registros en la base de datos en el registro ejecutado principalmente para la situación de escalado: casi asumo que tendré más de una máquina ejecutándose, y es útil para poder tener un registro combinado. (Cada entrada debe indicar la máquina de la que proviene, por supuesto)

El informe y la visualización de las aplicaciones se pueden realizar fácilmente desde una base de datos; puede haber menos herramientas de generación de informes especializadas actualmente, pero casi todas las bases de datos tienen una funcionalidad de informes generalizada.

Para facilitar el registro, usaría un framework como log4net, que requiere mucho esfuerzo y es una solución probada. Aparte de cualquier otra cosa, eso significa que puedes cambiar tu estrategia de salida sin cambios de código. Incluso puede iniciar sesión en el registro de eventos y la base de datos si es necesario, o enviar algunos registros a un lugar y algunos a otro. (Asumí .NET aquí, pero existen marcos de registro similares para muchas plataformas).