Logback – Problemas cotidianos

Nos projetos java que trabalho, usamos o logback para os logs das aplicações e, de tempos em tempos, alguém vem falar comigo que a aplicação parou de gerar logs. Diante disso, resolvi reunir aqui as primeiras coisas que eu checo nestas situações:

Problema na geração do binário

Algumas vezes, queremos organizar melhor o código, mudar o nome das pastas para algo que seja mais intuitivo e, sem querer, afetamos a geração do binário de forma que o logback.xml não está sendo levado pelo build para dentro do .war ou .ear.

Então, verifique se a tag resources do seu pom.xml está fazendo o mapeamento correto da pasta que contém o logback.xml.

<resources>
      <resource>
        <directory>src/main/resources</directory>
      </resource>
      ...
    </resources>

Padrão de escrita(pattern) do log no logback.xml

Para facilitar a análise dos logs em ferramentas como o Kibana, Graphana e etc, estabelecemos um padrão para a escrita dos logs para a aplicação.

<encoder>
      <pattern>%d %-5level [%thread] %logger{0}: %msg%n</pattern>
 </encoder>

Se a sua aplicação não está escrevendo os logs no padrão determinado, não gerará saída.

Vários webservices produzindo log no mesmo arquivo

Isso não é recomendado pois, com certeza, você terá problemas com a geração do log. Tivemos um caso que resolvemos escrever os logs de um conjunto de EJBs que realizavam operações distintas sobre um mesmo objeto no mesmo arquivo. Nem preciso falar que foi um caos. Às vezes gerava log, outras não. Tinhamos logs de alguns ejbs e outros não. A solução foi separar os logs, afinal nunca deveríamos ter feito isso.

Antes de continuar, acho que vale a pena falar que os ejbs possuem um logback.xml dentro do binário que carrega configurações de um logback-included.xml que está fora do binário. Isso é fundamental para conseguirmos alterar o nível de log, onde os arquivos são gerados e etc.

Continuando, para que não fosse necessário alterar o logback.xml que estava dentro dos binários para cada um ter a sua própria configuração, seu próprio logback-included.xml, chegamos a conclusão que seria melhor mapear destinos diferentes para os logs de cada EJB porém no mesmo logback-included.xml.

Para separar utilizamos os arquivos de log por pacote, colocamos cada pacote com seu próprio arquivo e nível de log. Por exemplo:

<configuration>

  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <!-- encoders are assigned the type
         ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
    <encoder>
      <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
    </encoder>
  </appender>

  <logger name="chapters.configuration" level="INFO"/>

  <!-- Strictly speaking, the level attribute is not necessary since -->
  <!-- the level of the root level is set to DEBUG by default.       -->
  <root level="DEBUG">          
    <appender-ref ref="STDOUT" />
  </root>  
  
</configuration>

O atributo logger name tem o nome do pacote que se quer logar e o nível do mesmo.

 

Espero que estas dicas sejam uteis e ajudem a resolver o seu problema(pois você deve ter um para ter chegado até aqui 🙂 )