Quando usar os diferentes níveis de log

Queres que a mensagem tire um administrador de sistema da cama a meio da noite?

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

Acho mais útil pensar em separações na perspectiva de ver o ficheiro de Registo.

Fatal / Crítico : aplicação global ou falha do sistema que deve ser investigada imediatamente. Sim, acorda o SysAdmin. Uma vez que preferimos o nosso Sys Admins alerta e bem descansado, esta gravidade deve ser usada muito pouco frequentemente. Se está acontecendo diariamente e isso não é uma BFD, está perdido é significado. Normalmente, um erro Fatal só ocorre uma vez na vida do processo, por isso se o arquivo de log Está ligado ao processo, esta é tipicamente a última mensagem no log.

Erro : definitivamente um problema que deve ser investigado. O SysAdmin deve ser notificado automaticamente, mas não precisa de ser arrastado da cama. Ao filtrar um log para olhar para os erros e acima de você obter uma visão geral da frequência de erros e pode rapidamente identificar a falha iniciadora que pode ter resultado em uma cascata de erros adicionais. Rastrear as taxas de erro como a utilização da aplicação pode produzir métricas de qualidade úteis, como o MTBF, que podem ser utilizadas para avaliar a qualidade global. Por exemplo, esta métrica pode ajudar a informar decisões sobre se outro ciclo de testes beta é necessário ou não antes de uma liberação.

Atenção : isto pode ser um problema,ou não. Por exemplo, as condições ambientais transitórias esperadas, tais como a perda curta da conectividade da rede ou da base de dados, devem ser registadas como avisos e não como erros. Ver um registo filtrado para mostrar apenas avisos e erros pode dar uma visão rápida sobre as primeiras dicas sobre a causa raiz de um erro subsequente. Os avisos devem ser usados com moderação para que não fiquem sem sentido. Por exemplo, perda de acesso à rede deve ser um aviso ou mesmo um erro em uma aplicação de servidor, mas pode ser apenas uma informação em um aplicativo desktop projetado para usuários de laptop ocasionalmente desconectados.

Info : esta é uma informação importante que deve ser registada em condições normais, tais como inicialização bem sucedida, serviços início e paragem ou conclusão com êxito de transacções significativas. A visualização de um log mostrando informações e acima deve dar uma visão rápida das principais mudanças de Estado no processo, proporcionando contexto de alto nível para a compreensão de quaisquer avisos ou erros que também ocorrem. Não tenho muitas mensagens informativas. Nós normalmente temos

Trace : Trace é, de longe, a gravidade mais utilizada e deve fornecer um contexto para compreender os passos que conduzem à aos erros e avisos. Ter a densidade certa de Trace messages torna o software muito mais sustentável, mas requer alguma diligência porque o valor das declarações de Trace individuais pode mudar ao longo do tempo à medida que os programas evoluem. A melhor maneira de conseguir isso é fazendo com que a equipe dev tenha o hábito de revisar logs regularmente como parte padrão dos problemas relatados pelo cliente. Incentivar a equipa a podar as mensagens rastreadas que já não fornecem um contexto útil e a adicionar mensagens onde necessário para compreender o contexto das mensagens subsequentes. Por exemplo, é muitas vezes útil registar a entrada do utilizador, tais como alterar ecrãs ou páginas.

Depurar : consideramos depurar

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

Eu recomendaria a adopção de níveis de severidade do Syslog.
Ver http://en.wikipedia.org/wiki/Syslog#Severity_levels

Devem fornecer níveis de gravidade de grão fino suficientes para a maioria dos casos de utilização e são reconhecidos pelos log-parsers existentes. Enquanto você tem, naturalmente, a liberdade de implementar apenas um subconjunto, por exemplo DEBUG, ERROR, EMERGENCY dependendo dos requisitos do seu aplicativo.

Vamos padronizar algo que já existe há séculos, em vez de criar o nosso próprio padrão para cada aplicação diferente que fazemos. Uma vez que você começa a agregar logs e está tentando detectar padrões através de diferentes que realmente ajuda.

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 a aplicação a abortar.

   [v2. 0 :..] erro grave que impedirá a aplicação de continuar.

2. ERROR:

   [v1.2: ..] erro eventos que ainda podem permitir que a aplicação continue a correr.

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

3. WARN:

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

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

4. INFO:

   [v1.2: ..] mensagens informativas que realçam o progresso da aplicação a um nível grosseiro.

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

5. DEBUG:

   [v1.2: ..] eventos informativos de grão fino que são mais úteis para depurar uma aplicação.

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

6. TRACE:

   [v1.2: ..] eventos informativos de melhor qualidade do que o DEBUG.

   [v2. 0 :..] mensagem de depuração de grão fino, normalmente capturando o fluxo através da aplicação.

---

Apache Httpd (como de costume) gosta de ir para o exagero: §

1. Esmerg:

   O sistema de emergência é inutilizável.

2. Alerta:

   As medidas devem ser tomadas imediatamente [mas o sistema ainda está utilizável].

3. Hematócrito:

   Condições críticas [mas não é necessário tomar medidas imediatamente].

   • "'socket': não foi possível obter um 'socket', a sair do filho"

4. Erro:

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

   • "fim prematuro dos cabeçalhos do programa"

5. Avisar:

   Condições de alerta. [perto de erro, mas não erro]

6. Aviso:

   Normal, mas significativo [notável] condição.

   • "hptpd: apanhado SIGBUS, a tentar despejar o núcleo ..."

7. Informação:

   [[13]] informacional [e inominável].

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

8. Depurar:

   Mensagens de depuração [, isto é, Mensagens registadas em nome de des-bugging].

   • "a abrir o ficheiro de configuração ..."

9. Trace1 → trace6:

   Rastreamento de mensagens [, ou seja, mensagens registadas em nome de rastreamento].

   • "'proxy': FTP: ligação de controlo completo"
   • "'proxy': CONNECT: enviar o pedido de ligação para o 'proxy' remoto"
   • "openssl: aperto de mão: início"
   • "ler da Brigada SSL tamponada, modo 0, 17 bytes"
   • "a pesquisa do mapa falhou: map=rewritemap key=keyname"
   • "a pesquisa da 'cache' falhou, forçando a pesquisa de um novo mapa"

10. Trace7 → trace8:

    [13]] rastreios de mensagens, dumping de 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 |"

---

Apache commons-logging: §

1. Fatal:

   Erros graves que causam terminação prematura. Espere que estes sejam imediatamente visíveis em uma consola de status.

2. Erro:

   Outros erros de execução ou condições inesperadas. Espere que estes sejam imediatamente visíveis em uma consola de status.

3. Avisar:

   Uso de APIs desactualizadas, mau uso de API, erros 'quase', outras situações de execução que são indesejáveis ou inesperadas, mas não necessariamente "erradas". Espere que estes sejam imediatamente visíveis em uma consola de status.

4. Informação:

   Eventos de execução interessantes (arranque/paragem). Esperar estes para serem imediatamente visíveis em um console, por isso, ser conservador e manter ao mínimo.

5. Depurar:

   Informação detalhada sobre o fluxo através do sistema. Espere que estes sejam escritos apenas para logs.

6. Trace:

   Informações mais detalhadas. Espere que estes sejam escritos apenas para logs.

Apache commons-registrando "melhores práticas" para uso empresarial faz uma distinção entre depurar e info com base no tipo de limites que atravessam.

Os limites incluem:

• Fronteiras Externas-Excepções Previstas.

• Fronteiras Externas-Excepções Inesperadas.

• Fronteiras Internas.

• Fronteiras Internas Significativas.

(ver commons-logging guide para mais informações sobre isto.)

Avisos que você pode recuperar. É o meu heurístico, outros podem ter outras ideias.

Por exemplo, digamos que você introduz/importa o nome "Angela Müller" na sua aplicação (anote o umlaut sobre o u). Seu código / banco de dados pode ser apenas Inglês (embora provavelmente não deveria estar neste dia e idade) e poderia, portanto, avisar que todos os caracteres "incomuns" tinham sido convertidos para caracteres normais em inglês.

Contrasta com a tentativa de escrever isso. informações para a base de dados e receber de volta uma mensagem de rede para baixo por 60 segundos seguidos. É mais um erro do que um aviso.

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

Em desenvolvimento, frequentemente uso avisos onde posso colocar o equivalente a uma falha de afirmação, mas a aplicação pode continuar a funcionar; isto permite-me descobrir se esse caso alguma vez realmente acontece, ou se é a minha imaginação.

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

Eu acho que os níveis do SYSLOG de aviso e alerta/emergência são em grande parte supérfluos para o registro ao nível da aplicação-enquanto crítico/alerta/emergência pode ser níveis de alerta úteis para um operador que pode desencadear diferentes ações e notificações, para um administrador de aplicação é tudo o mesmo que FATAL. E não consigo distinguir suficientemente entre receber uma notificação ou alguma informação. Se a informação é notável, não é realmente informação:)

Gosto do Jay Cincotta. interpretação melhor rastreamento da execução do seu código é algo muito útil no suporte técnico, e colocar rastreamentos no código liberalmente deve ser encorajado - especialmente em combinação com um mecanismo de filtragem dinâmico para registrar as mensagens de rastreamento de componentes de aplicação específicos. No entanto, o nível de depuração para mim indica que ainda estamos no processo de descobrir o que está acontecendo - eu vejo a saída de nível de depuração como uma opção apenas de desenvolvimento, não como algo que deve alguma vez aparecer num diário de produção. Há, no entanto, um nível de registo que eu gosto de ver nos meus registos de erro ao usar o chapéu de um sysadmin tanto como o do suporte técnico, ou mesmo do programador: OPER, para mensagens operacionais. Isto eu uso para registar um timestamp, o tipo de operação invocada, os argumentos fornecidos, possivelmente um (único) identificador de tarefa, e completação de tarefa. É usado quando, por exemplo, uma tarefa autônoma é disparada, algo que é uma verdadeira invocação de dentro do aplicativo maior de longa duração. É o tipo de coisa que quero sempre registada, não importa se alguma coisa corre mal ou não, por isso considero o nível de OPER superior ao FATAL, por isso só se pode desligá-lo indo para o modo totalmente silencioso. E é muito mais do que meros dados de log de informação-um nível de log muitas vezes abusado para o spamming logs com pequenas mensagens operacionais sem qualquer valor histórico.

Como o caso determina, esta informação pode ser dirigida para um registo de Invocação separado, ou pode ser obtida filtrando-o para fora. de um grande registro registrando mais informações. Mas é sempre necessário, como informação histórica, para saber o que estava sendo feito - sem descer ao nível de AUDITORIA, outra totalmente diferente nível de log que não tem nada a ver com o mau funcionamento ou a operação do sistema, não cabem dentro de níveis acima mencionados (como ele precisa do seu próprio interruptor de controle, e não uma classificação da gravidade) e que, definitivamente, precisa de seu próprio arquivo de log separado.

Um erro é algo que está errado, simplesmente errado, sem forma de contornar isso, ele precisa ser corrigido.

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

Dito isto, não posso dar um bom exemplo de um aviso que não é também um erro. O que quero dizer com isso é que se você se der ao trabalho de registrar um aviso, você pode muito bem corrigir o problema subjacente. No entanto, coisas como "execução sql leva muito tempo" seja um aviso, enquanto "SQL execução deadlocks" é um erro, então talvez haja alguns casos afinal.

Sempre considerei avisar o primeiro nível de registo que, com certeza, significa que há um problema (por exemplo, talvez um ficheiro de configuração não esteja onde deveria estar e vamos ter de correr com as configurações predefinidas). Um erro implica, para mim, algo que significa que o objetivo principal do software é agora impossível e nós vamos tentar fechar limpo.

De Ietf - Página 10

Each message Priority also has a decimal Severity level indicator.

Estes são descritos no quadro seguinte, juntamente com os seus números valores. Os valores de gravidade devem situar-se entre 0 e 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

Dia,

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

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

Fornecer exemplos, se possível, dos diferentes níveis de Registo. E ser consistente na informação a ser logado em uma mensagem.

HTH

Já construí sistemas antes disso usar o seguinte:

Erro-significa que algo está seriamente errado e que o fio/processo/sequência em particular não pode continuar. É necessária alguma intervenção do utilizador/Administrador
1. aviso-algo não está certo, mas o processo pode continuar como antes (por exemplo, um trabalho num conjunto de 100 falhou, mas o restante pode ser processado)

Nos sistemas que construí, os administradores estavam a ser instruídos a reagir a erros. Por outro lado, vigiaria os avisos e determinaria para cada caso se algum sistema muda, reconfigurações, etc. eram necessárias.

[[1]}Btw, eu sou um grande fã de capturar tudo e filtrar a informação mais tarde.

O que aconteceria se estivesse a capturar a nível de aviso e quisesse alguma informação de depuração relacionada com o aviso, mas não fosse possível recriar o aviso?

Captura Tudo e filtra depois!

Isto aplica-se mesmo ao software embutido, a menos que descubra que o seu processador não consegue acompanhar, caso em que poderá querer redesenhar o seu rastreio para o tornar mais eficiente., ou o rastreamento está interferindo com o tempo (você Pode considerar a depuração em um processador mais poderoso, mas isso abre uma nova lata de minhocas).

Captura Tudo e filtra depois!!

(btw, capturar tudo também é bom, porque permite que você desenvolva ferramentas para fazer mais do que apenas mostrar o traço de depuração (eu desenho gráficos de sequência de mensagens do meu, e histogramas de uso da memória. Também lhe dá uma base de comparação se algo correr mal no futuro (manter todos os logs, passe ou falhe, e certifique-se de incluir o número de compilação no arquivo de log).

Concordo totalmente com os outros, e acho que o GrayWizardx disse melhor.

Tudo o que posso acrescentar é que estes níveis geralmente correspondem às definições dos seus dicionários, por isso não pode ser assim tão difícil. Em caso de dúvida, trate-o como um puzzle. Para o seu projeto em particular, pense em tudo o que você pode querer fazer login.

Podes descobrir o que pode ser fatal? Sabes o que significa fatale, não sabes? Então, quais os itens da tua lista são fatais. Está bem, isso é fatal. lidado, agora vamos olhar para erros ... enxaguar e repetir. Abaixo de Fatal, ou talvez erro, eu sugeriria que mais informação é sempre melhor do que menos, então err "para cima". Não tens a certeza se é informação ou aviso? Então faça disso um aviso. Acho que o erro e a morte devem ser claros para todos nós. Os outros podem ser mais fúzidos, mas é indiscutivelmente menos vital acertar-lhes.

Aqui estão alguns exemplos:

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

Erro - nenhuma resposta à mensagem, transacção interrompida, incapaz de gravar o ficheiro, etc.

Atenção - a atribuição de recursos atinge X% (digamos 80%)-é um sinal de que poderá querer dimensionar o seu.

Info - o utilizador entrou/saiu, Nova transacção, ficheiro fechado, novo campo d/b ou campo apagado.

Depurar - despejo da estrutura de dados interna, qualquer nível de rastreamento com o nome do ficheiro & numero.
A Trace-action foi bem-sucedida/falhou, sendo D / b actualizada.