Website oficial
https://logback.qos.ch/manual/architecture.html
Construção de logback
A arquitetura básica do Logback é suficientemente genérica para ser aplicada em diferentes circunstâncias. Atualmente, o logback está dividido em três módulos, logback-core, logback-classic e logback-access.
Diz-se aqui que o logback é muito bom e está dividido principalmente em três módulos: acesso clássico básico
O módulo principal estabelece as bases para os outros dois módulos. O módulo clássico estende o núcleo. O módulo clássico corresponde a uma versão significativamente melhorada do log4j. Logback-classic implementa nativamente a API SLF4J para que você possa alternar prontamente entre logback e outros sistemas de log, como log4j ou java.util.logging (JUL) introduzido no JDK 1.4. O terceiro módulo chamado access integra-se com contêineres Servlet para fornecer funcionalidade de log de acesso HTTP. Um documento separado cobre a documentação do módulo de acesso.
O módulo principal é a base dos outros dois.
O Classic herda o núcleo e é uma versão avançada correspondente ao log4j. Ele implementa a API SLF4J e pode alternar facilmente entre o Logback e outros sistemas de registro. O
Access fornece funcionalidade de registro http.
No restante deste documento, escreveremos “logback” para nos referirmos ao módulo logback-classic
Na verdade, a estrutura de log que costumamos chamar de logback refere-se ao clássico.
Logger, Appenders e Layouts
Logback é construído sobre três classes principais: Logger, Appender e Layout. Esses três tipos de componentes trabalham juntos para permitir que os desenvolvedores registrem mensagens de acordo com o tipo e nível da mensagem e controlem em tempo de execução como essas mensagens são formatadas e onde são relatadas.
A classe Logger faz parte do módulo logback-classic. Por outro lado, as interfaces Appender e Layout fazem parte do logback-core. Como um módulo de uso geral, o logback-core não tem noção de loggers.
Logback consiste principalmente em três classes: Logger, Appender e Layout, que são usadas para definir o nível de log, método de saída de log e formato de saída de log.A
classe Logger faz parte do módulo logback-classic.
As interfaces Appender e Layout fazem parte do núcleo logback-core.
Como módulo geral, logback-core não possui o conceito de logger.
Contexto do registrador
A principal vantagem de qualquer API de log em relação ao System.out.println simples reside em sua capacidade de desabilitar certas instruções de log enquanto permite que outras imprimam sem impedimentos. Esse recurso pressupõe que o espaço de criação de log, ou seja, o espaço de todas as instruções de criação de log possíveis, seja categorizado de acordo com alguns critérios escolhidos pelo desenvolvedor. No logback-classic, essa categorização é uma parte inerente dos madeireiros. Cada logger é anexado a um LoggerContext que é responsável por fabricar loggers, bem como organizá-los em uma hierarquia semelhante a uma árvore.
Aqui falamos sobre a diferença entre log e soout. Diz-se que log pode imprimir parte do log e não imprimir parte. Na verdade, é o nível de log, mas log tem uma vantagem sobre sout. Se você olhar para baixo camada de sout, você descobrirá que ela está sincronizada e sout multithread. Ao bloquear, a eficiência é baixa.
Loggers são entidades nomeadas. Seus nomes diferenciam maiúsculas de minúsculas e seguem a regra de nomenclatura hierárquica:
Hierarquia Nomeada
Um registrador é considerado ancestral de outro registrador se seu nome seguido por um ponto for um prefixo do nome do registrador descendente. Diz-se que um criador de logs é pai de um criador de logs filho se não houver ancestrais entre ele e o criador de logs descendente.
Por exemplo, o criador de logs denominado “com.foo” é pai do criador de logs denominado “com.foo.Bar”. Da mesma forma, “java” é pai de “java.util” e ancestral de “java.util.Vector”. Este esquema de nomenclatura deve ser familiar para a maioria dos desenvolvedores.
O criador de logs raiz reside no topo da hierarquia do criador de logs. É excepcional porque faz parte de todas as hierarquias desde o seu início. Como todo criador de logs, ele pode ser recuperado por seu nome, como segue:
O criador de logs raiz reside no topo da hierarquia do criador de logs. É excepcional porque faz parte de todas as hierarquias desde o seu início. Como todo logger, ele pode ser recuperado pelo seu nome, como segue:
Logger rootLogger = LoggerFactory.getLogger(org.slf4j.Logger.ROOT_LOGGER_NAME);
Todos os outros criadores de logs também são recuperados com o método getLogger estático da classe encontrado na classe org.slf4j.LoggerFactory. Este método leva como parâmetro o nome do logger desejado. Alguns dos métodos básicos da interface do Logger estão listados abaixo.
O que foi dito aqui é o relacionamento hierárquico dos níveis de log.
Por exemplo, com.chenchi é o relacionamento pai de com.chenchi.age.
Nível Efetivo, também conhecido como Herança de Nível
Os níveis de log válidos
TRACE, DEBUG, INFO, WARN e ERROR são definidos na classe ch.qos.logback.classic.Level. Essa classe é final e não pode ser herdada, portanto, há apenas alguns níveis de log. O nível de log padrão é o modo de depuração
., o padrão aqui se refere a root=debug
demonstração1
Defina o nível de log do root = depuração. Todos os outros logs não precisam ser definidos, eles são todos de nível de depuração.
demonstração2
Defina root=error, x=info, xy=debug, xyz=warn, e o nível de log final é o nível que eles próprios definiram.
demonstração3
Defina root=error, x=info, xy=NONE, xyz=warn e, finalmente, o nível de log de xy herda x=INFO
demo4
define root=debug, x=info, xy=NONE, xyz=NONE e, finalmente, os níveis de log de xy e xyz herdam x=INFO
Em resumo, é isso.
1. A categoria de log de nível ancestral é definida pela raiz.
2. Se as outras classes ou pacotes não tiverem uma classe pai, o nível de log será a raiz do nível de ancestral.
3. Se o nível de log estiver definido para sua classe atual ou pacote, ele será seu, independentemente da classe pai.
Métodos de impressão e regra básica de seleção
TRACE < DEBUG < INFO < WARN < ERROR
import ch.qos.logback.classic.Level;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
....
// get a logger instance named "com.foo". Let us further assume that the
// logger is of type ch.qos.logback.classic.Logger so that we can
// set its level
ch.qos.logback.classic.Logger logger =
(ch.qos.logback.classic.Logger) LoggerFactory.getLogger("com.foo");
//set its Level to INFO. The setLevel() method requires a logback logger
logger.setLevel(Level. INFO);
Logger barlogger = LoggerFactory.getLogger("com.foo.Bar");
// This request is enabled, because WARN >= INFO
logger.warn("Low fuel level.");
// This request is disabled, because DEBUG < INFO.
logger.debug("Starting search for nearest gas station.");
// The logger instance barlogger, named "com.foo.Bar",
// will inherit its level from the logger named
// "com.foo" Thus, the following request is enabled
// because INFO >= INFO.
barlogger.info("Located nearest gas station.");
// This request is disabled, because DEBUG < INFO.
barlogger.debug("Exiting gas station search");
Não vou mais falar sobre isso.
Recuperando Registradores
Os dois seguintes apontam para o mesmo objeto.
Registrador x = LoggerFactory.getLogger(“wombat”);
Registrador y = LoggerFactory.getLogger(“wombat”);
Anexadores e Layouts
The ability to selectively enable or disable logging requests based on their logger is only part of the picture. Logback allows logging requests to print to multiple destinations. In logback speak, an output destination is called an appender. Currently, appenders exist for the console, files, remote socket servers, to MySQL, PostgreSQL, Oracle and other databases, JMS, and remote UNIX Syslog daemons.
More than one appender can be attached to a logger.
TheaddAppendermethod adds an appender to a given logger. Each enabled logging request for a given logger will be forwarded to all the appenders in that logger as well as the appenders higher in the hierarchy. In other words, appenders are inherited additively from the logger hierarchy. For example, if a console appender is added to the root logger, then all enabled logging requests will at least print on the console. If in addition a file appender is added to a logger, sayL, then enabled logging requests forLandL's children will print on a fileandon the console. It is possible to override this default behavior so that appender accumulation is no longer additive by setting the additivity flag of a logger to false.
A capacidade de ativar ou desativar seletivamente solicitações de log com base no criador de logs é apenas parte dela (nível de log). Logback permite que solicitações de registro sejam impressas em vários destinos. Na linguagem logback, o destino de saída é chamado de anexador. Atualmente, existem complementos para console, arquivos, servidores de soquete remoto, MySQL, PostgreSQL, Oracle e outros bancos de dados, JMS e daemons Syslog UNIX remotos.
Um registrador pode ser conectado a vários complementos.
O método AddAppender adiciona um anexador ao criador de logs fornecido. A tradução por trás não é muito boa, então vou traduzi-la sozinho. Na verdade, isso significa que o anexador pode ser anexado ou herdado como o nível de log. Se root = consoleAppender, então os logs em outros pacotes e classes terão este consoleAppender. Mas se meu pacote xy adicionar um mysqlAppender, então a classe no pacote xy terá mysql + consoleAppender, mas alguns pacotes são mais importantes e não querem para herdar. Para o anexador superior, podemos definir add como false, então teremos apenas o anexador que definimos
root.appender=A1 root não pode definir additivty.flag e finalmente produzir appender=A1
x.append.add=a- x1,a-x2 additivty .flag=true então o último anexador=A1,a-x1,a-x2
xyappender.add=Nó additivty.flag=true xy herda x e o último anexador=A1,a-x1,a- x2
xyzappender.add=a-xyz1 additivty .flag=true xyz herda x e o último appender=A1,a-x1,a-x2,a-xyz1
security.appender.add=a-sec additivty.flag= false não herda root, last appender=a-sec
security_access.appender.add=NONE additivty.flag=true não herda root, mas herda segurança, last appender=a -seg
layout
Por exemplo, o PatternLayout com o padrão de conversão “%-4relative [%thread] %-5level %logger{32} - %msg%n” produzirá algo semelhante a:
176 [main] DEBUG manual.architecture.HelloWorld2 - Hello world.
O primeiro campo é o número de milissegundos decorridos desde o início do programa.
O segundo campo é o thread que emitiu a solicitação de log.
O terceiro campo é o nível da solicitação de log.
O quarto campo é o nome do criador de logs associado à solicitação de log.
O texto após "-" é a mensagem solicitada.
Registro parametrizado
A maneira errada de escrever é
logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i])); A
maneira correta de escrever
é if(logger.isDebugEnabled()) { logger. debug("Número de entrada: " + i + " is " + String.valueOf(entry[i])); } Porque o primeiro também precisa construir msg e, como resultado, descobre-se que o nível de log está errado e não imprime nem produz, então é perda de tempo, enquanto o último só precisa verificar o nível do log, o que leva 1% do tempo. Claro que não importa, nunca vi ninguém fazer isso com tantos detalhes.
Melhor alternativa
logger.debug(“A nova entrada é “+entry+”.”);
logger.debug(“A nova entrada é {}.”, entrada);
A última é 30 vezes melhor que a anterior. . Porque o primeiro é a concatenação de strings de vários objetos, e o último é string.format.
Uma espiada sob o capô
Não entendi o que o site oficial dizia à primeira vista. Sentimentos também não importam