• Articles
• admin

obter visibilidade em seu aplicativo é crucial ao executar seu código em produção. O que queremos dizer com visibilidade? Principalmente coisas como desempenho do aplicativo por meio de métricas, integridade do aplicativo e disponibilidade, seus logs devem ser resolvidos ou rastreados se você precisar descobrir o que o torna lento e como torná-lo mais rápido.

as métricas fornecem informações sobre o desempenho de cada um dos elementos de sua infraestrutura. Os rastreamentos mostrarão uma visão mais ampla da execução e fluxo de código junto com as métricas de execução de código. Finalmente, logs bem elaborados fornecerão uma visão inestimável da execução da lógica de código e do que estava acontecendo em seu código. Cada uma das peças mencionadas é crucial para sua aplicação e, de fato, para a observabilidade geral do sistema. Hoje, vamos nos concentrar apenas em uma única peça-os logs. Para ser mais preciso – em logs de aplicativos Java. Se você estiver interessado em métricas, confira nosso artigo sobre as principais métricas da JVM que você deve monitorar.

no entanto, antes de entrarmos nele, vamos resolver um problema que impactou a comunidade usando essa estrutura. Em 9 de dezembro de 2021, uma vulnerabilidade crítica apelidada de Log4Shell foi relatada. Identificado como CVE-2021-44228, ele permite que um invasor assuma o controle total de uma máquina executando o Apache Log4j 2 versão 2.14.1 ou inferior, permitindo que eles executem código arbitrário no servidor vulnerável. Em nossa recente postagem no blog sobre a vulnerabilidade do Log4jShell, detalhamos como determinar se você foi afetado, como resolver o problema e o que nós, na Sematext, fizemos para proteger nosso sistema e usuários.

Log4j 1.x Fim da vida

lembre-se de que, em 5 de agosto de 2015, o Comitê de gerenciamento de projetos de Serviços de registro anunciou que o Log4j 1.x chegou ao fim da vida. Todos os usuários são aconselhados a migrar para o Log4j 2.X. nesta postagem do blog, ajudaremos você a entender sua configuração atual do Log4j-especificamente, o log4j 2.versão x-e depois disso, vou ajudá-lo a migrar para a versão Log4j mais recente e melhor.

“estou usando Log4j 1.x, O Que devo fazer?”. Não entre em pânico, não há nada de errado com isso. Faça um plano de transição para Log4j 2.X. vou mostrar como continuar lendo :). Sua inscrição agradecerá por isso. Você obterá as correções de segurança, melhorias de desempenho e muito mais recursos após a migração.

“estou iniciando um novo projeto, o que devo fazer?”. Basta usar o Log4j 2.x imediatamente, nem pense em Log4j 1.x. Se você precisar de ajuda com isso, confira este tutorial de registro Java, onde explico tudo o que você precisa.

fazendo login em Java

não há mágica por trás do login em Java. Tudo se resume a usar uma classe Java apropriada e seus métodos para gerar eventos de log. Como discutimos no Guia de registro Java, existem várias maneiras de começar

claro, o mais ingênuo e não o melhor caminho a seguir é apenas usar o sistema.fora e sistema.err classes. Sim, você pode fazer isso e suas mensagens irão apenas para a saída padrão e erro padrão. Normalmente, isso significa que ele será impresso no console ou gravado em um arquivo de algum tipo ou até mesmo enviado para /dev/null e para sempre ser esquecido. Um exemplo desse código pode ser assim:

public class SystemExample { public static void main(String args) { System.out.println("Starting my awesome application"); // some work to be done System.out.println( String.format("My application %s started successfully", SystemExample.class) ); }}

a saída da execução do código acima seria a seguinte:

Starting my awesome applicationMy application class com.sematext.logging.log4jsystem.SystemExample started successfully

isso não é perfeito, certo? Não tenho nenhuma informação sobre qual classe gerou a mensagem e muitas, muitas outras coisas “pequenas” que são cruciais e importantes durante a depuração.

há outras coisas que estão faltando que não estão realmente conectadas à depuração. Pense no ambiente de execução, em vários aplicativos ou microsserviços e na necessidade de unificar o registro para simplificar a configuração do pipeline de centralização de log. Usando o sistema.fora, ou / e sistema.errar em nosso código para fins de registro nos forçaria a refazer todos os locais onde o usamos sempre que precisarmos ajustar o formato de registro. Eu sei que é extremo, mas acredite em mim, vimos o uso do sistema.em código de produção em modelos de implantação de aplicativos “tradicionais”! Claro, fazendo logon no sistema.out é uma solução adequada para aplicativos em contêiner e você deve usar a saída que se adapta ao seu ambiente. Lembra-te disso!

por causa de todos os motivos mencionados e muitos mais que nem sequer pensamos, você deve olhar para uma das possíveis bibliotecas de log, como Log4 j, Log4j 2, Logback ou mesmo o java.util.logging que faz parte do Java Development Kit. Para esta postagem do blog, usaremos Log4j.

a camada de abstração-SLF4J

o tópico de escolher a solução de registro certa para seu aplicativo Java é algo que já discutimos em nosso tutorial sobre como fazer login em Java. É altamente recomendável ler pelo menos a seção mencionada.

usaremos SLF4J, uma camada de abstração entre nosso código Java e Log4j – a biblioteca de log de nossa escolha. A fachada de registro simples fornece ligações para estruturas de registro comuns, como Log4j, Logback e java.util.log. Imagine o processo de escrever uma mensagem de log da seguinte maneira simplificada:

você pode perguntar Por que usar uma camada de abstração? Bem, a resposta é bastante simples – eventualmente, você pode querer alterar a estrutura de registro, atualizá-la, unificá-la com o resto da sua pilha de tecnologia. Ao usar uma camada de abstração, essa operação é bastante simples-você apenas troca as dependências da estrutura de registro e fornece um novo pacote. Se não usássemos uma camada de abstração-teríamos que alterar o código, potencialmente muito código. Cada classe que registra algo. Não é uma experiência de desenvolvimento muito agradável.

O Logger

o código do seu aplicativo Java estará interagindo com um conjunto padrão de elementos-chave que permitem a criação e manipulação de eventos de log. Cobrimos os cruciais em nosso tutorial de log Java, mas deixe – me lembrá-lo sobre uma das classes que usaremos constantemente-o Logger.

O Logger é a principal entidade que um aplicativo usa para fazer chamadas de log – criar eventos de log. O objeto Logger é geralmente usado para uma única classe ou um único componente para fornecer contexto vinculado a um caso de uso específico. Ele fornece métodos para criar eventos de log com um nível de log apropriado e passá-lo para processamento posterior. Você geralmente criará um objeto estático com o qual interagirá, por exemplo, assim:

... Logger LOGGER = LoggerFactory.getLogger(MyAwesomeClass.class);

e isso é tudo. Agora que sabemos o que podemos esperar, vejamos a biblioteca Log4j.

Log4j

a maneira mais simples de começar com Log4j é incluir a biblioteca no caminho de classe do seu aplicativo Java. Para fazer isso, incluímos a mais nova biblioteca log4j disponível, o que significa a versão 1.2.17 em nosso arquivo de compilação.

usamos Gradle e em nosso aplicativo simples e secção de dependências para o Gradle arquivo de compilação de procura da seguinte forma:

dependencies { implementation 'log4j:log4j:1.2.17'}

podemos começar a desenvolver o código e incluir o registo utilizando o Log4j:

package com.sematext.blog;import org.apache.log4j.Logger;public class ExampleLog4j { private static final Logger LOGGER = Logger.getLogger(ExampleLog4j.class); public static void main(String args) { LOGGER.info("Initializing ExampleLog4j application"); }}

Como você pode ver no código acima estamos inicializado o objeto Logger utilizando o estático método getLogger e nós fornecemos o nome da classe. Depois de fazer isso, podemos acessar facilmente o objeto Logger estático e usá-lo para produzir eventos de log. Podemos fazer isso no método principal.

de Um lado nota – o método getLogger também pode ser chamado com uma String como argumento, por exemplo:

private static final Logger LOGGER = Logger.getLogger("com.sematext.blog");

Isso significaria que nós queremos criar um logger e associar o nome de com.sematexto.blog com ele. Se usarmos o mesmo nome em qualquer outro lugar no código Log4j retornará a mesma instância do Logger. Isso é útil se quisermos combinar o registro de várias classes diferentes em um único local. Por exemplo, logs relacionados ao pagamento em um único arquivo de log dedicado.

Log4j fornece uma lista de métodos que permitem a criação de novos eventos de log usando um nível de log apropriado. Esses são:

• public void trace(Objeto de mensagem)
• public void depuração(Objeto de mensagem)
• public void informações(Objeto de mensagem)
• public void avisar(Objeto de mensagem)
• public void erro(Objeto de mensagem)
• public void fatal(Objecto mensagem)

E um método genérico:

• log de vazio público(nível de nível, mensagem de objeto)

falamos sobre os níveis de registro Java em nossa postagem no Blog do tutorial de registro Java. Se você não está ciente deles, por favor, tome alguns minutos para se acostumar com eles como os níveis de log são cruciais para o registro. Se você está apenas começando com os níveis de registro, no entanto, recomendamos que você consulte nosso guia de níveis de registro também. Explicamos tudo, desde o que são até como escolher o caminho certo e como usá-los para obter insights significativos.

se executássemos o código acima, a saída que obteríamos no console padrão seria a seguinte:

log4j:WARN No appenders could be found for logger (com.sematext.blog.ExampleLog4j).log4j:WARN Please initialize the log4j system properly.log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.

não vimos a mensagem de log que esperávamos. Log4j nos informou que não há configuração presente. Oooops, vamos falar sobre como configurar Log4j …

configuração Log4j

existem várias maneiras de configurar nosso log log4j. Podemos fazer isso programaticamente-por exemplo, incluindo um bloco de inicialização estática:

static { BasicConfigurator.configure();}

o código acima configura Log4j para gerar os logs para o console no formato padrão. A saída de executar nosso aplicativo de exemplo seria a seguinte:

0 INFO com.sematext.blog.ExampleLog4jProgrammaticConfig - Initializing ExampleLog4j application

no entanto, configurar Log4j programaticamente não é muito comum. A maneira mais comum seria usar um arquivo de Propriedades ou um arquivo XML. Podemos alterar nosso código e incluir o arquivo log4j. properties com o seguinte conteúdo:

log4j.rootLogger=DEBUG, MAINlog4j.appender.MAIN=org.apache.log4j.ConsoleAppenderlog4j.appender.MAIN.layout=org.apache.log4j.PatternLayoutlog4j.appender.MAIN.layout.ConversionPattern=%r %-5p %c %x - %m%n

dessa forma, dissemos ao Log4j que criamos o logger raiz, que será usado por padrão. Seu nível de registro padrão é definido como DEBUG, o que significa que eventos de log com Debug de gravidade ou superior serão incluídos. Portanto, depure, INFO, WARN, ERROR e FATAL. Também demos ao nosso registrador um nome-principal. Em seguida, configuramos o logger, definindo sua saída para console e usando o layout do padrão. Falaremos sobre isso mais adiante no post do blog. A saída de executar o código acima seria a seguinte:

0 INFO com.sematext.blog.ExampleLog4jProperties - Initializing ExampleLog4j application

se desejar, também podemos alterar o arquivo log4j. properties e usar um chamado log4j.xml. A mesma configuração usando o formato XML ficaria da seguinte maneira:

<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"><log4j:configuration> <appender name="MAIN" class="org.apache.log4j.ConsoleAppender"> <param name="Target" value="System.out"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%r %-5p %c %x - %m%n" /> </layout> </appender> <root> <priority value ="debug"></priority> <appender-ref ref="MAIN" /> </root></log4j:configuration>

Se nós agora alterar o log4j.propriedades para log4j.xml um e mantê-lo no classpath a execução de nosso aplicativo de exemplo seria o seguinte:

0 INFO com.sematext.blog.ExampleLog4jXML - Initializing ExampleLog4j application

então, como Log4j sabe qual Arquivo usar? Vamos ver isso.

processo de inicialização

é crucial saber que Log4j não faz nenhuma suposição sobre o ambiente em que está sendo executado. Log4j não assume nenhum tipo de destino de eventos de log padrão. Quando ele é iniciado, ele procura a propriedade log4j. configuration e tenta carregar o arquivo especificado como sua configuração. Se o local do arquivo não puder ser convertido em um URL ou se o arquivo não estiver presente, ele tentará carregar o arquivo do classpath.

isso significa que podemos substituir a configuração Log4j do classpath fornecendo o-Dlog4j.configuration durante a inicialização e apontando-o para o local correto. Por exemplo, se incluirmos um arquivo chamado outro.xml com o seguinte conteúdo:

<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"><log4j:configuration> <appender name="MAIN" class="org.apache.log4j.ConsoleAppender"> <param name="Target" value="System.out"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%r %-5p %c %x - %m%n" /> </layout> </appender> <root> <priority value ="debug"></priority> <appender-ref ref="MAIN" /> </root></log4j:configuration>

e então execute o código com-Dlog4j. configuration= / opt/sematext / other.xml a saída do nosso código será a seguinte:

0 INFO com.sematext.blog.ExampleLog4jXML - Initializing ExampleLog4j application

log4j Appenders

já usamos appenders em nossos exemplos … bem, realmente apenas um-o ConsoleAppender. Seu único objetivo é escrever os eventos de log no console. É claro que, com um grande número de eventos de log e sistemas em execução em diferentes ambientes, escrever dados de texto puro para a saída padrão pode não ser a melhor ideia, a menos que você esteja executando em contêineres. É por isso que o Log4j suporta vários tipos de remetentes. Aqui estão alguns exemplos comuns de appenders Log4j:

• ConsoleAppender – o appender que anexa os eventos de log ao sistema.fora ou sistema.errar com o padrão sendo o sistema.as. Ao usar este appender, você verá seus logs no console do seu aplicativo.
• FileAppender – o appender que anexa os eventos de log a um arquivo definido armazenando-os no sistema de arquivos.
• RollingFileAppender – o appender que estende o FileAppender e gira o arquivo quando atinge um tamanho definido. O uso de RollingFileAppender impede que os arquivos de log se tornem muito grandes e difíceis de manter.
• SyslogAppender-o appender enviando os eventos de log para um daemon Syslog remoto.
• JDBCAppender – o appender que armazena os eventos de log no banco de dados. Lembre-se de que este appender não armazenará erros e geralmente não é a melhor ideia armazenar os eventos de log em um banco de dados.
• SocketAppender-o appender que envia os eventos de log serializados para um soquete remoto. Tenha em mente que este appender não usa layouts porque envia os eventos de log raw serializados.
• NullAppender – o appender que apenas descarta os eventos de log.

além do mais, você pode ter vários Appenders configurados para um único aplicativo. Por exemplo, você pode enviar logs para o console e para um arquivo. O seguinte log4j.propriedades conteúdo do arquivo faria exatamente isso:

log4j.rootLogger=DEBUG, MAIN, ROLLINGlog4j.appender.MAIN=org.apache.log4j.ConsoleAppenderlog4j.appender.MAIN.layout=org.apache.log4j.PatternLayoutlog4j.appender.MAIN.layout.ConversionPattern=%r %-5p %c %x - %m%nlog4j.appender.ROLLING=org.apache.log4j.RollingFileAppenderlog4j.appender.ROLLING.File=/var/log/sematext/awesome.loglog4j.appender.ROLLING.MaxFileSize=1024KBlog4j.appender.ROLLING.MaxBackupIndex=10log4j.appender.ROLLING.layout=org.apache.log4j.PatternLayoutlog4j.appender.ROLLING.layout.ConversionPattern=%r %-5p %c %x - %m%n

nosso Logger raiz está configurado para registrar tudo a partir da gravidade de depuração e enviar os logs para dois remetentes – o principal e o rolamento. O registrador principal é aquele que já vimos – aquele que envia os dados para o console.

o segundo registrador, aquele chamado rolamento é o mais interessante neste exemplo. Ele usa o RollingFileAppender que grava os dados no arquivo e vamos definir o tamanho do arquivo e quantos arquivos manter. No nosso caso, os arquivos de log devem ser chamados de incríveis.registre e escreva os dados no diretório /var/log/sematext/. Cada arquivo deve ter no máximo 1024KB e não deve haver mais de 10 arquivos armazenados. Se houver mais arquivos, eles serão removidos do sistema de arquivos assim que o log4j os vir.

Depois de executar o código com a configuração acima, o console deve imprimir o seguinte conteúdo:

0 INFO com.sematext.blog.ExampleAppenders - Starting ExampleAppenders application1 WARN com.sematext.blog.ExampleAppenders - Ending ExampleAppenders application

No /var/log/sematext/incrível.arquivo de log que veríamos:

0 INFO com.sematext.blog.ExampleAppenders - Starting ExampleAppenders application1 WARN com.sematext.blog.ExampleAppenders - Ending ExampleAppenders application

nível de Log do Appender

a coisa boa sobre os Appenders é que eles podem ter seu nível que deve ser levado em consideração ao registrar. Todos os exemplos que vimos até agora registraram todas as mensagens que tinham a gravidade da depuração ou superior. E se quiséssemos mudar isso para todas as classes no com.sematexto.pacote de blog? Só teríamos que modificar nosso arquivo log4j. properties:

log4j.rootLogger=DEBUG, MAINlog4j.appender.MAIN=org.apache.log4j.ConsoleAppenderlog4j.appender.MAIN.layout=org.apache.log4j.PatternLayoutlog4j.appender.MAIN.layout.ConversionPattern=%r %-5p %c %x - %m%nlog4j.logger.com.sematext.blog=WARN

Olhe para a última linha no arquivo de configuração acima. Usamos o prefixo log4j.logger e dissemos que o logger chamava com.sematexto.blog só deve ser usado para níveis de gravidade avisar e acima, então erro e FATAL.

nosso exemplo de código de aplicativo se parece com isso:

public static void main(String args) { LOGGER.info("Starting ExampleAppenderLevel application"); LOGGER.warn("Ending ExampleAppenderLevel application");}

com a configuração Log4j acima, a saída do registro é a seguinte:

0 WARN com.sematext.blog.ExampleAppenderLevel - Ending ExampleAppenderLevel application

como você pode ver, apenas o registro de nível de aviso foi incluído. Isso é exatamente o que queríamos.

Log4j Layouts

finalmente, a parte da estrutura de registro Log4j que controla a forma como nossos dados são estruturados em nosso arquivo de log – o layout. O Log4j fornece algumas implementações de padrão como PatternLayout, SimpleLayout, XMLLayout, HTMLLayout, EnchancedPatternLayout, e o DateLayout.

na maioria dos casos, você encontrará o PatternLayout. A ideia por trás desse layout é que você pode fornecer uma variedade de opções de formatação para definir a estrutura dos logs. Alguns dos exemplos são:

• d – data e hora do registo de eventos,
• m – mensagem associada ao evento de log,
• t – nome do thread,
• n – dependente de plataforma separador de linha,
• p – nível de log.

para obter mais informações sobre as opções disponíveis, vá para o Log4j Javadocs oficial para o PatternLayout.

ao usar o PatternLayout, podemos configurar qual opção gostaríamos de usar. Vamos supor que gostaríamos de escrever a data, a gravidade do evento de log, o thread cercado por colchetes e a mensagem do evento de log. Poderíamos usar um padrão como este:

%d %-5p - %m%n

o arquivo log4j.properties completo neste caso pode parecer o seguinte:

log4j.rootLogger=DEBUG, MAINlog4j.appender.MAIN=org.apache.log4j.ConsoleAppenderlog4j.appender.MAIN.layout=org.apache.log4j.PatternLayoutlog4j.appender.MAIN.layout.ConversionPattern=%d %-5p - %m%n

usamos o %d para exibir a data, o %-5p para exibir a gravidade usando 5 caracteres, %t para thread, %m para a mensagem e o %n Para separador de linha. A saída que é gravada no console depois de executar nosso código de exemplo é a seguinte:

2021-02-02 11:49:49,003 INFO - Initializing ExampleLog4jFormatter application

contexto de diagnóstico aninhado

na maioria dos aplicativos do mundo real, o evento de log não existe por conta própria. É cercado por um certo contexto. Para fornecer esse contexto, por thread, o Log4j fornece o chamado contexto de diagnóstico aninhado. Dessa forma, podemos vincular um determinado tópico com informações adicionais, por exemplo, um identificador de sessão, assim como em nosso aplicativo de exemplo:

NDC.push(String.format("Session ID: %s", "1234-5678-1234-0987"));LOGGER.info("Initializing ExampleLog4jNDC application");

ao usar um padrão que inclui x variável, informações adicionais serão incluídas em cada linha de log para o thread fornecido. No nosso caso, a saída será assim:

0 INFO com.sematext.blog.ExampleLog4jNDC Session ID: 1234-5678-1234-0987 - Initializing ExampleLog4jNDC application

você pode ver que as informações sobre o identificador de sessão estão na linha de log. Apenas para referência, O arquivo log4j. properties que usamos neste exemplo é o seguinte:

log4j.rootLogger=DEBUG, MAINlog4j.appender.MAIN=org.apache.log4j.ConsoleAppenderlog4j.appender.MAIN.layout=org.apache.log4j.PatternLayoutlog4j.appender.MAIN.layout.ConversionPattern=%r %-5p %c %x - %m%n

contexto diagnóstico mapeado

o segundo tipo de informação contextual que podemos incluir em nossos eventos de log é mapeado contexto diagnóstico. Usando a classe MDC, podemos fornecer informações adicionais relacionadas ao valor da chave. Semelhante ao contexto de diagnóstico aninhado, o contexto de diagnóstico mapeado é encadeado.

vejamos nosso exemplo de código de aplicativo:

MDC.put("user", "[email protected]");MDC.put("step", "initial");LOGGER.info("Initializing ExampleLog4jNDC application");MDC.put("step", "launch");LOGGER.info("Starting ExampleLog4jNDC application");

temos dois campos de contexto – o Usuário e a etapa. Para exibir todas as informações de contexto de diagnóstico mapeadas associadas ao evento log, basta usar a variável X em nossa definição de padrão. Por exemplo:

log4j.rootLogger=DEBUG, MAINlog4j.appender.MAIN=org.apache.log4j.ConsoleAppenderlog4j.appender.MAIN.layout=org.apache.log4j.PatternLayoutlog4j.appender.MAIN.layout.ConversionPattern=%r %-5p %c %X - %m%n

lançar o código acima junto com a configuração resultaria na seguinte saída:

0 INFO com.sematext.blog.ExampleLog4jMDC {{step,initial}{user,[email protected]}} - Initializing ExampleLog4jNDC application1 INFO com.sematext.blog.ExampleLog4jMDC {{step,launch}{user,[email protected]}} - Starting ExampleLog4jNDC application

também podemos escolher quais informações usar alterando o padrão. Por exemplo, para incluir o usuário mapeada diagnóstico do contexto poderíamos escrever um padrão como este:

%r %-5p %c %X{user} - %m%n

Neste momento a saída ficaria da seguinte maneira:

0 INFO com.sematext.blog.ExampleLog4jMDC [email protected] - Initializing ExampleLog4jNDC application0 INFO com.sematext.blog.ExampleLog4jMDC [email protected] - Starting ExampleLog4jNDC application

Você pode ver que, em vez de geral %X, usamos o %X % {user}. Isso significa que estamos interessados na variável de usuário do contexto de diagnóstico mapeado associado a um determinado evento de log.

migração para Log4j 2

migração do Log4j 1.X para Log4j 2.x não é difícil e, em alguns casos, pode ser muito fácil. Se você não usou nenhum Log4j interno 1.classes x, você usou arquivos de configuração ao configurar programaticamente os loggers e não usou as classes DOMConfigurator e PropertyConfigurator a migração deve ser tão simples quanto incluir a API log4j-1.2.arquivo jar jar em vez do Log4j 1.arquivos x jar. Isso permitiria Log4j 2.x para trabalhar com seu código. Você precisaria adicionar o Log4j 2.x arquivos jar, ajustar a configuração, e voilà-você está feito.

se você gostaria de saber mais sobre Log4j 2.x confira nosso tutorial de registro Java e seu Log4j 2.x seção dedicada.

no entanto, se você usou log4j interno 1.x classes, o guia oficial de migração sobre como passar do Log4j 1.X para Log4j 2.x será muito útil. Ele discute o código necessário e as alterações de configuração e será inestimável quando em dúvida.

log centralizado com ferramentas de gerenciamento de Log

enviar eventos de log para um console ou arquivo pode ser bom para um único aplicativo, mas lidar com várias instâncias de seu aplicativo e correlacionar os logs de várias fontes não é divertido quando os eventos de log estão em arquivos de texto em máquinas diferentes. Nesses casos, a quantidade de dados rapidamente se torna incontrolável e requer soluções dedicadas – auto-hospedadas ou provenientes de um dos fornecedores. E os contêineres em que você normalmente nem grava logs em arquivos? Como você soluciona problemas e depura um aplicativo cujos logs foram emitidos para a saída padrão ou cujo contêiner foi morto?

é aqui que os Serviços de gerenciamento de log, ferramentas de análise de log e serviços de registro em nuvem entram em jogo. É uma prática recomendada de registro Java não escrita entre os engenheiros para usar essas soluções quando você leva a sério o gerenciamento de seus logs e o aproveitamento máximo deles. Por exemplo, o Sematext Logs, nosso software de monitoramento e gerenciamento de log, resolve todos os problemas mencionados acima e muito mais.

com uma solução totalmente gerenciada como Logs Sematext, você não precisa gerenciar outra parte do ambiente – sua solução de registro DIY, normalmente construída usando partes da pilha elástica. Essas configurações podem começar pequenas e baratas, no entanto, muitas vezes crescem grandes e caras. Não apenas em termos de custos de infraestrutura, mas também de custos de gerenciamento. Você sabe, tempo e folha de pagamento. Explicamos mais sobre as vantagens de usar um serviço gerenciado em nossa postagem no blog sobre as melhores práticas de registro.

Alertas e agregação de log também são cruciais ao lidar com problemas. Eventualmente, para aplicativos Java, você pode querer ter logs de coleta de lixo depois de ativar o registro de coleta de lixo e começar a analisar os logs. Esses logs correlacionados com métricas são uma fonte inestimável de informações para solucionar problemas relacionados à coleta de lixo.

resumo

mesmo que Log4j 1.x chegou ao fim da vida útil há muito tempo ainda está presente em um grande número de aplicativos legados usados em todo o mundo. A migração para sua versão mais jovem é bastante simples, mas pode exigir recursos e tempo substanciais e geralmente não é uma prioridade. Especialmente em grandes empresas onde os procedimentos, requisitos legais ou ambos exigem auditorias seguidas de testes longos e caros antes que qualquer coisa possa ser alterada em um sistema já em execução. Mas para aqueles de nós que estão apenas começando ou pensando em migração – lembre-se, Log4j 2.x está lá, já está maduro, rápido, seguro e muito capaz.

mas independentemente da estrutura que você está usando para registrar seus aplicativos Java, definitivamente recomendamos combinar seus esforços com uma solução de gerenciamento de log totalmente gerenciada, como Logs de Sematexto. Experimente! Há um teste gratuito de 14 dias disponível para você testá-lo.

registo feliz!