logging - tipos - Cuándo utilizar los diferentes niveles de registro.
registros linguisticos planificados (16)
Hay diferentes maneras de registrar mensajes, en orden de fatalidad:
FATALERRORWARNINFODEBUGTRACE
¿Cómo decido cuándo usar cuál?
¿Qué es una buena heurística para usar?
¿Desearía que el mensaje sacara a un administrador del sistema de la cama en medio de la noche?
- si -> error
- no -> advertir
Advertencias de las que puedes recuperar. Errores que no puedes. Esa es mi heurística, otros pueden tener otras ideas.
Por ejemplo, digamos que ingresa / importa el nombre "Angela Müller" en su aplicación (note la diéresis sobre la u ). Su código / base de datos puede ser 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 normales en inglés.
Compare esto con intentar escribir esa información en la base de datos y recuperar un mensaje de inactividad de la red durante 60 segundos seguidos. Eso es más un error que una advertencia.
Aquí hay una lista de lo que tienen "los madereros".
FATAL:[ v1.2 : ..] eventos de error muy severos que probablemente llevarán a la aplicación a abortar.
[ v2.0 : ..] error grave que evitará que la aplicación continúe.
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.
WARN:[ v1.2 : ..] situaciones potencialmente dañinas.
[ v2.0 : ..] evento que podría [ sic ] llevar a un error.
INFO:[ v1.2 : ..] mensajes informativos que resaltan el progreso de la aplicación a nivel general.
[ v2.0 : ..] evento con fines informativos.
DEBUG:[ v1.2 : ..] eventos informativos detallados que son más útiles para depurar una aplicación.
[ v2.0 : ..] evento de depuración general.
TRACE:[ v1.2 : ..] eventos informativos más detallados que
DEBUG.[ v2.0 : ..] mensaje de depuración de grano fino, que normalmente captura el flujo a través de la aplicación.
A Apache Httpd (como de costumbre) le gusta ir por el exceso: §
emerg :
Emergencias - El sistema es inutilizable.
alerta :
Se debe tomar acción inmediatamente [pero el sistema aún es utilizable].
crit :
Condiciones críticas [pero no es necesario tomar medidas inmediatamente].
- " socket: no se pudo obtener un socket, salir del hijo "
error :
Condiciones de error [pero no críticas].
- " Fin prematuro de los encabezados de script "
advertir
Condiciones de advertencia. [cerca de error, pero no error]
aviso :
Condición normal pero significativa [ notable ].
- " httpd: atrapó
SIGBUS, intentando volcar el núcleo en ... "
- " httpd: atrapó
info :
Informativo [e imperceptible].
- ["El servidor ha estado funcionando durante x horas ".
depurar
Mensajes de nivel de depuración [, es decir, mensajes registrados en aras de la eliminación de errores )].
- " Abriendo el archivo de configuración ... "
trace1 → trace6 :
Rastrear mensajes [, es decir, mensajes registrados por el bien del rastreo ].
- " proxy: FTP: control de conexión completa "
- " proxy: CONECTAR: enviando la solicitud CONECTAR al proxy remoto "
- " openssl: Handshake: start "
- " leer de brigada SSL con búfer, modo 0, 17 bytes "
- " búsqueda de
map=rewritemap:map=rewritemapkey=keyname" - " Falló la búsqueda de caché, lo que obligó a una nueva búsqueda en el mapa "
trace7 → trace8 :
Rastreo de 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: §
fatal
Errores graves que causan la terminación prematura. Espere que estos sean visibles inmediatamente en una consola de estado.
error :
Otros errores de ejecución o condiciones inesperadas. Espere que estos sean visibles inmediatamente en una consola de estado.
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 inmediatamente en una consola de estado.
info :
Eventos de tiempo de ejecución interesantes (inicio / apagado). Espere que estos sean visibles inmediatamente en una consola, así que sea conservador y mantenga al mínimo.
depurar
Información detallada sobre el flujo a través del sistema. Espere que estos se escriban solo en los registros.
traza
Información más detallada. Espere que estos se escriban solo en los registros.
Las "mejores prácticas" de apache commons logging para uso empresarial hacen una distinción entre depuración e información en función de qué tipo de límites se cruzan.
Los límites incluyen:
Límites externos - Excepciones esperadas.
Límites externos - Excepciones inesperadas.
Límites internos.
Límites internos significativos.
(Para obtener más información sobre esto, consulte la guía de registro de los bienes comunes ).
Como han dicho otros, los errores son problemas; Las advertencias son problemas potenciales.
En desarrollo, con frecuencia utilizo advertencias en las que podría poner el equivalente a un error de aserción pero la aplicación puede continuar funcionando; esto me permite saber si ese caso alguna vez sucedió realmente, o si es mi imaginación.
Pero sí, se reduce a los aspectos de recuperabilidad y actualidad. Si puedes recuperarte, probablemente sea una advertencia; Si hace que algo falle realmente, es un error.
Creo que los niveles de AVISO y ALERTA / EMERGENCIA de SYSLOG son en gran medida superfluos para el registro a nivel de la 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 la aplicación es lo mismo que FATAL. Y simplemente no puedo distinguir lo suficiente entre recibir un aviso o alguna información. Si la información no es digna de mención, 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 debe alentarse generosamente las declaraciones de rastreo, especialmente en combinación con un mecanismo de filtrado dinámico para registrar los mensajes de rastreo de componentes específicos de la aplicación. Sin embargo, el nivel de DEBUG para mí indica que todavía estamos en el proceso de averiguar qué está pasando. Veo el nivel de DEBUG como una opción 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 del sistema tanto como el del soporte técnico, o incluso el desarrollador: OPER, para los mensajes OPERATIVOS. Esto lo uso para registrar una marca de tiempo, el tipo de operación invocada, los argumentos proporcionados, posiblemente un identificador de tarea (único) y la finalización de la tarea. Se usa cuando, por ejemplo, se ejecuta una tarea independiente, algo que es una verdadera invocación desde la aplicación más grande de larga duración. Es el tipo de cosa que siempre quiero registrar, no importa si algo sale mal o no, por lo 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 de INFO: un nivel de registro a menudo abusado para los registros de spam con mensajes operativos menores sin ningún valor histórico.
Según lo exija el caso, esta información puede dirigirse a un registro de invocación por separado, o puede obtenerse al filtrarla 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 AUDITORÍA, otro nivel de registro totalmente independiente que no tiene nada que ver con el funcionamiento incorrecto del sistema, 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 independiente.
Desde 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
Dia de dia
Como corolario a 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.
Proporcionar ejemplos, si es posible, de los diferentes niveles de registro. Y ser coherente en la información a 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, tratarlo como un rompecabezas. Para su proyecto en particular, piense en todo lo que quiera registrar.
Ahora, ¿puedes averiguar qué podría ser fatal? Sabes lo que significa fatale, ¿verdad? Entonces, qué elementos en tu lista son fatales.
Ok, eso es fatal, ahora veamos los errores ... enjuague y repita.
Debajo de Fatal, o tal vez de Error, sugeriría que más información es siempre mejor que menos, por lo que errar "hacia arriba". ¿No está seguro si es información o advertencia? Entonces haz una advertencia.
Creo que Fatal y el error deben ser claros para todos nosotros. Los otros pueden ser más difusos, pero es posiblemente menos vital para 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% (es decir, el 80%), es una señal de que es posible que desee redimensionar su.
Información : el usuario inició sesión / se desconectó, nueva transacción, archivo crated, nuevo campo d / b o campo eliminado.
Depuración : volcado de la estructura de datos interna, nivel de seguimiento de cualquier cosa con nombre de archivo y número de línea.
Rastreo: la acción se realizó correctamente / falló, se actualizó d / b.
Generalmente me suscribo a la siguiente convención:
- Rastreo : solo cuando esté "rastreando" el código y tratando de encontrar una parte de una función específicamente.
- Depuración : información que es útil para los diagnósticos, más que solo desarrolladores (TI, administradores de sistemas, etc.).
- Información - Información generalmente útil para registrar (inicio / parada 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 de fábrica.
- Advertir : cualquier cosa que pueda causar rarezas en la aplicación, pero para la cual 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). Estos suelen ser reservados (en mis aplicaciones) para cadenas de conexión incorrectas, servicios faltantes, etc.
- Fatal : cualquier error que esté forzando el cierre del servicio o la aplicación para evitar la pérdida de datos (o una pérdida de datos adicional). Los reservo solo para los errores y situaciones más atroces en los que se garantiza que se han producido daños o pérdidas de datos.
He construido sistemas antes de que utilicen lo siguiente:
- 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
- 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 se puede procesar)
En los sistemas que he construido, los administradores estaban bajo instrucciones de reaccionar a los ERRORES. Por otro lado, estaremos atentos a las ADVERTENCIAS y determinaremos para cada caso si se requirieron cambios en el sistema, reconfiguraciones, etc.
Me parece más útil pensar en las severidades desde la perspectiva de ver el archivo de registro.
Fatal / crítico : Fallo general de la aplicación o del sistema que debe investigarse de inmediato. Sí, despierta el SysAdmin. Ya que preferimos nuestra alerta de administrador del sistema y descansamos bien, esta severidad debe usarse con poca frecuencia. Si está sucediendo a diario y eso no es un BFD, se pierde su significado. Normalmente, un error grave solo se produce 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 del registro.
Error : Definitivamente un problema que debe ser investigado. SysAdmin debe ser notificado automáticamente, pero no es necesario que lo saquen 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 de inicio 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 producir 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 un lanzamiento.
Advertencia : Esto podría ser un problema, o podría no serlo. Por ejemplo, las condiciones ambientales transitorias esperadas, como la pérdida corta 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 las sugerencias tempranas 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 solo una información en una aplicación de escritorio diseñada para usuarios de computadoras portátiles desconectados ocasionalmente.
Información : Esta es información importante que se debe registrar en condiciones normales, como la inicialización exitosa, el inicio y finalización de los servicios o la finalización exitosa de transacciones significativas. Ver un registro que muestre Información y más debe ofrecer una visión general rápida de los cambios de estado más importantes 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 relativos al seguimiento.
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 correcta 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 lograr que el equipo de desarrollo tenga la costumbre de revisar los registros regularmente como parte estándar de la solución de problemas informados por los clientes. Aliente al equipo a eliminar los mensajes de seguimiento que ya no proporcionan un contexto útil y a agregar mensajes cuando sea necesario para comprender el contexto de los mensajes subsiguientes. Por ejemplo, a menudo es útil registrar las entradas de los usuarios, 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 las versiones de lanzamiento. Dicho esto, desalentamos el uso de mensajes de depuración. Permitir que los mensajes de depuración tienden a conducir a que se agreguen más y más mensajes de depuración y ninguno se elimine. Con el tiempo, esto hace que los archivos de registro sean casi inútiles porque es muy difícil filtrar la señal del ruido. Eso hace que los desarrolladores no utilicen los registros, lo que continúa la espiral de la muerte. En contraste, los mensajes de seguimiento de la poda constantemente alientan 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 se incluye en la versión de lanzamiento. Sí, ya sé que eso no debería suceder con un buen código, pero es mejor prevenirlo y luego perdonarlo.
Por cierto, soy un gran fanático de capturar todo y filtrar la información más adelante.
¿Qué pasaría si estuviera capturando en el nivel de advertencia y desea alguna información de depuración relacionada con la advertencia, pero no pudo volver a crear la advertencia?
¡Captura todo y filtra luego!
Esto es válido incluso para el software integrado a menos que encuentre que su procesador no puede mantenerse al día, en cuyo caso es posible que desee volver a diseñar su rastreo para que sea más eficiente, o que el rastreo esté interfiriendo con el tiempo ( puede considerar la depuración en un procesador más potente, pero que abre toda una lata de gusanos).
¡Captura todo y filtra más tarde!
(por cierto, capturar todo también es bueno porque le permite desarrollar herramientas para hacer más que solo mostrar el seguimiento de depuración (dibujo los Gráficos de Secuencia de Mensajes de la mía y los histogramas de uso de la memoria. También le proporciona una base para la comparación si algo sale mal en futuro (conserve todos los registros, ya sea que se aprueben o no, y asegúrese de incluir el número de compilación en el archivo de registro)).
Recomiendo adoptar niveles de severidad de Syslog: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY .
Ver http://en.wikipedia.org/wiki/Syslog#Severity_levels
Deben proporcionar suficientes niveles de gravedad específicos 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, EMERGENCY según los requisitos de su aplicación.
Vamos a estandarizar algo que ha existido durante años en lugar de crear nuestro propio estándar para cada aplicación diferente que creamos. Una vez que comienza a agregar registros y está intentando detectar patrones en diferentes, realmente ayuda.
Si puede recuperarse del problema, entonces es una advertencia. Si evita la ejecución continua, es un error.
Siempre he considerado advertir el primer nivel de registro, lo que seguro 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 apagarlo limpiamente.
Un error es algo que está mal, simplemente mal, no hay forma de evitarlo, necesita ser arreglado.
Una advertencia es un signo de un patrón que podría estar equivocado, pero también podría no estarlo.
Dicho esto, no puedo dar un buen ejemplo de una advertencia que no sea también un error. Lo que quiero decir con esto 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 requiere demasiado tiempo" puede ser una advertencia, mientras que "los bloqueos de ejecución de SQL" es un error, por lo que quizás haya algunos casos después de todo.