Quando usar os diferentes níveis de log


520

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?


11
Questão bastante ampla. Portanto, mais de uma resposta é possível, dependendo das circunstâncias reais do log. Alguém vai perder noticenesta coleção alguém não vai ...
Lobo

@ Wolf onde 'aviso' se enquadra nessa hierarquia? Só para constar ...
pgblu

1
noticepode estar faltando porque alguns serviços populares de log como o log4j não o utilizam.
Pgblu

Respostas:


750

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.

2
Por que você não pode mesclar informações e avisar! ??! Não é um aviso sobre algo realmente "info" ...
mP.

35
@ MP Você pode mesclar informações e avisar, acho que geralmente elas são separadas por causa do princípio do "pânico". Se eu tenho um monte de informações rotineiras e apenas listando o estado, não vale a pena olhar para "primeiro", mas se houver muitos "avisos", quero ver os priorizados (depois de Erros e Fatais) para que eu possa analisar eles. Eu ficaria mais "em pânico" com muitos avisos do que muitas mensagens informativas.
precisa saber é o seguinte

3
@dzieciou depende de suas necessidades particulares. Às vezes pode ser fatal, às vezes um aviso. Se eu recebi um 4xx de um serviço crítico de que dependo e não posso continuar, seria um erro / fatal para meus projetos. Se eu estivesse tentando armazenar em cache alguns dados para uso posterior, mas pudesse viver sem eles, seria um aviso. A única vez que vejo informações seria sobre algo como um aplicativo de monitoramento que está relatando o status de suas verificações de URL. Então, eu informaria que recebi um 4xx da URL e segui em frente.
precisa saber é o seguinte

2
@ GreyWizardx, acho que o outro fator é se esse é o cliente que recebeu 4xx ou o servidor que o enviou. No primeiro caso, eu estaria mais disposto a usar ERROR (OMG, é minha culpa não poder preparar a solicitação correta), enquanto no último caso registraria WARN (é culpa dos clientes que eles não podem formular solicitações corretamente)
dzieciou

4
Eu suspeito que isso seja verdade - Debug - Information that is diagnostically helpful to people more than just developers (IT, sysadmins, etc.).. O Logger.Debug destina-se apenas aos desenvolvedores para rastrear problemas muito desagradáveis ​​na produção, por exemplo:If you want to print the value of a variable at any given point inside a for loop against a condition
RBT

304

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

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

11
Exceto que a maioria das pessoas não se importa se tiram as pessoas da cama à noite. Tivemos clientes que aumentaram os requisitos de gravidade 1 (destinados a 100% de interrupção, ou seja, nacional) porque um site não pôde fazer seu trabalho (seu raciocínio era que ele é 100% desse site). Desde então, os "educamos" nessa questão.
21420 Paxdiablo

53
FATALé quando o administrador do sistema acorda, decide que não é pago o suficiente por isso e volta a dormir.
Mateen Ulhaq

135

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.


3
Eu gosto que enfatiza pensar sobre o público. A chave em qualquer comunicação (e as mensagens de log são uma forma de comunicação) é pensar no seu público e no que ele precisa.
sleske

18
Sobre o Debug <-> Rastreio: Observe que pelo menos em Java-land, a ordem de prioridade é "debug> trace". Essa é a convenção que todas as estruturas de registro que conheço usam (SLF4J, Logback, log4j, Apache Commons Logging, Log4Net, NLog). Portanto, Debug <Trace parece incomum para mim.
sleske

1
@ Jay Cincotta Ótima resposta. Acho que a depuração / rastreamento é uma questão de preferência, mas certamente esses tipos de detalhes tendem a ser específicos de aplicativos / empresas, portanto é bom ver opiniões diferentes.
precisa saber é o seguinte

5
Acabei de fazer uma pesquisa com 7 estruturas de registro em vários idiomas. Dos três que incluem um nível de gravidade de "rastreamento", todos eles têm menos gravidade do que a depuração. isto é, trace <debug; Não tenho casos do mundo real em que o oposto seja verdadeiro. @RBT Nem sempre é possível invadir um depurador. Por exemplo, os servidores da web devem atender solicitações em um período finito de tempo ou existir em ambientes multithread e / ou de servidor que podem ser difíceis de instrumentar, ou o bug pode ser raro o suficiente para que um depurador não seja uma opção. Ou você não sabe o que está procurando.
Thanatos

5
@RBT Trabalho com sistemas Java há mais de 4 anos. Posso lhe dizer que o que você está pedindo é completamente impraticável. A depuração do IDE só pode levar você até agora. Em um determinado momento, você simplesmente precisa de logs de depuração de outro sistema (geralmente um servidor de produção ) para entender o que está acontecendo e corrigir o erro. Você pode pensar que ele deve ser reproduzível no IDE local, mas se você trabalha com sistemas reais, verá que muitas vezes muitos bugs são exclusivos do servidor de produção.
ADTC

30

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. trace1trace6 :

    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. trace7trace8 :

    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.)


24

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


5
Mas então, qual é a diferença entre erro e erro fatal?
usar o seguinte comando

37
Um erro é algo que você faz (por exemplo, ler um arquivo inexistente), um erro fatal é algo que é feito para você (por exemplo, falta de memória).
Ignacio Vazquez-Abrams

@ IgnacioVazquez-Abrams Eu gosto da sua maneira de distinguir. Mas qual é o seu comentário é baseado no quê? AFIAK entre os desenvolvedores do iOS, convém escrever uma afirmação relacionada a fatalErrorquando um arquivo não existe. Basicamente, é o oposto do que você disse.
Mel

@ Mel: Em uma situação móvel, é razoável considerar um arquivo ausente como um erro fatal.
Ignacio Vazquez-Abrams

23

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.


1
Preciso de um log de rastreamento, pois quero ver como as coisas estão sendo executadas no meu código. O que o syslog faz para corrigir isso?
K - A toxicidade no SO está crescendo.

Normalmente, os rastreamentos não são algo que você deseja transmitir através do syslog e acho que você pode adicionar esse nível às suas próprias sessões de depuração interativa?
KVZ

2
Todos esses níveis expandidos aumentam a complexidade do log da IMO. É melhor manter o conjunto mais simples, atendendo às necessidades específicas do aplicativo. Para mim, você deve começar com DEBUG, INFO, WARNINGe ERROR. Os desenvolvedores devem ver todos os níveis. Os administradores de sistema até INFOe os usuários finais podem ver avisos e erros, mas apenas se houver uma estrutura para alertá-los sobre isso .
ADTC

1
(continuação) À medida que o aplicativo amadurece, você pode expandir para mais níveis, se necessário. Como ambos DEBUGe TRACEpara os desenvolvedores controlarem a granularidade. E ERRORexpandiu-se para outros níveis como CRITICAL, ALERT, EMERGENCYpara distinguir a gravidade dos erros e determinar a ação com base na gravidade.
ADTC

17

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.


Se o banco de dados estiver em um determinado conjunto de caracteres que não inclua o trema, essa entrada deverá ser rejeitada.
Cochise Ruhulessin

Cochise, o mundo raramente é tão preto e branco :-) #
384

6

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.


5

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.


5

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

4

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


4

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.


3

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.


1
Um bom exemplo de aviso é que, no MySQL, por padrão, se você tentar inserir mais caracteres em um varchardo que o definido, ele avisa que o valor foi truncado, mas ainda o insere. Mas o aviso de uma pessoa pode ser o erro de outra: no meu caso, isso é um erro; significa que cometi um erro no meu código de validação, definindo um comprimento incongruente com o banco de dados. E eu não ficaria muito surpreso se outro mecanismo de banco de dados considerasse isso um erro, e eu não teria o direito real de ficar indignado, afinal, é errado.
Crast

Eu também consideraria isso um erro. Em alguns casos, o conteúdo é "texto" (não no significado do tipo de dados), o que significa que talvez seja correto truncá-lo. Em outro caso, é um código em que o corte de bits o corrompe ou altera seu significado, o que não é bom. Na minha opinião, não cabe ao software tentar adivinhar o que eu quis dizer. Se eu tentar forçar uma string de 200 caracteres em uma coluna que tenha apenas 150 caracteres, é um problema que eu gostaria de saber. No entanto, gosto da distinção feita por outras pessoas aqui, que se você pode se recuperar, é um aviso, mas então ... você precisa fazer logon?
Lasse V. Karlsen

Um exemplo em que pude pensar é: alguma mensagem leva surpreendentemente mais tempo para processar do que o habitual. Pode ser uma indicação de que algo está errado (talvez algum outro sistema esteja sobrecarregado ou um recurso externo esteja temporariamente inativo).
Laradda

3

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.


1

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.


1

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)).


1

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.


0

Sugiro usar apenas três níveis

  1. Fatal - O que interromperia o aplicativo.
  2. Info - Info
  3. Depuração - Informações menos importantes
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.