Trabajo con sistemas críticos de seguridad en tiempo real y el registro es a menudo la única forma de detectar errores raros que aparecen una vez en la luna azul cada 53. ° martes, cuando es luna llena, si capta mi deriva. Esto te hace obsesivo con el tema, así que me disculparé ahora si empiezo a echar espuma por la boca. Lo siguiente se escribió para los registros de depuración de código nativo, pero la mayoría de ellos se aplica también al mundo administrado ...
Usa archivos de registro de texto. Parece obvio, pero algunas personas intentan generar archivos de registro binarios: eso es estúpido 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 la posibilidad de que el ingeniero de campo pueda leer el archivo y diagnosticar el problema sin volver a consultarme. Todo el mundo gana.
Diseño sistemas que son capaces de registrar casi todo, pero no enciendo todo de forma predeterminada. La información de depuración se envía a un cuadro de diálogo de depuración oculto que lo marca y lo envía a un cuadro de lista (limitado a unas 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. Esa desviación me permite ver la salida de depuración de múltiples aplicaciones, todas perfectamente serializadas, lo que a veces puede ser un salvavidas. Usé para usar niveles de registro numérico (cuanto más alto establezca el nivel, más capturará):
off
errors only
basic
detailed
everything
pero esto es demasiado inflexible: a medida que te abres camino hacia un error, es mucho más eficiente poder enfocarte en iniciar sesión exactamente en lo que necesitas sin tener que atravesar toneladas de detritus, y puede ser un tipo particular de Transacción u operación que provoca el error. Si eso requiere que enciendas todo, solo estás haciendo tu propio trabajo más difícil. Necesitas algo más fino.
Así que ahora estoy en el proceso de cambiarme al registro basado en un sistema de bandera. Todo lo que se registra tiene una marca que detalla qué tipo de operación es, y hay un conjunto de casillas de verificación que me permiten definir qué se registra. Normalmente 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 versión , está activado y se guarda en el archivo de forma predeterminada. Es demasiado tarde para descubrir que debería haber estado registrando DESPUÉS de que se haya producido 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 las versiones de depuración es justo. llanura. tonto.
El software normalmente se envía con ERROR, BASIC, STATE_CHANGE y EXCEPTION activados, pero esto se puede cambiar en el campo a través del cuadro de 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 inicie todos los archivos con la fecha, la versión del código que está ejecutando y, si es posible, algún marcador para la ID del cliente, la ubicación del sistema o lo que sea. Puede obtener una mezcla de archivos de registro desde el campo, y necesita algún registro de lo que vino de dónde y qué versión del sistema que estaban ejecutando, que está realmente en los datos en sí, y no puede confiar en el cliente / Ingeniero de campo para decirle qué versión tienen, es posible que solo le digan 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 se olvidó de reiniciar después de reemplazarla. Haga que su código se lo diga a usted mismo.
Por último, no desea que su código genere sus propios problemas, así que ponga 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 obtener con la purga de datos antiguos cuando se inicia. Por lo general, hacemos purga después de 30 días aproximadamente, en un sistema sin frecuentes visitas de ingenieros, es posible que desee dejarlo por más tiempo. Obviamente, esto también depende del tamaño de sus archivos de registro.