2011-07-02 9 views
8

Actualmente estoy desarrollando un servicio web de descanso grande (funcional) y quiero capturar registros realmente buenos, así puedo tener una buena idea de qué está pasando en dónde. Por ahora yo uso log4j para el registro, utilizando esta configuración anexa:La mejor manera de modificar log4j anexado para iniciar sesión

<!-- Appenders --> 
<appender name="console" class="org.apache.log4j.ConsoleAppender"> 
    <param name="Target" value="System.out" /> 
    <layout class="org.apache.log4j.PatternLayout"> 
     <param name="ConversionPattern" value="%-5p: %c - %m%n" /> 
    </layout> 
</appender> 

que produce este tipo de registros:

10:44:55,893 INFO [STDOUT] INFO : my.package.MyClass - I'm class message 
  1. ¿Cómo puedo hacer que este aspecto mensaje como por ejemplo

    10:44:55,893 INFO : my.package.MyClass - I'm class message 
    
  2. ¿Puedo hacer un appender especial o lo que sea, y usarlo en algunas clases, no en todas, es decir, quiero h Ave en algunos de los registros de mi esto:

    • Payload: some request parameters
    • Response: some response that my service returns
    • extra data : some extra data

Sin tener estos INFO [STDOUT] INFO my.package.MyClass in front of it

ACTUALIZACIÓN

Olvidé mencionar en la pregunta que estoy usando Jboss 5. Creo que el jboss podría estar agregando el 10:44:55,893 INFO [STDOUT] a cualquier formato que puse en mi configuración log4j.

BOUNTY ACTUALIZACIÓN

me cambió esto:

<!-- ============================== --> 
    <!-- Append messages to the console --> 
    <!-- ============================== --> 

    <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender"> 
     <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/> 
     <param name="Target" value="System.out"/> 
     <param name="Threshold" value="INFO"/> 

     <layout class="org.apache.log4j.PatternLayout"> 
     <!-- The default pattern: Date Priority [Category] Message\n --> 
     <param name="ConversionPattern" value="%d{ABSOLUTE} %-5p [%c{1}] %m%n"/> 
     </layout> 
    </appender> 

a esto:

<!-- ============================== --> 
    <!-- Append messages to the console --> 
    <!-- ============================== --> 

     <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender"> 
      <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/> 
      <param name="Target" value="System.out"/> 
      <param name="Threshold" value="INFO"/> 

      <layout class="org.apache.log4j.PatternLayout"> 
      <!-- The default pattern: Date Priority [Category] Message\n --> 
      <param name="ConversionPattern" value="%m%n"/> 
      </layout> 
     </appender> 

y funcionó, pero parece un poco feo para hacerlo de esta manera. ¿Hay alguna otra manera? Estoy usando la combinación Spring MVC/JBoss.

ahora estoy consiguiendo buenos mensajes limpias:

10:44:55,893 INFO : my.package.MyClass - I'm class message 

sin molestar

10:44:55,893 INFO [STDOUT] 

prefijo

+0

No JBoss pero% d {ABSOLUTE} le dio 10: 44: 55,893 mensaje – Dima

+0

Podría aclarar: ¿qué hay de malo en establecer un patrón de conversión personalizado? – GargantuChet

Respuesta

7

Pregunta 1:

Usar la siguiente distribución para su patrón appender:

<param name="ConversionPattern" value="%d{ABSOLUTE} %-5p: %c - %m%n" /> 

El patrón de conversión en el archivo de configuración que ha indicado no da como resultado el tipo de registro que ha indicado. Por ejemplo, la fecha/hora no está incluida en su patrón de conversión.


Pregunta 2:

Se puede utilizar un registrador especial que utiliza otra appender que sólo está registrando el mensaje puro.

Su configuración sería por ejemplo el siguiente aspecto:

<?xml version="1.0" encoding="UTF-8" ?> 
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"> 

<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/"> 

    <appender name="consoleAppender" class="org.apache.log4j.ConsoleAppender"> 
     <param name="Target" value="System.out" /> 
     <layout class="org.apache.log4j.PatternLayout"> 
      <param name="ConversionPattern" value="%m%n" /> 
     </layout> 
    </appender> 

    <appender name="consoleAppender2" class="org.apache.log4j.ConsoleAppender"> 
     <param name="Target" value="System.out" /> 
     <layout class="org.apache.log4j.PatternLayout"> 
      <param name="ConversionPattern" value="%d{ABSOLUTE} %-5p: %c - %m%n" /> 
     </layout> 
    </appender> 

    <logger name="specialLogger" additivity="false"> 
     <level value="INFO" /> 
     <appender-ref ref="consoleAppender" /> 
    </logger> 

    <root> 
     <priority value="INFO" /> 
     <appender-ref ref="consoleAppender2" /> 
    </root> 

</log4j:configuration> 

Se utiliza el specialLogger para los mensajes puros sin la información adicional. Se puede usar en múltiples clases.

En la configuración del especialLogger, additivity = "false" es necesario, porque de lo contrario también el appender consoleAppender2 del registrador de raíz registraría el mismo mensaje. (El mensaje se registra dos veces en este caso.)

Su código podría, por ejemplo, el siguiente aspecto:

public class TestClassA 
{ 
    private static Logger specialLogger = Logger.getLogger("specialLogger"); 
    private static Logger logger = Logger.getLogger(TestClassA.class);  

    public TestClassA() { 

    } 

    public void doSomething() { 
     logger.info("Some message from TestClassA"); 
     specialLogger.info("Some message via the specialLogger from TestClassA"); 
    } 
} 

Calling resultados doSomething en:

17:17:18,125 INFO : com.foo.TestClassA - Some message from TestClassA 
Some message via the specialLogger from TestClassA 

En algún lugar de su clase principal necesita configurar log4j como de costumbre, p. ej .:

DOMConfigurator.configureAndWatch("log4j.xml", 60 * 1000); 
+0

incluso cuando uso todo lo que has sugerido, aún no puedo deshacerme de este molesto "13: 13: 43,428 INFO [STDOUT]" delante de cualquier cosa que cambie en mi appender, tu configuración funciona pero solo después de esto parte.. –

1

Intente utilizar este patrón, ya que dará que limpia mensaje:

<param name="ConversionPattern" value="%d{HH:mm:ss.SSS} %-5p %c %X %m/> 

Es una buena idea para añadir algo de valor único a MDC al petición llega, a continuación, añadir% X {} uniqueValueKey a su patrón. Le permitirá rastrear registros para esta solicitud única.

4

El INFO [STDOUT] normalmente viene de log4j para System.out también. Tuvimos un caso similar en el que la aplicación en sí misma tenía su propia configuración de log4j y, por lo tanto, obtuvo su propio apéndice raíz. Esto se registraría en la consola que escucha JBoss log4j. Esto a su vez agrega el INFO [STDOUT] como si estuviera escribiendo directamente al System.out (o ERROR [STDERR] al escribir al System.err).

La solución en nuestro caso fue eliminar la configuración de log4j específica de la aplicación y simplemente usar la que JBoss escribe.

Otra forma podría ser escribir directamente en un archivo de registro específico de la aplicación en lugar de escribir en la consola. En un entorno de servidor, lo más probable es que se refiera a los archivos de registro de todos modos.

En cuanto a la segunda parte, que se extiende es decir automáticamente los registros con la respuesta, solicitar etc. datos:

En un caso, tuvimos una superclase para las semillas de sesión sin estado que proporcionadas capturar la funcionalidad y tenido un registrador (overwritable) por ejemplo. Los métodos base como info llamarían al registrador y agregarían los datos requeridos automáticamente.

Un segundo enfoque podría ser MCD, es decir, usted pone algunos datos (como la solicitud) en el MDC local de la secuencia (básicamente un mapa) y luego los accede en la definición de su patrón.

Por ejemplo, tenemos varias aplicaciones similares, cada una de las cuales tiene algunas clases que los demás también tienen. Así que íbamos a necesitar la aplicación que el mensaje se originó a partir y por lo tanto añade el nombre de la aplicación a la MDC:

En el código:
MDC.put("app.name", "myapplication");

En la configuración de log4j patrón:
<param name="ConversionPattern" value="%d %-5p [%c (%X{app.name})] %m%n"/> (nótese el % X {} app.name)

no he probado si se podría hacer algo como poner la solicitud en el MDC y luego usar: %X{request.getAttribute('xyz')} pero si simplemente se pone el valor en el MDC y llama toString() en él, podrías crear un solicitud de envoltura así:

class RequestLogWrapper { 
    private HttpServletRequest request; //initialize through constructor etc. 

    public String toString() { 
    return request.getAttribute("xyz") + ";" + request.getAttribute("abc") + ... //handle null etc. as well 
    } 
} 

A continuación, llame MDC.put("request", new RequestLogWrapper(request)); y en la configuración utilizar %X{request}.

0

para imprimir solo mensajes, el siguiente patrón de conversión funcionará.

<param name="ConversionPattern" value="%m%n"/> 

Dependiendo de sus necesidades, puede establecer el patrón de conversión a lo que usted quiere

  1. % -5p se refiere al tipo de entrada de registro. Esto aparecería en el archivo de registro como INFO, DEBUG, ERROR, etc. Técnicamente,% p sería suficiente para incluir esta descripción; el -5 está ahí para incluir la palabra en una columna de ancho de 5 caracteres.
  2. % d se refiere a la fecha.
  3. % t al nombre del subproceso que generó esta entrada de registro.
  4. % c enumera la categoría que generó este registro que generalmente es el nombre de clase .
  5. % m muestra el mensaje
  6. % n agrega un retorno de carro.

¿Va a poner toda la información relevante solo en los mensajes? No estoy seguro, pero no es una buena idea.

1

Si no te gusta el archivo de configuración log4j xml, puedes cambiar a un archivo de propiedades. No puede configurar filtros usando el archivo de propiedad simple, pero dado que parece que no los necesita, esto no debería ser un problema.

Dado que eres

... actualmente en desarrollo para luego ser grande (sabia funcional) servicio web reposo y quiero capturar los registros realmente bueno, así que puede tener una buena perspectiva de lo que es yendo donde.

entonces me temo que su resultado deseado no le dará muchos conocimientos en absoluto, no se escalará bien, y le hará perder la cabeza una vez que la aplicación se vuelva tan grande como se esperaba ...

Consulte Log4j Best Practices para una buena referencia del diseño de registros.Por favor, eche un vistazo a ALL sus párrafos incluyendo la consideración cosmética al final. Espero que esto ayude.

Cuestiones relacionadas