Cuándo usar los diferentes niveles de registro

Hay diferentes formas de registrar mensajes, en orden de fatalidad:

1. FATAL

2. ERROR

3. WARN

4. INFO

5. DEBUG

6. TRACE

¿Cómo decido cuándo usar cuál?

¿Qué es una buena heurística para usar?

Generalmente me suscribo a la siguiente convención:

• Rastreo : solo cuando estaría "rastreando" el código e intentando encontrar una parte de una función específicamente.
• Depuración : información que es útil para el diagnóstico de las personas más que solo desarrolladores (TI, administradores de sistemas, etc.).
• Información : información generalmente útil para iniciar sesión (inicio / detención del servicio, supuestos de configuración, etc.). Información que quiero tener siempre disponible, pero generalmente no me importa en circunstancias normales. Este es mi nivel de configuración listo para usar.
• Advertir : cualquier cosa que pueda causar rarezas en la aplicación, pero para la que me estoy recuperando automáticamente. (Como cambiar de un servidor primario a uno de respaldo, reintentar una operación, faltar datos secundarios, etc.)
• Error : cualquier error que sea fatal para la operación , pero no para el servicio o la aplicación (no se puede abrir un archivo requerido, datos faltantes, etc.). Estos errores forzarán la intervención del usuario (administrador o usuario directo). Por lo general, están reservados (en mis aplicaciones) para cadenas de conexión incorrectas, servicios faltantes, etc.
• Fatal : cualquier error que obligue a cerrar el servicio o la aplicación para evitar la pérdida de datos (o una mayor pérdida de datos). Los reservo solo para los errores más atroces y las situaciones en las que se garantiza que ha habido corrupción o pérdida de datos.

¿Desea que el mensaje saque a un administrador del sistema de la cama en medio de la noche?

• sí -> error
• no -> advertir

Me resulta más útil pensar en las severidades desde la perspectiva de ver el archivo de registro.

Fatal / Crítico : falla general de la aplicación o del sistema que debe investigarse de inmediato. Sí, despierta el SysAdmin. Como preferimos nuestra alerta SysAdmins y descansamos bien, esta gravedad debe usarse con poca frecuencia. Si sucede a diario y eso no es un BFD, se pierde su significado. Por lo general, un error fatal solo ocurre una vez en la vida útil del proceso, por lo que si el archivo de registro está vinculado al proceso, este suele ser el último mensaje en el registro.

Error : Definitivamente un problema que debe ser investigado. SysAdmin debería ser notificado automáticamente, pero no necesita ser arrastrado fuera de la cama. Al filtrar un registro para ver los errores y más arriba, obtiene una visión general de la frecuencia de errores y puede identificar rápidamente la falla inicial que podría haber resultado en una cascada de errores adicionales. El seguimiento de las tasas de error en comparación con el uso de la aplicación puede proporcionar métricas de calidad útiles, como MTBF, que se pueden utilizar para evaluar la calidad general. Por ejemplo, esta métrica podría ayudar a informar las decisiones sobre si se necesita o no otro ciclo de prueba beta antes de un lanzamiento.

Advertencia : esto PUEDE ser un problema, o podría no serlo. Por ejemplo, las condiciones ambientales transitorias esperadas, como la pérdida corta de la conectividad de la red o la base de datos, deben registrarse como Advertencias, no como Errores. Ver un registro filtrado para mostrar solo advertencias y errores puede dar una idea rápida de los primeros indicios sobre la causa raíz de un error posterior. Las advertencias deben usarse con moderación para que no tengan sentido. Por ejemplo, la pérdida de acceso a la red debería ser una advertencia o incluso un error en una aplicación de servidor, pero podría ser solo una información en una aplicación de escritorio diseñada para usuarios de computadoras portátiles ocasionalmente desconectados.

Información : Esta es información importante que debe registrarse en condiciones normales, como la inicialización exitosa, el inicio y la detención de servicios o la finalización exitosa de transacciones significativas. Ver un registro que muestre información y más arriba debería proporcionar una visión general rápida de los principales cambios de estado en el proceso, proporcionando un contexto de nivel superior para comprender cualquier advertencia o error que también ocurra. No tengo demasiados mensajes de información. Por lo general, tenemos <5% de mensajes de información en relación con Trace.

Rastreo : El rastreo es, con mucho, la gravedad más utilizada y debe proporcionar un contexto para comprender los pasos que conducen a errores y advertencias. Tener la densidad adecuada de mensajes de seguimiento hace que el software sea mucho más fácil de mantener, pero requiere cierta diligencia porque el valor de las declaraciones de seguimiento individuales puede cambiar con el tiempo a medida que los programas evolucionan. La mejor manera de lograr esto es conseguir que el equipo de desarrollo se habitúe a revisar regularmente los registros como parte estándar de la resolución de problemas informados por los clientes. Aliente al equipo a eliminar los mensajes de Trace que ya no proporcionan un contexto útil y a agregar mensajes donde sea necesario para comprender el contexto de los mensajes posteriores. Por ejemplo, a menudo es útil registrar la entrada del usuario, como cambiar pantallas o pestañas.

Debug : consideramos Debug <Trace. La distinción es que los mensajes de depuración se compilan a partir de versiones de lanzamiento. Dicho esto, desaconsejamos el uso de mensajes de depuración. Permitir mensajes de depuración tiende a generar más y más mensajes de depuración que se agregan y nunca se eliminan. Con el tiempo, esto hace que los archivos de registro sean casi inútiles porque es demasiado difícil filtrar la señal del ruido. Eso hace que los desarrolladores no usen los registros, lo que continúa la espiral de la muerte. Por el contrario, podar constantemente los mensajes de Trace alienta a los desarrolladores a usarlos, lo que resulta en una espiral virtuosa. Además, esto elimina la posibilidad de errores introducidos debido a los efectos secundarios necesarios en el código de depuración que no está incluido en la compilación de lanzamiento. Sí, sé que eso no debería suceder en un buen código, pero es mejor prevenir que curar.

Aquí hay una lista de lo que tienen "los madereros".

Apache log4j: §1 , §2

1. FATAL:

   [ v1.2 : ..] eventos de error muy graves que presumiblemente llevarán a la aplicación a abortar.

   [ v2.0 : ..] error grave que impedirá que la aplicación continúe.

2. ERROR:

   [ v1.2 : ..] eventos de error que aún podrían permitir que la aplicación continúe ejecutándose.

   [ v2.0 : ..] error en la aplicación, posiblemente recuperable.

3. WARN:

   [ v1.2 : ..] situaciones potencialmente dañinas.

   [ v2.0 : ..] evento que podría provocar [ sic ] un error.

4. INFO:

   [ v1.2 : ..] mensajes informativos que resaltan el progreso de la aplicación a nivel de grano grueso.

   [ v2.0 : ..] evento con fines informativos.

5. DEBUG:

   [ v1.2 : ..] eventos informativos detallados que son más útiles para depurar una aplicación.

   [ v2.0 : ..] evento de depuración general.

6. TRACE:

   [ v1.2 : ..] eventos informativos más finos que el DEBUG.

   [ v2.0 : ..] mensaje de depuración detallado, que generalmente captura el flujo a través de la aplicación.

A Apache Httpd (como siempre) le gusta ir por la exageración: §

1. emerg :

   Emergencias: el sistema no se puede utilizar.

2. alerta :

   Se deben tomar medidas de inmediato [pero el sistema aún se puede usar].

3. crítico :

   Condiciones críticas [pero no es necesario tomar medidas de inmediato].

   • " socket: no se pudo obtener un socket al salir del niño "

4. error :

   Condiciones de error [pero no críticas].

   • " Fin prematuro de los encabezados de script "

5. advertir :

   Condiciones de advertencia [cerca del error, pero no del error]

6. aviso :

   Condición normal pero significativa [ notable ].

   • " httpd: atrapado SIGBUS, intentando volcar el núcleo en ... "

7. info :

   Informativo [y no notificable].

   • ["El servidor ha estado funcionando durante x horas "]

8. depurar :

   Mensajes de nivel de depuración [, es decir, mensajes registrados para eliminar errores )].

   • " Abriendo archivo de configuración ... "

9. trace1 → trace6 :

   Rastrear mensajes [, es decir, mensajes registrados por el bien del rastreo ].

   • " proxy: FTP: conexión de control completa "
   • " proxy: CONNECT: enviando la solicitud CONNECT al proxy remoto "
   • " openssl: Apretón de manos: inicio "
   • " leer de la brigada SSL almacenada en el búfer, modo 0, 17 bytes "
   • "la búsqueda del mapa FALLÓ:map=rewritemap key=keyname "
   • " Falló la búsqueda en caché, forzando una nueva búsqueda en el mapa "

10. trace7 → trace8 :

    Rastrear mensajes, volcar grandes cantidades de datos

    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"
    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"

Apache commons-logging: §

1. fatal :

   Errores graves que causan terminación prematura. Espere que estos sean visibles de inmediato en una consola de estado.

2. error :

   Otros errores de tiempo de ejecución o condiciones inesperadas. Espere que estos sean visibles de inmediato en una consola de estado.

3. advertir :

   Uso de API en desuso, mal uso de API, 'casi' errores, otras situaciones de tiempo de ejecución que son indeseables o inesperadas, pero no necesariamente "incorrectas". Espere que estos sean visibles de inmediato en una consola de estado.

4. info :

   Eventos de tiempo de ejecución interesantes (inicio / apagado). Espere que estos sean visibles de inmediato en una consola, así que sea conservador y manténgalo al mínimo.

5. depurar :

   información detallada sobre el flujo a través del sistema. Espere que estos se escriban solo en los registros.

6. rastro :

   Información más detallada. Espere que estos se escriban solo en los registros.

Las "mejores prácticas" de registro común de Apache para el uso empresarial hacen una distinción entre depuración e información en función del tipo de límites que cruzan.

Los límites incluyen:

• Límites externos: excepciones esperadas.

• Límites externos: excepciones inesperadas.

• Límites internos.

• Límites internos significativos.

(Consulte la guía de registro de comunes para obtener más información al respecto).

Si puede recuperarse del problema, entonces es una advertencia. Si impide la ejecución continua, entonces es un error.

Me gustaría recomendar la adopción de niveles de gravedad Syslog: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY.
Ver http://en.wikipedia.org/wiki/Syslog#Severity_levels

Deben proporcionar suficientes niveles de gravedad de grano fino para la mayoría de los casos de uso y son reconocidos por los analizadores de registros existentes. Si bien, por supuesto, tiene la libertad de implementar solo un subconjunto, por ejemplo, DEBUG, ERROR, EMERGENCYdependiendo de los requisitos de su aplicación.

Estandaricemos en algo que ha existido por años en lugar de crear nuestro propio estándar para cada aplicación diferente que creamos. Una vez que comience a agregar registros e intente detectar patrones en diferentes, realmente ayuda.

Advertencias de las que puede recuperarse. Errores que no puedes Esa es mi heurística, otros pueden tener otras ideas.

Por ejemplo, supongamos que ingresa / importa el nombre "Angela Müller"en su aplicación (observe la diéresis sobre u). Su código / base de datos puede estar solo en inglés (aunque probablemente no debería estar en este día y edad) y, por lo tanto, podría advertir que todos los caracteres "inusuales" se han convertido a caracteres ingleses normales.

Compare eso con intentar escribir esa información en la base de datos y recuperar un mensaje de red inactiva durante 60 segundos seguidos. Eso es más un error que una advertencia.

Como otros han dicho, los errores son problemas; Las advertencias son problemas potenciales.

En el desarrollo, con frecuencia utilizo advertencias en las que podría poner el equivalente de una falla de aserción pero la aplicación puede continuar funcionando; Esto me permite saber si ese caso realmente sucede, o si es mi imaginación.

Pero sí, se reduce a los aspectos de recuperación y actualidad. Si puede recuperarse, probablemente sea una advertencia; si hace que algo falle realmente, es un error.

Creo que los niveles de SYSLOG AVISO y ALERTA / EMERGENCIA son en gran medida superfluos para el registro a nivel de aplicación, mientras que CRÍTICO / ALERTA / EMERGENCIA pueden ser niveles de alerta útiles para un operador que puede desencadenar diferentes acciones y notificaciones, para un administrador de aplicaciones es todo lo mismo que FATAL. Y simplemente no puedo distinguir suficientemente entre recibir un aviso o alguna información. Si la información no es notable, no es realmente información :)

Me gusta más la interpretación de Jay Cincotta: rastrear la ejecución de su código es algo muy útil en el soporte técnico, y debería alentarse poner declaraciones de rastreo en el código liberalmente, especialmente en combinación con un mecanismo de filtrado dinámico para registrar los mensajes de rastreo de componentes de aplicaciones específicas. Sin embargo, el nivel de DEPURACIÓN para mí indica que todavía estamos en el proceso de descubrir qué está sucediendo: veo la salida del nivel de DEPURACIÓN como una opción solo de desarrollo, no como algo que debería aparecer en un registro de producción.

Sin embargo, hay un nivel de registro que me gusta ver en mis registros de errores cuando uso el sombrero de un administrador de sistemas tanto como el de soporte técnico, o incluso desarrollador: OPER, para mensajes OPERACIONALES. Esto lo uso para registrar una marca de tiempo, el tipo de operación invocada, los argumentos suministrados, posiblemente un identificador de tarea (único) y la finalización de la tarea. Se utiliza, por ejemplo, cuando se activa una tarea independiente, algo que es una invocación verdadera desde la aplicación más grande de larga duración. Es el tipo de cosas que siempre quiero registrar, sin importar si algo sale mal o no, así que considero que el nivel de OPER es más alto que FATAL, por lo que solo puede apagarlo yendo al modo totalmente silencioso. Y es mucho más que simples datos de registro INFO: un nivel de registro que a menudo se abusa para enviar correos electrónicos no deseados con mensajes operativos menores sin ningún valor histórico.

Según lo dicte el caso, esta información puede dirigirse a un registro de invocación separado, o puede obtenerse filtrándola de un registro grande que registra más información. Pero siempre se necesita, como información histórica, saber lo que se estaba haciendo, sin descender al nivel de AUDIT, otro nivel de registro totalmente separado que no tiene nada que ver con el mal funcionamiento o el funcionamiento del sistema, realmente no cabe dentro de los niveles anteriores ( ya que necesita su propio interruptor de control, no una clasificación de gravedad) y que definitivamente necesita su propio archivo de registro separado.

Desde RFC 5424, el Protocolo Syslog (IETF) - Página 10:

Cada mensaje de prioridad también tiene un indicador de nivel de gravedad decimal. Estos se describen en la siguiente tabla junto con sus valores numéricos. Los valores de gravedad DEBEN estar en el rango de 0 a 7 inclusive.

       Numerical         Severity
         Code

          0       Emergency: system is unusable
          1       Alert: action must be taken immediately
          2       Critical: critical conditions
          3       Error: error conditions
          4       Warning: warning conditions
          5       Notice: normal but significant condition
          6       Informational: informational messages
          7       Debug: debug-level messages

          Table 2. Syslog Message Severities

G'day

Como corolario de esta pregunta, comunique sus interpretaciones de los niveles de registro y asegúrese de que todas las personas en un proyecto estén alineadas en su interpretación de los niveles.

Es doloroso ver una gran variedad de mensajes de registro donde las severidades y los niveles de registro seleccionados son inconsistentes.

Proporcione ejemplos, si es posible, de los diferentes niveles de registro. Y sea coherente en la información que se registrará en un mensaje.

HTH

Estoy totalmente de acuerdo con los demás, y creo que GrayWizardx lo dijo mejor.

Todo lo que puedo agregar es que estos niveles generalmente corresponden a sus definiciones de diccionario, por lo que no puede ser tan difícil. En caso de duda, trátelo como un rompecabezas. Para su proyecto particular, piense en todo lo que quiera registrar.

Ahora, ¿puedes descubrir lo que podría ser fatal? Sabes lo que significa fatal, ¿no? Entonces, qué elementos de tu lista son fatales.

Ok, eso es fatal, ahora veamos los errores ... enjuague y repita.

Debajo de Fatal, o tal vez Error, sugeriría que más información siempre es mejor que menos, así que errar "hacia arriba". ¿No está seguro si es información o advertencia? Entonces hazlo una advertencia.

Creo que Fatal y error deberían ser claros para todos nosotros. Los otros pueden ser más difusos, pero podría decirse que es menos vital hacerlos bien.

Aquí hay unos ejemplos:

Fatal : no se puede asignar memoria, base de datos, etc., no se puede continuar.

Error : no hay respuesta al mensaje, transacción cancelada, no se puede guardar el archivo, etc.

Advertencia : la asignación de recursos alcanza el X% (digamos 80%), eso es una señal de que es posible que desee cambiar el tamaño de su.

Información : usuario conectado / desconectado, nueva transacción, archivo creado, nuevo campo d / b o campo eliminado.

Depuración : volcado de la estructura de datos interna, nivel de rastreo de cualquier cosa con nombre de archivo y número de línea.
Rastreo - acción exitosa / fallida, d / b actualizada.

Un error es algo que está mal, simplemente mal, no hay forma de evitarlo, necesita ser reparado.

Una advertencia es una señal de un patrón que podría estar equivocado, pero que también podría no estarlo.

Dicho esto, no puedo encontrar un buen ejemplo de una advertencia que no sea también un error. Lo que quiero decir con eso es que si te tomas la molestia de registrar una advertencia, también podrías solucionar el problema subyacente.

Sin embargo, cosas como "la ejecución de SQL tarda demasiado" podría ser una advertencia, mientras que los "puntos muertos de ejecución de SQL" son un error, así que quizás hay algunos casos después de todo.

Siempre he considerado advertir al primer nivel de registro que con seguridad significa que hay un problema (por ejemplo, tal vez un archivo de configuración no esté donde debería estar y tendremos que ejecutarlo con la configuración predeterminada). Un error implica, para mí, algo que significa que el objetivo principal del software ahora es imposible y vamos a tratar de cerrarlo limpiamente.

He construido sistemas antes que usan lo siguiente:

1. ERROR: significa que algo está muy mal y que ese hilo / proceso / secuencia en particular no puede continuar. Se requiere alguna intervención del usuario / administrador
2. ADVERTENCIA: algo no está bien, pero el proceso puede continuar como antes (por ejemplo, un trabajo en un conjunto de 100 ha fallado, pero el resto puede procesarse)

En los sistemas que he construido, los administradores tenían instrucciones de reaccionar ante ERRORES. Por otro lado, estaríamos atentos a las ADVERTENCIAS y determinaríamos para cada caso si se requerían cambios en el sistema, reconfiguraciones, etc.

Por cierto, soy un gran fanático de capturar todo y filtrar la información más tarde.

¿Qué pasaría si estuviera capturando en el nivel de Advertencia y deseara información de depuración relacionada con la advertencia, pero no pudiera volver a crear la advertencia?

¡Capture todo y filtre más tarde!

Esto es válido incluso para el software integrado a menos que descubra que su procesador no puede mantener el ritmo, en cuyo caso es posible que desee rediseñar su rastreo para hacerlo más eficiente, o el rastreo interfiere con el tiempo ( puede considerar depurarlo en un procesador más potente, pero que abre una gran lata de gusanos).

¡Captura todo y filtra más tarde!

(por cierto, capturar todo también es bueno porque te permite desarrollar herramientas para hacer más que solo mostrar el seguimiento de depuración (dibujo los cuadros de secuencia de mensajes de los míos y los histogramas de uso de memoria. También te da una base para comparar si algo sale mal en futuro (mantenga todos los registros, ya sea aprobados o no, y asegúrese de incluir el número de compilación en el archivo de registro)).

Mis dos centavos sobre FATALy TRACEniveles de registro de error.

ERROR es cuando ocurre una FALLA (excepción).

FATAL en realidad es DOBLE FALLA: cuando ocurre una excepción mientras se maneja la excepción.

Es fácil de entender para el servicio web.

1. Solicitud ven. El evento se registra comoINFO
2. El sistema detecta poco espacio en disco. El evento se registra comoWARN
3. Se llama a alguna función para manejar la solicitud. Mientras se produce la división por cero. El evento se registra comoERROR
4. Se llama al manejador de excepciones del servicio web para manejar la división por cero. El servicio web / marco enviará un correo electrónico, pero no puede porque el servicio de correo está fuera de línea ahora. Esta segunda excepción no se puede manejar normalmente, porque el controlador de excepciones del servicio web no puede procesar la excepción.
5. Se llamó un controlador de excepción diferente. El evento se registra comoFATAL

TRACEes cuando podemos rastrear la entrada / salida de la función. No se trata de iniciar sesión, porque este mensaje puede ser generado por algún depurador y su código no ha llamado logen absoluto. Entonces los mensajes que no son de su aplicación están marcados como TRACEnivel. Por ejemplo, ejecuta su aplicación constrace

Por lo general, en su programa lo hace DEBUG, INFOy el WARNregistro. Y solo si está escribiendo algún servicio / marco web que usará FATAL. Y cuando esté depurando la aplicación, se TRACEregistrará desde este tipo de software.

Sugiero usar solo tres niveles

1. Fatal: lo que rompería la aplicación.
2. Información - Información
3. Depuración: información menos importante