Quando usar os diferentes níveis de log

Existem diferentes maneiras de registrar mensagens, em ordem de fatalidade:

1. FATAL

2. ERROR

3. WARN

4. INFO

5. DEBUG

6. TRACE

Como decido quando usar qual?

O que é uma boa heurística para usar?

Geralmente, assino a seguinte convenção:

• Rastrear - Somente quando eu estaria "rastreando" o código e tentando encontrar especificamente uma parte de uma função.
• Depuração - informações que são diagnosticadas úteis para as pessoas mais do que apenas desenvolvedores (TI, administradores de sistemas etc.).
• Info - informações geralmente úteis para registrar (início / parada do serviço, suposições de configuração, etc.). Informações que eu sempre quero ter disponíveis, mas geralmente não me importo em circunstâncias normais. Este é o meu nível de configuração pronto para uso.
• Aviso - Qualquer coisa que possa causar estranheza de aplicativos, mas para a qual estou me recuperando automaticamente. (Como alternar de um servidor primário para um servidor de backup, tentar novamente uma operação, perder dados secundários etc.)
• Erro - Qualquer erro fatal para a operação , mas não o serviço ou aplicativo (não é possível abrir um arquivo necessário, dados ausentes etc.). Esses erros forçarão a intervenção do usuário (administrador ou usuário direto). Geralmente, são reservados (nos meus aplicativos) para cadeias de conexão incorretas, serviços ausentes etc.
• Fatal - Qualquer erro que esteja forçando o desligamento do serviço ou aplicativo para evitar perda de dados (ou perda adicional de dados). Eu os reservo apenas para os erros e situações mais hediondos em que é garantido que houve corrupção ou perda de dados.

Deseja que a mensagem tire um administrador do sistema da cama no meio da noite?

• sim -> erro
• não -> avisar

Acho mais útil pensar em severidades da perspectiva de exibição do arquivo de log.

Fatal / Crítico : Falha geral no aplicativo ou no sistema que deve ser investigada imediatamente. Sim, acorde o SysAdmin. Como preferimos o alerta do SysAdmins e estamos descansados, essa severidade deve ser usada com pouca frequência. Se está acontecendo diariamente e não é um BFD, está perdido seu significado. Normalmente, um erro fatal ocorre apenas uma vez na vida útil do processo; portanto, se o arquivo de log estiver vinculado ao processo, essa será a última mensagem no log.

Erro : Definitivamente um problema que deve ser investigado. O SysAdmin deve ser notificado automaticamente, mas não precisa ser arrastado da cama. Ao filtrar um log para examinar os erros e acima, você obtém uma visão geral da frequência dos erros e pode identificar rapidamente a falha inicial que pode ter resultado em uma cascata de erros adicionais. O rastreamento das taxas de erro versus o uso do aplicativo pode gerar métricas úteis de qualidade, como MTBF, que podem ser usadas para avaliar a qualidade geral. Por exemplo, essa métrica pode ajudar a informar as decisões sobre a necessidade ou não de outro ciclo de testes beta antes do lançamento.

Aviso : PODE ser um problema ou não. Por exemplo, condições ambientais transitórias esperadas, como perda curta de conectividade de rede ou banco de dados, devem ser registradas como avisos, não erros. A visualização de um log filtrado para mostrar apenas avisos e erros pode fornecer informações rápidas sobre dicas iniciais da causa raiz de um erro subsequente. Os avisos devem ser usados ​​com moderação para que não fiquem sem sentido. Por exemplo, a perda de acesso à rede deve ser um aviso ou até mesmo um erro em um aplicativo de servidor, mas pode ser apenas uma informação em um aplicativo de desktop projetado para usuários de laptop desconectados ocasionalmente.

Informações : são informações importantes que devem ser registradas em condições normais, como inicialização bem-sucedida, inicialização e parada de serviços ou conclusão bem-sucedida de transações significativas. A visualização de um log mostrando Informações e acima deve fornecer uma rápida visão geral das principais alterações de estado no processo, fornecendo um contexto de nível superior para entender quaisquer avisos ou erros que também ocorram. Não possui muitas mensagens informativas. Normalmente, temos <5% de mensagens informativas relativas ao rastreamento.

Rastreio : O rastreio é de longe a gravidade mais usada e deve fornecer contexto para entender as etapas que levam a erros e avisos. Ter a densidade certa de mensagens de rastreamento torna o software muito mais sustentável, mas requer alguma diligência, pois o valor das instruções individuais do rastreamento pode mudar com o tempo à medida que os programas evoluem. A melhor maneira de conseguir isso é adquirir a equipe de desenvolvimento com o hábito de revisar regularmente os logs como parte padrão da solução de problemas relatados pelos clientes. Incentive a equipe a remover mensagens de rastreamento que não fornecem mais contexto útil e a adicionar mensagens quando necessário para entender o contexto de mensagens subseqüentes. Por exemplo, geralmente é útil registrar a entrada do usuário, como alterar telas ou guias.

Debug : Consideramos Debug <Rastreio. A distinção é que as mensagens de depuração são compiladas a partir das versões do Release. Dito isto, desencorajamos o uso de mensagens de depuração. Permitir mensagens de depuração tende a levar a que mais e mais mensagens de depuração sejam adicionadas e nenhuma seja removida. Com o tempo, isso torna os arquivos de log quase inúteis, porque é muito difícil filtrar o sinal do ruído. Isso faz com que os desenvolvedores não usem os logs que continuam a espiral da morte. Por outro lado, as mensagens Trace constantemente removidas incentivam os desenvolvedores a usá-las, o que resulta em uma espiral virtuosa. Além disso, isso elimina a possibilidade de erros introduzidos devido aos efeitos colaterais necessários no código de depuração que não estão incluídos na versão. Sim, eu sei que isso não deve acontecer em bom código, mas é melhor prevenir do que remediar.

Aqui está uma lista do que "os madeireiros" têm.

Apache log4j: §1 , §2

1. FATAL:

   [ v1.2 : ..] eventos de erro muito graves que provavelmente levarão o aplicativo a abortar.

   [ v2.0 : ..] erro grave que impedirá o aplicativo de continuar.

2. ERROR:

   Eventos de erro [ v1.2 : ..] que ainda podem permitir que o aplicativo continue em execução.

   [ v2.0 : ..] erro no aplicativo, possivelmente recuperável.

3. WARN:

   [ v1.2 : ..] situações potencialmente perigosas.

   [ v2.0 : ..] que pode ser possível [ sic ] levar a um erro.

4. INFO:

   [ v1.2 : ..] mensagens informativas que destacam o progresso do aplicativo em nível de granulação grossa.

   [ v2.0 : ..] para fins informativos.

5. DEBUG:

   [ v1.2 : ..] eventos informativos refinados que são mais úteis para depurar um aplicativo.

   [ v2.0 : ..] evento de depuração geral.

6. TRACE:

   [ v1.2 : ..] eventos informativos de granularidade mais fina que o DEBUG.

   [ v2.0 : ..] mensagem de depuração refinada, geralmente capturando o fluxo através do aplicativo.

O Apache Httpd (como sempre) gosta de exagerar: §

1. emerg :

   Emergências - o sistema é inutilizável.

2. alerta :

   A ação deve ser executada imediatamente [mas o sistema ainda é utilizável].

3. crit :

   Condições críticas [mas nenhuma ação precisa ser tomada imediatamente].

   • " socket: falha ao obter um socket, saindo do child "

4. erro :

   Condições de erro [mas não críticas].

   • " Fim prematuro dos cabeçalhos de script "

5. avisar :

   Condições de aviso. [quase erro, mas não erro]

6. aviso :

   Condição normal, mas significativa [ notável ].

   • " httpd: travado SIGBUS, tentando despejar o núcleo em ... "

7. informação :

   Informativo [e notável].

   • ["O servidor está em execução há x horas. "]

8. debugar :

   Mensagens no nível de depuração [, ou seja, mensagens registradas para eliminar erros )].

   • " Abrindo arquivo de configuração ... "

9. trace1 → trace6 :

   Rastrear mensagens [, ou seja, mensagens registradas para fins de rastreamento ].

   • " proxy: FTP: conexão de controle concluída "
   • " proxy: CONNECT: enviando a solicitação CONNECT ao proxy remoto "
   • " openssl: Handshake: start "
   • " lido da brigada SSL em buffer, modo 0, 17 bytes "
   • " pesquisa no mapa FAILED:map=rewritemap key=keyname "
   • " pesquisa de cache FAILED, forçando nova pesquisa de mapa "

10. trace7 → trace8 :

    Rastrear mensagens, descarregando grandes quantidades de dados

    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"
    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"

Registro comum do Apache: §

1. fatal :

   Erros graves que causam rescisão prematura. Espere que eles fiquem visíveis imediatamente em um console de status.

2. erro :

   Outros erros de tempo de execução ou condições inesperadas. Espere que eles sejam visíveis imediatamente em um console de status.

3. avisar :

   Uso de APIs obsoletas, uso inadequado da API, 'quase' erros, outras situações de tempo de execução indesejáveis ​​ou inesperadas, mas não necessariamente "erradas". Espere que eles fiquem visíveis imediatamente em um console de status.

4. informação :

   Eventos de tempo de execução interessantes (inicialização / desligamento). Espere que eles sejam imediatamente visíveis em um console, portanto, seja conservador e mantenha-o no mínimo.

5. debugar :

   informações detalhadas sobre o fluxo no sistema. Espere que eles sejam gravados apenas em logs.

6. traço :

   informações mais detalhadas. Espere que eles sejam gravados apenas em logs.

As "melhores práticas" do Apache commons-log para uso corporativo fazem uma distinção entre depuração e informações com base no tipo de limite que eles cruzam.

Os limites incluem:

• Limites externos - exceções esperadas.

• Limites externos - exceções inesperadas.

• Limites internos.

• Limites internos significativos.

(Consulte o guia de registro comum para obter mais informações sobre isso.)

Se você pode se recuperar do problema, é um aviso. Se impedir a execução contínua, é um erro.

Eu recomendo adoção de níveis de gravidade Syslog: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY.
Veja http://en.wikipedia.org/wiki/Syslog#Severity_levels

Eles devem fornecer níveis de gravidade refinados suficientes para a maioria dos casos de uso e são reconhecidos pelos analisadores de log existentes. Embora você tenha a liberdade de implementar apenas um subconjunto, por exemplo, DEBUG, ERROR, EMERGENCYdependendo dos requisitos do seu aplicativo.

Vamos padronizar algo que existe há séculos, em vez de criar nosso próprio padrão para cada aplicativo diferente que criamos. Depois de começar a agregar logs e tentar detectar padrões em diferentes, isso realmente ajuda.

Avisos dos quais você pode se recuperar. Erros que você não pode. Essa é a minha heurística, outros podem ter outras idéias.

Por exemplo, digamos que você insira / importe o nome "Angela Müller"no seu aplicativo (observe o trema sobre o u). Seu código / banco de dados pode ser apenas em inglês (embora provavelmente não deva ser hoje em dia) e, portanto, pode avisar que todos os caracteres "incomuns" foram convertidos em caracteres comuns em inglês.

Compare isso ao tentar gravar essas informações no banco de dados e recuperar uma mensagem de inatividade da rede por 60 segundos seguidos. Isso é mais um erro do que um aviso.

Como outros já disseram, erros são problemas; avisos são problemas em potencial.

No desenvolvimento, freqüentemente uso avisos em que posso colocar o equivalente a uma falha de asserção, mas o aplicativo pode continuar funcionando; isso me permite descobrir se esse caso realmente acontece ou se é minha imaginação.

Mas sim, tudo se resume aos aspectos de recuperação e realidade. Se você pode se recuperar, provavelmente é um aviso; se faz com que algo realmente falhe, é um erro.

Eu acho que os níveis SYSLOG AVISO e ALERTA / EMERGÊNCIA são amplamente supérfluos para o registro no nível do aplicativo - enquanto CRITICAL / ALERT / EMERGENCY pode ser níveis de alerta úteis para um operador que pode acionar ações e notificações diferentes, para um administrador de aplicativo é o mesmo que FATAL. E simplesmente não consigo distinguir suficientemente entre receber um aviso ou alguma informação. Se a informação não é digna de nota, não é realmente informação :)

Eu gosto mais da interpretação de Jay Cincotta - rastrear a execução do seu código é algo muito útil no suporte técnico, e colocar instruções de rastreamento no código liberalmente deve ser incentivado - especialmente em combinação com um mecanismo de filtragem dinâmica para registrar as mensagens de rastreamento dos componentes específicos do aplicativo. No entanto, o nível de DEBUG para mim indica que ainda estamos no processo de descobrir o que está acontecendo - vejo a saída no nível de DEBUG como uma opção apenas de desenvolvimento, não como algo que deveria aparecer em um log de produção.

No entanto, há um nível de log que eu gosto de ver nos meus logs de erro ao usar o chapéu de um administrador de sistemas tanto quanto o de suporte técnico ou mesmo desenvolvedor: OPER, para mensagens OPERACIONAIS. Isso eu uso para registrar um registro de data e hora, o tipo de operação invocada, os argumentos fornecidos, possivelmente um identificador de tarefa (exclusivo) e a conclusão da tarefa. É usado quando, por exemplo, uma tarefa autônoma é disparada, algo que é uma verdadeira invocação a partir do aplicativo maior de longa duração. É o tipo de coisa que eu sempre quero registrar, não importa se algo der errado ou não, por isso considero o nível de OPER maior que FATAL, para que você possa desativá-lo apenas no modo totalmente silencioso. E são muito mais do que meros dados de log INFO - um nível de log frequentemente usado para logs de spam com pequenas mensagens operacionais sem valor histórico.

Conforme o caso, essas informações podem ser direcionadas para um log de chamada separado ou podem ser obtidas filtrando-a de um log grande registrando mais informações. Mas é sempre necessário, como informações históricas, saber o que estava sendo feito - sem descer para o nível de AUDIT, outro nível de log totalmente separado que não tem nada a ver com mau funcionamento ou operação do sistema, não se encaixa realmente nos níveis acima ( pois precisa de sua própria opção de controle, não de uma classificação de gravidade) e que definitivamente precisa de seu próprio arquivo de log separado.

Do RFC 5424, o Syslog Protocol (IETF) - Página 10:

Cada mensagem Priority também possui um indicador de nível de gravidade decimal. Eles são descritos na tabela a seguir, juntamente com seus valores numéricos. Os valores de gravidade DEVEM estar na faixa de 0 a 7, inclusive.

       Numerical         Severity
         Code

          0       Emergency: system is unusable
          1       Alert: action must be taken immediately
          2       Critical: critical conditions
          3       Error: error conditions
          4       Warning: warning conditions
          5       Notice: normal but significant condition
          6       Informational: informational messages
          7       Debug: debug-level messages

          Table 2. Syslog Message Severities

G'day,

Como corolário desta pergunta, comunique suas interpretações dos níveis de log e verifique se todas as pessoas em um projeto estão alinhadas na interpretação dos níveis.

É doloroso ver uma grande variedade de mensagens de log em que as gravidades e os níveis de log selecionados são inconsistentes.

Forneça exemplos, se possível, dos diferentes níveis de log. E seja consistente nas informações a serem registradas em uma mensagem.

HTH

Eu concordo totalmente com os outros e acho que o GrayWizardx disse isso melhor.

Tudo o que posso acrescentar é que esses níveis geralmente correspondem às suas definições de dicionário, por isso não pode ser tão difícil. Em caso de dúvida, trate-o como um quebra-cabeça. Para seu projeto em particular, pense em tudo o que você pode querer registrar.

Agora, você pode descobrir o que pode ser fatal? Você sabe o que significa fatal, não é? Então, quais itens da sua lista são fatais.

Ok, isso é fatal, agora vamos ver os erros ... enxágue e repita.

Abaixo de Fatal, ou talvez Erro, eu sugeriria que mais informações são sempre melhores que menos, portanto, erre "para cima". Não tem certeza se é Info ou Aviso? Então faça um aviso.

Eu acho que Fatal e erro devem ser claros para todos nós. Os outros podem estar mais confusos, mas é indiscutivelmente menos vital acertá-los.

aqui estão alguns exemplos:

Fatal - não pode alocar memória, banco de dados, etc. - não pode continuar.

Erro - nenhuma resposta à mensagem, transação abortada, não é possível salvar o arquivo etc.

Aviso - a alocação de recursos atinge X% (por exemplo, 80%) - isso é um sinal de que você pode querer redimensionar sua.

Info - usuário conectado / desconectado, nova transação, criação de arquivo, novo campo d / b ou campo excluído.

Depuração - despejo da estrutura de dados interna, nível de rastreamento com o nome do arquivo e o número da linha.
Rastreio - ação bem-sucedida / com falha, d / b atualizado.

Um erro é algo que está errado, completamente errado, sem solução, ele precisa ser corrigido.

Um aviso é um sinal de um padrão que pode estar errado, mas também pode não estar.

Dito isto, não posso apresentar um bom exemplo de aviso que também não seja um erro. O que quero dizer com isso é que, se você tiver o problema de registrar um aviso, poderá corrigir o problema subjacente.

No entanto, coisas como "execução do sql leva muito tempo" podem ser um aviso, enquanto "deadlocks de execução do sql" é um erro, portanto, talvez haja alguns casos, afinal.

Sempre considerei avisar o primeiro nível de log que, com certeza, significa que há um problema (por exemplo, talvez um arquivo de configuração não esteja onde deveria estar e teremos que executar as configurações padrão). Um erro implica, para mim, algo que significa que o objetivo principal do software agora é impossível e vamos tentar desligar de forma limpa.

Eu criei sistemas antes disso, usando o seguinte:

1. ERRO - significa que algo está seriamente errado e esse segmento / processo / sequência em particular não pode continuar. É necessária alguma intervenção do usuário / administrador
2. AVISO - algo não está certo, mas o processo pode continuar como antes (por exemplo, um trabalho em um conjunto de 100 falhou, mas o restante pode ser processado)

Nos sistemas que eu construí, os administradores estavam sob instruções para reagir a ERROS. Por outro lado, observaríamos WARNINGS e determinaríamos para cada caso se eram necessárias alterações, reconfigurações, etc. do sistema.

Aliás, sou um grande fã de capturar tudo e filtrar as informações mais tarde.

O que aconteceria se você estivesse capturando no nível de Aviso e desejasse algumas informações de Depuração relacionadas ao aviso, mas não pudesse recriá-lo?

Capture tudo e filtre mais tarde!

Isso vale mesmo para o software incorporado, a menos que você descubra que o seu processador não consegue acompanhar; nesse caso, você pode refazer o design do seu rastreio para torná-lo mais eficiente ou o rastreamento está interferindo no tempo (você pode considerar a depuração no um processador mais poderoso, mas que abre toda uma outra lata de worms).

Capture tudo e filtre mais tarde !!

(btw, capturar tudo também é bom porque permite desenvolver ferramentas para fazer mais do que apenas mostrar o rastreamento de depuração. futuro (mantenha todos os logs, passem ou não, e inclua o número da compilação no arquivo de log)).

Meus dois centavos FATALe TRACEníveis de log de erros.

ERROR é quando ocorre alguma falha (exceção).

FATAL é realmente DOUBLE FAULT: quando ocorre uma exceção ao manipular uma exceção.

É fácil entender o serviço da web.

1. Pedido vem. O evento é registrado comoINFO
2. O sistema detecta pouco espaço em disco. O evento é registrado comoWARN
3. Alguma função é chamada para lidar com a solicitação. Durante o processamento, ocorre a divisão por zero. O evento é registrado comoERROR
4. O manipulador de exceção do serviço da Web é chamado para manipular a divisão por zero. O serviço / estrutura da Web vai enviar email, mas não pode porque o serviço de correspondência está offline agora. Esta segunda exceção não pode ser manipulada normalmente, porque o manipulador de exceção do serviço da Web não pode processar a exceção.
5. Manipulador de exceção diferente chamado. O evento é registrado comoFATAL

TRACEé quando podemos rastrear a entrada / saída da função. Não se trata de log, porque esta mensagem pode ser gerada por algum depurador e seu código não foi chamado log. Portanto, as mensagens que não são do seu aplicativo são marcadas como TRACEnível. Por exemplo, você executa seu aplicativo comstrace

Então, geralmente em seu programa que você faz DEBUG, INFOe WARNlogging. E somente se você estiver escrevendo algum serviço / estrutura da web, você usará FATAL. E quando você está depurando um aplicativo, você obtém o TRACElog desse tipo de software.

Sugiro usar apenas três níveis

1. Fatal - O que interromperia o aplicativo.
2. Info - Info
3. Depuração - Informações menos importantes