Regras e conselhos para o log?

Na minha organização, reunimos algumas regras / guildelines sobre o registro que eu gostaria de saber se você pode adicionar ou comentar.

Usamos Java, mas você pode comentar em geral sobre loggin - regras e conselhos

1. Use o nível de log correto

   • ERRO: Algo deu muito errado e precisa ser corrigido imediatamente
   • AVISO: O processo pode continuar sem correção. O aplicativo deve tolerar esse nível, mas o aviso sempre deve ser investigado.
   • INFO: informações de que um processo importante foi concluído
   • DEPURAR. Só é usado durante o desenvolvimento

2. Verifique se você sabe o que está registrando.

3. Evite que o registro influencie o comportamento do aplicativo

A função do log deve ser escrever mensagens no log.

1. As mensagens de log devem ser descritivas, claras, curtas e concisas.

Não há muito uso de uma mensagem sem sentido na solução de problemas.

1. Coloque as propriedades corretas no log4j

Coloque que o método e a classe certos são escritos automaticamente.

Exemplo:

Datedfile -web

log4j.rootLogger=ERROR, DATEDFILE
log4j.logger.org.springframework=INFO
log4j.logger.waffle=ERROR
log4j.logger.se.prv=INFO
log4j.logger.se.prv.common.mvc=INFO
log4j.logger.se.prv.omklassning=DEBUG

log4j.appender.DATEDFILE=biz.minaret.log4j.DatedFileAppender
log4j.appender.DATEDFILE.layout=org.apache.log4j.PatternLayout
log4j.appender.DATEDFILE.layout.ConversionPattern=%d{HH:mm:ss,SSS} %-5p [%C{1}.%M] - %m%n

log4j.appender.DATEDFILE.Prefix=omklassning.
log4j.appender.DATEDFILE.Suffix=.log
log4j.appender.DATEDFILE.Directory=//localhost/WebSphereLog/omklassning/

1. Valor do log.

Por favor, registre valores do aplicativo.

1. Prefixo do log.

Indique de que parte do aplicativo é que o registro foi gravado, de preferência com algo para o prefixo acordado do projeto, por exemplo PANDORA_DB

1. A quantidade de texto.

Tenha cuidado para que não haja muito texto de log. Pode influenciar o desempenho do aplicativo.

1. Formato de registro:

-Existem várias variantes e métodos para usar com o log4j, mas gostaríamos de um uso uniforme do seguinte formato, quando registramos com exceções:

logger.error("PANDORA_DB2: Fel vid hämtning av frist i TP210_RAPPORTFRIST", e);

No exemplo acima, supõe-se que configuramos as propriedades do log4j para que ele grave automaticamente a classe e o método.

Sempre use o logger e não o seguinte:

System.out.println(), System.err.println(), e.printStackTrace()

Se o aplicativo Web usar nossa estrutura, você poderá obter informações de erro muito detalhadas do EJB, se estiver usando try-catch no manipulador e efetuando log de acordo com o modelo acima:

Em nosso projeto, usamos esse padrão de conversão com o qual os nomes de métodos e classes são gravados automaticamente. Aqui, usamos dois pattents diferentes para o console e o datedfileappender:

log4j.appender.CONSOLE.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n

log4j.appender.DATEDFILE.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

Nos exemplos acima, o método e a classe serão gravados. No número da linha do console também será escrito nosso.

1. toString()

Por favor, tenha um toString()para cada objeto. EX:

@Override
public String toString() {
  StringBuilder sb = new StringBuilder();
  sb.append(" DwfInformation [ ");
  sb.append("cc: ").append(cc);
  sb.append("pn: ").append(pn);
  sb.append("kc: ").append(kc);
  sb.append("numberOfPages: ").append(numberOfPages);
  sb.append("publicationDate: ").append(publicationDate);
  sb.append("version: ").append(version);
  sb.append(" ]");
  return sb.toString();
}

em vez de um método especial que faz essas saídas

public void printAll()
{
    logger.info("inbet: " + getInbetInput());
    logger.info("betdat: " + betdat);
    logger.info("betid: " + betid);
    logger.info("send: " + send);
    logger.info("appr: " + appr);
    logger.info("rereg: " + rereg);   
    logger.info("NY: " + ny);   
    logger.info("CNT: " + cnt);   
}

Então, há algo que você possa adicionar, comentar ou achar questionável com essas maneiras de usar o registro? Sinta-se à vontade para responder ou comentar, mesmo que não esteja relacionado a Java, Java e log4j, é apenas uma implementação de como isso é fundamentado.

Como uma extensão da sua regra de log, de onde veio a instrução de log no aplicativo, convém adicionar sinalizadores de log no nível por módulo. Em vez de registrar tudo, o tempo todo, isso permite segmentar seletivamente seções do seu aplicativo. Existe uma sobrecarga nisso, e você precisa criar um recurso que permita ativar / desativar esse log. Idealmente, você seria capaz de ativar / desativar on-the-fly enquanto o aplicativo está sendo executado.

Estou acostumado a ver uma camada abaixo da depuração, que chamo de "Trace", mas isso não é necessariamente um termo universal. O registro de nível "Trace" rastreia o máximo que você pode suportar, incluindo entrada / saída de módulo, registros de data e hora com entrada / saída e pontos de bônus para capturar valores passados. Obviamente, isso gera MUITOS dados e não é algo que você ativa quer ou não. Mas tem vantagens em relação à depuração quando você não pode se conectar ao processo ou não possui um dump principal do aplicativo incorreto.

Eu gosto de ver referências de arquivo / módulo e registros de data e hora com minhas informações de log. Pode ser útil ao tentar procurar condições de corrida entre threads, além de coordenar as atividades de várias áreas do aplicativo. Para ser justo, eu conheço algumas pessoas que pensam que esses detalhes bagunçam o arquivo de log. Adicionar o registro de data e hora é algo a discutir com a equipe. (Desculpas se log4j já faz isso.)

Se o registro não estiver sendo tratado por seu próprio encadeamento / processo, é algo a considerar também. Em vez de fazer com que o encadeamento do aplicativo aguarde o processamento do log, a mensagem de log é passada para o manipulador de log e o encadeamento do aplicativo segue seu caminho alegre. Como alternativa, criar algum tipo de mecanismo de buffer para manipular as mensagens de log é outra maneira de acelerar a capacidade de resposta do aplicativo.

Ter controles sobre o tamanho e o histórico dos arquivos de log é outro recurso a ser considerado. Você não deseja que o aplicativo gaste todo o espaço em disco no sistema host, nem necessariamente mantenha todos os arquivos de log por toda a eternidade.

Uma coisa a ter em mente é verificar o nível de log antes de executar qualquer tipo de operação de cadeia para log. Ou seja, não faça todo o trabalho de configurar um formatador de datas ou concatenar várias seqüências de caracteres para criar a mensagem de log, se você realmente não deseja registrá-la. Isso é apenas desperdício de trabalho que torna seu aplicativo lento.

Para sua informação, o projeto Apache Commons possui uma ToStringBuilder classe que simplifica a criação de seus toString()métodos.

Não acho nada questionável no que você adicionou aqui Nick. É assim que faço isso há algum tempo. A postagem que você forneceu é muito detalhada e provavelmente pode ser usada como uma espécie de tutorial para o log. No entanto, quero adicionar uma coisa aqui, que é: Em muitos lugares, tenho visto pessoas usando log condicional, por exemplo:

     if(env_local)
     {
     write_to_local();
     }    
     else if(env_IT)
     {
     write_to_IT();
     } 
     else if(env_PROD)
     {
     write_to_prod();
     } 
     else
     dosomething();

Eu acho que esse tipo de rastreamento ou depuração condicional não é o melhor caminho a percorrer.

Além de registrar a classe / método que gerou o erro, seria útil também registrar os parâmetros passados ​​para esse método. Saber onde um erro foi gerado não é muito útil se ocorrer apenas uma vez em mil; você também precisa saber quais dados causaram o erro.

Também achei útil ter uma variável que define o nível padrão de log para um aplicativo. Dessa forma, você pode ter o código DEBUG e INFO ao lado do código WARNING e ERROR. Ao executar no modo de produção, o padrão é não gerar informações de DEBUG, mas quando um bug aparece, você pode atualizar um sinalizador e começar a gravar mensagens DEBUG no log também.

A extração de madeira é, na maioria das vezes, uma preocupação transversal. Somente o Java não é expressivo o suficiente para torná-lo capaz de separar o log das lógicas de negócios reais. Isso significa que você não pode, por exemplo, apenas pegar um método e colocá-lo em outro projeto, mas é necessário remover e ajustar todo o seu log antes de fazê-lo. E isso é só a ponta do icebergue.

Para evitar esse e outros problemas ao mesclar log e lógica de negócios "real", você deve considerar o uso de programação orientada a aspectos. Para Java, a estrutura mais usada seria o AspectJ. Existe este vídeo do youtube das conversas sobre tecnologia do Google que explica muito bem o AspectJ e seus usos além do registro. Você encontrará muitos exemplos para se registrar, é claro, aqui também no stackexchange .

Uma coisa que eu sugeriria seria que você tivesse um meio de ter vários contextos de log associados a qualquer arquivo de log específico e providencie para que qualquer coisa gravada em qualquer contexto de log seja registrada, a menos que o código solicite explicitamente que o contexto de log descarte seu conteúdo. Esse design permitirá capturar logs bastante detalhados durante uma operação e descartá-los se a operação for bem-sucedida, mas tê-los disponíveis se a operação falhar. Na ausência desse recurso de registro, ter bons registros disponíveis quando algo falhar pode exigir que um aplicativo perca muito tempo registrando dados inúteis nas 99,99% das vezes em que tudo funciona.