Práticas recomendadas para usar marcadores no SLF4J / Logback

Estamos usando a combinação SLF4J + Logback em nosso projeto já há algum tempo e estamos bastante satisfeitos com isso, mas nossa estratégia de registro é bastante simples, usando loggers baseados em classes simples e nada sofisticado como MDC ou marcadores.

O que eu quero saber é se alguém da comunidade realmente usa esses recursos e como eles são usados ​​para melhorar o registro / filtragem.

Estou especialmente interessado em onde, por que e como alguém usaria ^[1] Marcadores para o registro. Eles me parecem um recurso bastante interessante para adicionar contexto semântico ao registro - por exemplo, enquanto uma classe pode estar lidando com várias preocupações, pode-se usar marcadores específicos de tarefa / preocupação para discriminar declarações de log.

Quais podem ser as melhores práticas, convenções ou estratégias para criar e usar marcadores no log.

Atualização: Eu acho que o que realmente estou procurando não é tanto o porquê de usar marcadores, mas a parte how - existem algumas práticas recomendadas de nomear marcadores (por exemplo, usar texto sem formatação com espaços ou nomes de estilo de palavra-chave delimitados por traços / sublinhados / pontuação ), deve haver algum tipo de pool de "nomes padrão", nomeando itens com base nas funções de negócios. As perguntas que eu provavelmente posso descobrir por mim mesmo, mas se eu quiser usar esses recursos sistematicamente e apresentá-los a uma equipe de desenvolvedores, faz sentido ter um conjunto formal de diretrizes por aí ...

^[1] - Ao perguntar como usar marcadores, não estou realmente perguntando como usar a API (é realmente bastante simples) - estou me referindo ao nível mais geral de como alguém configuraria o log usando marcadores de forma consistente

Primeiro, como disse @darioo:

• O MDC é usado para associar vários eventos a poucas "entidades"
• [Marcadores] são usados ​​para eventos "especiais" que você deseja filtrar dos eventos comuns

Portanto, sua afirmação de que você deseja usar o MDC para isso. Os marcadores são para destacar eventos "especiais" - filtragem, se preferir - em vez de "fatiar". Por exemplo, você pode fatiar com base em um usuário específico, mas filtrar com base em qualquer exceção inesperada. Nesse caso, você criaria uma dimensão MDC do usuário e um marcador UnexpectedException .

Mas isso aparentemente não aborda a pergunta que você tinha em mente. Você está "se referindo ao nível mais geral de como alguém configuraria o log usando marcadores de forma consistente". Então, vamos abordar isso:

O MDC é para fatiar e cortar em cubos , e os Marcadores são para filtrar . Essas atividades são realizadas durante os testes e na produção . Como tal, é necessário decidir em quais dimensões você espera que seja útil dividir os dados do log e em quais casos pode ser útil filtrá-los quando o teste / produção chegar. Cada dimensão obtém uma dimensão MDC. Cada caso recebe um marcador. É simples assim.

Os desenvolvedores não precisam tomar nenhuma decisão aqui. Uma única pessoa ou equipe deve decidir, em tempo de design , que tipo de fatia, corte e filtragem precisa ser suportado. Isso deve ser informado imaginando que tipo de tarefas de análise se espera que sejam solicitadas a serem executadas.

Essa mesma pessoa ou equipe deve decidir sobre a convenção de nomenclatura. É totalmente arbitrário . Escolha algo que seja esteticamente agradável, auto-descritivo (mais importante) e específico o suficiente para dificilmente entrar em conflito com adições posteriores. Hífens vs. sublinhados é extremamente incisivo e alarmante, mas note que pode ser menos confuso para os funcionários da ESL ler sublinhados (pelo menos em comparação com o CamelCase); ao mesmo tempo, isso irrita alguns desenvolvedores devido ao constrangimento de alcançar as chaves necessárias.

Quanto à decisão de uma política, isso significa apenas definir em quais casos uma determinada dimensão de Marcador ou MDC precisa ser empregada . Mantenha isso firme (centralizado, deliberado), mas permita o feedback dos desenvolvedores se eles sentirem que o conjunto de dimensões e marcadores é insuficiente para a tarefa em questão. Revise / adicione dimensões e / ou atributos conforme apropriado.

Entender esta política será quase necessariamente específico do projeto . Nem todo projeto precisa do mesmo tipo de análise de log. Imagine alguns cenários de pesadelo. Imagine como você gostaria de poder analisar os logs nesse cenário. Você provavelmente não deseja escrever um script complicado para tentar rastrear qual mensagem pertence a qual contexto e qual estado é qual, em que momento, certo? Codifique as informações necessárias como dimensões e marcadores e salve um pouco do aborrecimento se algo der errado.

Primeiro, MDC.

O MDC é realmente útil em um ambiente em que você tem uma "entidade" associada a algum comportamento. Um exemplo típico: usuário interagindo com um aplicativo da web. Então, digamos que você tenha muitos usuários brincando com seu aplicativo da web. Usando o MDC, você pode rastreá-los facilmente sem muito trabalho. Exemplo simplificado:

...[Sandy][abcd] clicked on "change profile"
...[Joe][1234] clicked on "weather reports"
...[Joe][1234] clicked on "Europe"
...[Sandy][abcd] clicked on "logout"
...[Joe][1234] clicked on "logout"
...[Sandy][efgh] logged in

Aqui, você está usando o MDC em dois locais: para nome de usuário e ID da sessão. Dessa forma, você pode facilmente saudar a sessão de um usuário para ver tudo o que está fazendo.

Segundo, marcadores.

Os marcadores geralmente são usados ​​para circunstâncias "especiais", como o envio de um email a um administrador por alguns erros críticos. Nem todos os erros sempre caem na mesma categoria; alguns têm que ser tratados de maneira apropriada.

Ou, quando um usuário sai do seu serviço, ele geralmente acessa um log INFO, mas você também pode usar um marcador para tais instâncias, se desejar que eventos como este sejam inseridos em um arquivo de log separado, para que você possa monitorá-lo. mais facilmente para a coleta estatística de usuários que saem.

Regra prática:

• O MDC é usado para associar vários eventos a poucas "entidades"
• marcadores são usados ​​para eventos "especiais" que você deseja filtrar dos comuns

Marcadores podem ser usados ​​para colorir ou marcar uma única instrução de log. O que você faz com essas cores, ou seja, marcadores, depende inteiramente de você. No entanto, dois padrões parecem ser comuns (o primeiro mais comum que o segundo) para o uso de marcadores.

1. Disparo : algum solicitante pode ser instruído a executar uma ação na presença de um determinado marcador. Por exemplo, SMTPAppenderpode ser configurado para enviar um email sempre que um evento de log for marcado com o NOTIFY_ADMINmarcador, independentemente do nível do log. Consulte o disparo baseado em marcador na documentação do logback. Você também pode combinar níveis e marcadores de log para acionar.

2. Filtragem : por exemplo, você pode colorir / marcar todos os seus logs relacionados à persistência (em vários e múltiplos arquivos de classe) com a cor "DB". Você pode filtrar o "DB": desabilite o log, exceto as instruções de log marcadas com DB. Consulte o capítulo sobre filtros na documentação do logback para obter mais informações (pesquise MarkerFilter).

Assim como um adendo, se você estiver usando o logstash e o json log ativado, existe outro uso potencial do Marker - para que as variáveis ​​de log sejam associadas a uma mensagem de log específica. Isso é mais consistente e mais fácil de analisar do que incluí-lo no corpo da mensagem. Muito útil, se for adequado ao seu caso de uso.

Veja detalhes aqui:

https://github.com/logstash/logstash-logback-encoder#loggingevent_custom_event