Consultor Eletrônico



Kbase 43026: Alterando o nível de Log no Jboss
Autor   Gionei Mistura - CAT
Acesso   Público
Publicação   01/09/2010
No Jboss, o logging é controlado por um arquivo central (conf/jboss-log4j.xml). Este arquivo define um conjunto de "appenders", que são basicamente as saídas de log. Por padrão, o Jboss está configurado para saídas para o console e para um arquivo de log.
O nível de log a ser configurado, depende do tipo de informação que se quer obter. O produto Datasul 11 está configurado com o log para "ERROR", o que significa que somente as mensagens de erro serão exibidas no arquivo. Esta é a configuração adequada para um ambiente de produção, para que mensagens inúteis (neste momento) não sejam gravadas em log.
Existem 6 tipos básicos de níveis de log: TRACE, DEBUG, INFO, WARN, ERROR e FATAL. Quando um desses níveis é definido no arquivo, todas as mensagens acima do nível escolhido também serão logadas. Quer dizer, se for escolhido o nível "INFO", todas as mensagens iguais e superiores a este nível serão escritas em log (INFO, WARN, ERROR e FATAL).

O exemplo abaixo, é de um appender com saída para arquivo, configurado para "INFO":

<appender name="FILE" class="org.jboss.logging.appender.DailyRollingFileAppender">
<errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
<param name="File" value="${jboss.server.log.dir}/server.log"/>
<param name="Append" value="false"/>
<param name="Threshold" value="INFO"/>

Para alterar o nível de log, basta alterar este valor de "INFO" para o valor desejado. Após a alteração NÃO é necessário reiniciar a instância. O jboss-log4j.xml é o único arquivo de configuração do Jboss que não exige restart da instância. A alteração entra em vigor no máximo em 60 segundos após salvar o arquivo.

---------------------------------------------------------------

Information about Logging Levels (without translation):

1. FATAL - Use the FATAL level priority for events that indicate a critical service failure. If a service issues a FATAL error it is completely unable to service requests of any kind.

2. ERROR - Use the ERROR level priority for events that indicate a disruption in a request or the ability to service a request. A service should have some capacity to continue to service requests in the presence of ERRORs.

3. WARN - Use the WARN level priority for events that may indicate a non-critical service error. Resumable errors, or minor breaches in request expectations fall into this category. The distinction between WARN and ERROR may be hard to discern and so its up to the developer to judge. The simplest criterion is would this failure result in a user support call. If it would use ERROR. If it would not use WARN.

4. INFO - Use the INFO level priority for service life-cycle events and other crucial related information. Looking at the INFO messages for a given service category should tell you exactly what state the service is in.

5. DEBUG - Use the DEBUG level priority for log messages that convey extra information regarding life-cycle events. Developer or in depth information required for support is the basis for this priority. The important point is that when the DEBUG level priority is enabled, the JBoss server log should not grow proportionally with the number of server requests. Looking at the DEBUG and INFO messages for a given service category should tell you exactly what state the service is in, as well as what server resources it is using: ports, interfaces, log files, etc.

6. TRACE - Use TRACE the level priority for log messages that are directly associated with activity that corresponds requests. Further, such messages should not be submitted to a Logger unless the Logger category priority threshold indicates that the message will be rendered. Use the Logger.isTraceEnabled() method to determine if the category priority threshold is enabled. The point of the TRACE priority is to allow for deep probing of the JBoss server behavior when necessary. When the TRACE level priority is enabled, you can expect the number of messages in the JBoss server log to grow at least a x N, where N is the number of requests received by the server, a some constant. The server log may well grow as power of N depending on the request-handling layer being traced.