Cuándo usar los diferentes niveles de registro

Hay diferentes maneras 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?

En general 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 desde el punto de vista del diagnóstico para las personas más que solo para desarrolladores (TI, administradores de sistemas, etc.).
  • Información : información generalmente útil para el registro (inicio / detención del servicio, suposiciones de configuración, etc.). Información que quiero tener siempre disponible, pero por lo general no me importa en circunstancias normales. Este es mi nivel de configuración listo para usar.
  • Advertir : cualquier cosa que pueda causar anomalías en la aplicación, pero que me estoy recuperando automáticamente. (Como cambiar de un servidor primario a uno de respaldo, reintentar una operación, perder 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). Suelen estar reservados (en mis aplicaciones) para cadenas de conexión incorrectas, servicios faltantes, etc.
  • Fatal : cualquier error que fuerce el cierre del 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 y situaciones más atroces en los que se garantiza que hubo corrupción o pérdida de datos.

¿Le gustaría que el mensaje para sacar a un administrador del sistema de la cama en el 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.

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

Error : Definitivamente es un problema que debe ser investigado. SysAdmin debe ser notificado automáticamente, pero no necesita ser arrastrado fuera de la cama. Al filtrar un registro para ver los errores y los anteriores, obtiene una descripción general de la frecuencia de errores y puede identificar rápidamente el error de inicio que podría haber provocado una cascada de errores adicionales. El seguimiento de las tasas de error en comparación con el uso de la aplicación puede generar métricas de calidad útiles, como MTBF, que se pueden usar 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 una publicación.

Advertencia : esto podría ser un problema o no. Por ejemplo, las condiciones ambientales transitorias esperadas, como la pérdida breve de la red o la conectividad de 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 de la causa raíz de un error posterior. Las advertencias deben usarse con moderación para que no pierdan 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 simplemente una información en una aplicación de escritorio diseñada para usuarios ocasionalmente desconectados de computadoras portátiles.

Información : esta es información importante que debe registrarse en condiciones normales, como una inicialización exitosa, servicios de inicio y finalización o finalización exitosa de transacciones significativas. La visualización de un registro que muestre Información y más arriba debe proporcionar una visión general rápida de los principales cambios de estado en el proceso, proporcionando un contexto de alto nivel para comprender cualquier advertencia o error que también ocurra. No tienes demasiados mensajes de información. Normalmente tenemos <5% de mensajes de información relativos a Trace.

Rastreo : el rastro es, con mucho, la gravedad más comúnmente utilizada y debe proporcionar un contexto para comprender los pasos que conducen a errores y advertencias. Tener la densidad adecuada de mensajes Trace hace que el software sea mucho más fácil de mantener, pero requiere cierta diligencia porque el valor de las declaraciones individuales de Trace puede cambiar con el tiempo a medida que los progtwigs evolucionan. La mejor forma de lograrlo es haciendo que el equipo de desarrollo tenga el hábito de revisar los registros regularmente como parte estándar de la resolución de problemas informados por los clientes. Aliente al equipo a que elimine los mensajes de rastreo que ya no brindan un contexto útil y agregue mensajes donde sea necesario para comprender el contexto de los mensajes subsiguientes. Por ejemplo, a menudo es útil registrar la entrada del usuario, como el cambio de pantallas o tabs.

Depurar : Consideramos Debug

Si puedes recuperarte del problema, entonces es una advertencia. Si impide la continuación de la ejecución, entonces es un error.

Recomiendo adoptar niveles de severidad Syslog: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY .
Ver http://en.wikipedia.org/wiki/Syslog#Severity_levels

Deben proporcionar suficientes niveles de severidad de grano fino para la mayoría de los casos de uso y son reconocidos por los correctores de log existentes. Si bien, por supuesto, tiene la libertad de implementar solo, por ejemplo DEBUG, ERROR, EMERGENCY función de los requisitos de su aplicación.

Vamos a estandarizar algo que ha existido durante siglos en lugar de crear nuestro propio estándar para cada aplicación diferente que hacemos. Una vez que comienzas a agregar registros y estás tratando de detectar patrones en diferentes campos, realmente ayuda.

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 conducirá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 todavía pueden 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 ser posible [ sic ] conducir a un error.

  4. INFO :

    [ v1.2 : ..] mensajes informativos que destacan 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 detallados que el DEBUG .

    [ v2.0 : ..] mensaje de depuración de grano fino, generalmente capturando el flujo a través de la aplicación.


Apache Httpd (como de costumbre) le gusta ir por la exageración: §

  1. emerg :

    Emergencias: el sistema no se puede usar.

  2. alerta :

    La acción debe tomarse inmediatamente [pero el sistema aún es utilizable].

  3. crit :

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

    • socket: Error al obtener un socket, saliendo del hijo
  4. error :

    Condiciones de error [pero no críticas].

    • Final prematuro de encabezados de scripts
  5. advertir

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

  6. aviso :

    Condición [ notable ] normal pero significativa.

    • httpd: atrapó a SIGBUS , intentando volcar núcleo en …
  7. información :

    Informativo [y no apta].

    • [“El servidor se ha estado ejecutando durante x horas “].
  8. depuración :

    Mensajes de nivel de depuración [, es decir, mensajes registrados por el deseo de eliminar errores ]].

    • Abrir el archivo de configuración …
  9. trace1trace6 :

    Mensajes de rastreo [, es decir, mensajes registrados por el bien de rastreo ].

    • proxy: FTP: conexión de control completa
    • proxy: CONNECT: enviando la solicitud CONNECT al proxy remoto
    • openssl: Handshake: start
    • leer desde la brigada SSL protegida, modo 0, 17 bytes
    • “la búsqueda del map=rewritemap : map=rewritemap key=keyname
    • “la búsqueda de caché FALLÓ, lo que obligó a buscar un nuevo mapa
  10. trace7trace8 :

    Rastrea mensajes, volcando 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 :

    Graves errores que causan la 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, uso deficiente de API, errores “casi”, 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. información :

    Interesantes eventos en tiempo de ejecución (inicio / apagado). Espere que estos sean visibles inmediatamente en una consola, así que sea conservador y manténgase al mínimo.

  5. depuración :

    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 de recursos comunes de Apache para el uso empresarial hacen una distinción entre la depuración y la 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 bienes comunes para obtener más información sobre esto).

Advertencias de las que puedes recuperarte 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 la u ). Su código / base de datos puede ser solo en inglés (aunque probablemente no debería serlo en este momento) y, por lo tanto, podría advertir que todos los caracteres “inusuales” se habían convertido a caracteres regulares en inglés.

Compare esto con tratar de escribir esa información en la base de datos y obtener un mensaje de red inactivo 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 desarrollo, frecuentemente uso advertencias donde podría poner el equivalente de una falla de aserción pero la aplicación puede seguir funcionando; esto me permite saber si ese caso realmente sucede, o si es mi imaginación.

Pero sí, se trata de aspectos de recuperación y actualidad. Si puedes recuperarte, es probable que sea una advertencia; si causa que algo realmente falle, es un error.

Creo que los niveles de SYSLOG AVISO y ALERTA / EMERGENCIA son en gran medida superfluos para el registro de nivel de aplicación, mientras que CRITICO / ALERTA / EMERGENCIA pueden ser niveles de alerta útiles para un operador que pueden desencadenar diferentes acciones y notificaciones, para un administrador de aplicaciones es igual que FATAL. Y simplemente no puedo distinguir suficientemente entre recibir un aviso o alguna información. Si la información no es digna de mención, en realidad no es información 🙂

Me gusta mejor la interpretación de Jay Cincotta: rastrear la ejecución de su código es algo muy útil en soporte técnico, y debe alentarse la creación de declaraciones de traza en el código, especialmente en combinación con un mecanismo de filtrado dynamic para registrar los mensajes de seguimiento de componentes específicos de la aplicación. Sin embargo, el nivel de DEPURACIÓN para mí indica que todavía estamos en el proceso de averiguar qué está sucediendo: veo la salida de nivel de DEPURACIÓN como una opción de solo desarrollo, no como algo que siempre 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 llevo 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 usa cuando, por ejemplo, se dispara una tarea independiente, algo que es una verdadera invocación desde la aplicación más extensa de larga ejecució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 puedes desactivarlo 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 de los registros de correo no deseado con mensajes operativos menores sin valor histórico alguno.

Según el caso lo requiera, esta información se puede dirigir a un registro de invocación separado, o se puede obtener filtrándola de un registro grande que registra más información. Pero siempre es necesario, como información histórica, saber qué se estaba haciendo, sin descender al nivel de AUDIT, otro nivel de registro totalmente independiente que no tiene nada que ver con mal funcionamiento o funcionamiento del sistema, realmente no se ajusta a 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.

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

Una advertencia es un signo de un patrón que podría estar equivocado, pero que también podría no serlo.

Habiendo dicho eso, no puedo encontrar un buen ejemplo de advertencia que tampoco sea un error. Lo que quiero decir con eso es que si se toma la molestia de registrar una advertencia, también podría solucionar el problema subyacente.

Sin embargo, cosas como “la ejecución de sql lleva demasiado tiempo” podría ser una advertencia, mientras que “deadlocks de ejecución de sql” es un error, por lo que quizás haya algunos casos después de todo.

Siempre he considerado advertir sobre el primer nivel de registro que seguramente significa que hay un problema (por ejemplo, quizás 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 objective principal del software ahora es imposible y vamos a tratar de cerrarlo limpiamente.

De Ietf – Página 10

 Each message Priority also has a decimal Severity level indicator. 

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 

Gday,

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 para iniciar sesión en un mensaje.

HTH

Creé sistemas antes de eso y uso lo siguiente:

  1. ERROR: significa que algo está muy mal y que un hilo / proceso / secuencia en particular no puede continuar. Se requiere alguna intervención de 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 rest puede procesarse)

En los sistemas que he creado, los administradores tenían instrucciones de reactjsr ante los ERROR. Por otro lado, deberíamos estar atentos a las ADVERTENCIAS y determinar, para cada caso, si algún sistema cambia, se requieren reconfiguraciones, etc.

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

¿Qué pasaría si estuvieras capturando en el nivel de advertencia y deseas información de depuración relacionada con la advertencia, pero no pudiste volver a crear la advertencia?

¡Captura todo y filtra 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 puede rediseñar su rastreo para hacerlo más eficiente, o el seguimiento está interfiriendo con el tiempo ( puede considerar la eliminación de errores en un procesador más potente, pero que abre una lata entera 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 rastro de depuración (dibujo diagtwigs de secuencias de mensajes del mío e histogtwigs de uso de memoria. También te da una base para comparar si algo sale mal en futuro (conserve todos los registros, ya sea aprobado o no, y asegúrese de incluir el número de comstackción en el archivo de registro)).

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. Si tiene dudas, trátelo como un rompecabezas. Para su proyecto particular, piense en todo lo que desee registrar.

Ahora, ¿puedes descubrir qué podría ser fatal? Ya sabes lo que significa fatale, ¿verdad? 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ás seguro de si es información o advertencia? Entonces hazlo una advertencia.

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

Aquí hay unos ejemplos:

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

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

Advertencia : la asignación de recursos llega al X% (digamos 80%), es una señal de que es posible que desee volver a dimensionar su.

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

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

Intereting Posts