Trabajo con sistemas críticos de seguridad en tiempo real y el registro es a menudo la única forma de atrapar errores raros que aparecen una vez que hay luna azul cada martes 53 cuando hay luna llena, si me entiendes. Esto te hace obsesivo con el tema, así que me disculparé ahora si empiezo a hacer espuma en la boca. Lo siguiente se escribió para los registros de depuración de código nativo, pero la mayor parte también es aplicable al mundo administrado ...
Use archivos de registro de texto. Parece obvio, pero algunas personas intentan generar archivos de registro binarios: eso es tonto porque no necesito buscar una herramienta de lectura cuando estoy en el campo. Además, si se trata de texto y la depuración es detallada, existe una buena posibilidad de que el ingeniero de campo pueda leer el archivo y diagnosticar el problema sin tener que volver a consultarme. Todos ganan.
Diseño sistemas que son capaces de registrar casi todo, pero no enciendo todo por defecto. La información de depuración se envía a un cuadro de diálogo de depuración oculto que la marca de tiempo y la envía a un cuadro de lista (limitado a alrededor de 500 líneas antes de la eliminación), y el cuadro de diálogo me permite detenerlo, guardarlo en un archivo de registro automáticamente o desviarlo a un depurador adjunto. Ese desvío me permite ver la salida de depuración de múltiples aplicaciones, todas bien serializadas, lo que a veces puede ser un salvavidas. Yo solía utilizar niveles de registro numéricos (el más alto sea el nivel, más se captura):
off
errors only
basic
detailed
everything
pero esto es demasiado inflexible: a medida que avanza hacia un error, es mucho más eficiente poder concentrarse en iniciar sesión exactamente en lo que necesita sin tener que atravesar toneladas de detritos, y puede ser un tipo particular de transacción u operación eso causa el error. Si eso requiere que encienda todo, solo está haciendo su propio trabajo más difícil. Necesitas algo más fino.
Así que ahora estoy en el proceso de cambiar al registro basado en un sistema de bandera. Todo lo que se registra tiene una bandera que detalla qué tipo de operación es, y hay un conjunto de casillas de verificación que me permiten definir qué se registra. Por lo general, esa lista se ve así:
#define DEBUG_ERROR 1
#define DEBUG_BASIC 2
#define DEBUG_DETAIL 4
#define DEBUG_MSG_BASIC 8
#define DEBUG_MSG_POLL 16
#define DEBUG_MSG_STATUS 32
#define DEBUG_METRICS 64
#define DEBUG_EXCEPTION 128
#define DEBUG_STATE_CHANGE 256
#define DEBUG_DB_READ 512
#define DEBUG_DB_WRITE 1024
#define DEBUG_SQL_TEXT 2048
#define DEBUG_MSG_CONTENTS 4096
Este sistema de registro se envía con la versión de lanzamiento , activada y guardada en el archivo de forma predeterminada. Es demasiado tarde para descubrir que debería haber estado iniciando sesión DESPUÉS de que ocurrió el error, si ese error solo ocurre una vez cada seis meses en promedio y no tiene forma de reproducirlo. El registro que solo funciona con compilaciones de depuración es justo. llanura. tonto.
El software generalmente se entrega con ERROR, BASIC, STATE_CHANGE y EXCEPTION activados, pero esto se puede cambiar en el campo a través del diálogo de depuración (o una configuración de registro / ini / cfg, donde se guardan estas cosas).
Ah, y una cosa: mi sistema de depuración genera un archivo por día. Sus requisitos pueden ser diferentes. Pero asegúrese de que su código de depuración comience cada archivo con la fecha, la versión del código que está ejecutando y, si es posible, algún marcador para la identificación del cliente, la ubicación del sistema o lo que sea. Puede obtener una mezcla de archivos de registro desde el campo, y necesita un registro de lo que vino de dónde y qué versión del sistema estaban ejecutando que está realmente en los datos, y no puede confiar en el cliente / ingeniero de campo para decirte qué versión tienen, pueden simplemente decirte qué versión piensan que tienen. Peor aún, pueden informar la versión exe que está en el disco, pero la versión anterior todavía se está ejecutando porque olvidaron reiniciar después de reemplazarla. Haz que tu código te lo diga a ti mismo.
Por último, no desea que su código genere sus propios problemas, por lo tanto, coloque una función de temporizador para purgar los archivos de registro después de tantos días o semanas (solo verifique la diferencia entre la hora actual y la hora de creación del archivo). Esto está bien para una aplicación de servidor que se ejecuta todo el tiempo, en una aplicación del lado del cliente que puede solucionar purgando los datos antiguos cuando se inicia. Por lo general, purgamos después de aproximadamente 30 días, en un sistema sin visitas frecuentes de ingenieros, es posible que desee dejarlo más tiempo. Obviamente, esto también depende del tamaño de sus archivos de registro.