¿Cuál es la mejor práctica al usar los niveles de log4j durante la codificación? Me refiero a cuándo usamos el registro de INFO, cuándo usamos el registro de DEPURACIÓN/registro de ERROR, etc.Uso de los niveles de log4J
La mejor manera de aprender es con el ejemplo. Lea la fuente de algunas cosas de código abierto, como, oh, Tomcat o lo que sea que esté en su área de aplicación, y vea lo que ve.
Hibernate es otra buena referencia –
Hibernate en realidad no es una gran referencia para esa IMO, ver por ejemplo el enlace en mi respuesta. Creo que la primavera es un buen ejemplo, así como el cuarzo, el eje2 y proyectos similares – Yoni
ERROR el registro siempre debe estar activado.
INFO + DEBUG debe estar encendido al rastrear problemas/errores.
¿Quiere decir 'usar' como en 'habilitar' o 'usar' como en 'a quién debo llamar cuando'? – bmargulies
hmm, buen punto! –
Gracias por la respuesta. De su respuesta, leí que ERROR es el nivel que se debe usar en Producción e INFO/DEBUG debe establecerse según los requisitos en caso de problemas. Pleae aclara si estoy en lo correcto. –
En general, las siguientes pautas:
log4j también tiene un nivel [FATAL] (https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html#FATAL) y un [TRACE] (https: // logging. apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html#TRACE) nivel. Para log4j2, consulte [esta página] (https://logging.apache.org/log4j/2.0/log4j-api/apidocs/org/apache/logging/log4j/Level.html) –
Mi línea de base es siempre que nivel INFO es equivalente a System.out y ERROR es equivalente a System.err.
DEPURTO - Aquí pone toda su información de rastreo, y específicamente información que no quiere ver cuando su "nivel de comodidad" es system.out.
INFO - utilice este para mensajes generales, mensajes de progreso, para mensajes relacionados con aplicaciones, pero no para rastreo.
WARN - avisa de que algo anda mal, tal vez inesperado, o que se utiliza una solución alternativa, pero la aplicación puede continuar (tiempo de espera/reintentos del socket, entrada de usuario no válida, etc.).
ERROR - alertas sobre problemas que impiden que su aplicación continúe normalmente, p. la base de datos está inactiva, falta la configuración de arranque.
Un error común al escribir bibliotecas es utilizar el nivel de ERROR para indicar problemas con la aplicación de llamada (el código que usa la biblioteca) en lugar de indicar errores reales dentro de la biblioteca. Ver por ejemplo este error de hibernación ->http://opensource.atlassian.com/projects/hibernate/browse/HHH-3731
Esto es realmente molesto porque los mensajes del nivel de ERROR son realmente difíciles de suprimir, por lo tanto, utilícelos solo para indicar problemas con su propio código.
Todo - Realmente no uso este, es prácticamente lo mismo que DEBUG o TRACE.
Además, NHibernate utiliza el nivel INFO para registrar cada La declaración SQL que genera es irritante ya que suelo dejar INFO en forma predeterminada en los sistemas de producción. Esto debería ser DEBUG en mi humilde opinión. – Andy
Estoy de acuerdo con la lista de significados, pero tengo una comprensión muy diferente de System.out/err (que está basado en Unix-shell: out es para "la salida que el usuario esperaba", mientras que err es "cosas que podrían ayuda si la aplicación que está haciendo el registro necesita reparación ". Como tal, * toda * log4j es material de System.err; las aplicaciones de línea de comandos envían sus cosas de System.out a System.out; webapps envían sus cosas de System.out a la web respuesta DTO). Sería mejor simplemente eliminar o ignorar el párrafo "Mi línea base". – jackr
A lo que otros mencionaron, agregaría niveles TRACE y FATAL, el primero es bueno para el registro muy detallado, el último es para indicar el tope total de la demostración. Existen pautas generales sobre cómo usar los niveles, como se menciona en los otros anteriores. Sin embargo, la mayoría de importante es cómo USTED lo usará y cómo lo interpretará su USUARIOS. Necesita niveles para concentrarse en los problemas, así que decida cuál es el problema en su caso. Sus usuarios casi nunca necesitarán rastrear o depurar declaraciones, pero definitivamente querrán identificar problemas y denunciarlos.
A pesar de que esta pregunta es bastante antigua, este es realmente un punto importante que todo desarrollador debe saber, le recomiendo que consulte la página oficial de Apache log4j.
También he encontrado útil y la imagen que describe esto perfectamente, log4jImage tomado de supportweb.cs.bham.ac.uk/documentation/tutorials/docsystem/build/tutorials/log4j/log4j.html
TRACE: El menor nivel de registro. Proporciona el nivel de información más detallado.
DEPURTO: La declaración del registro aquí está destinada a ayudar a los desarrolladores. Estado detallado de su aplicación.
INFO: Información comercial general. Progreso y estado de su aplicación
WARN: Advertencias sobre eventos inesperados. Estos no son lo suficientemente graves como para abortar su aplicación.
ERROR: Problemas graves en su aplicación.
Además, tener el nivel correcto de inicio de sesión activado en diferentes entornos es igualmente crucial.
Aquí hay algunas pautas que utilizo:
DEPURTO: registro dirigido solo a los desarrolladores: contenido de variables, resultados de comparaciones y otros bits de información que ayudan a depurar la lógica empresarial.
INFORMACIÓN: la información de alto nivel, como la tarea X, se ha completado o se ha cumplido alguna regla, y esto es lo que voy a hacer a continuación debido a esa regla.
WARN: puede ser un problema, pero no es lo suficientemente grave como para hacer ningún daño real al flujo de la lógica de negocio. Por ejemplo, tal vez alguna variable sea a veces nula, pero no necesariamente la necesitamos o podemos solucionarla de alguna manera. Al mismo tiempo, aún queremos saberlo por si acaso nos dicen que más adelante tenemos que encontrar ejemplos de ello o investigar más detenidamente por qué sucede.
ERROR: Un problema grave que definitivamente debe investigarse más a fondo, pero no lo suficientemente grave como para detener la aplicación de realizar la tarea en cuestión.
FATAL: Un problema inesperado muy grave que no podemos evitar o recuperar e incluso puede evitar que la aplicación haga algo útil.
muy subjetiva. Quizás Community Wiki sería apropiado? – bmargulies