Quanta informação para registrar de erros? [fechado

Question

Na empresa em que trabalho, criei uma classe de log de erros para lidar com erros no meu aplicativo ASP.NET. É uma classe personalizada porque não temos permissão para instalar software adicional em nossos servidores (nlog, log4net etc.).

Atualmente, eu o uso em dois dos meus projetos e vi alguns bons resultados. No momento, estou aprisionando os erros que causam erros de página e aplicativos. Ele envia e armazena a mensagem de erro e todas as exceções internas.

O problema que estou tendo agora é que estou recebendo erros que não tenho certeza de como reproduzir. Não ouvi nenhum relato de erro de nenhum dos meus usuários. Não tenho certeza do que eles estão fazendo, ou mesmo que estejam vendo -os como erros.

Estou pensando em criar um log de eventos em cada página, ou em que quero informações adicionais. Mantendo -o como uma variável de sessão na página e escrevendo eventos para ele (início/final das funções, alterações variáveis, etc.). Somente se um erro for chamado para que isso envie junto com a mensagem de erro para ver se ele fornece uma imagem melhor do que está acontecendo. Espero que fazê -lo dessa maneira não me dê toneladas de logs de eventos quando todos os usuários acessarem o aplicativo, só querer estar acontecendo antes que o erro aconteça com o usuário.

Você conhece alguma armadilha que eu deveria vigiar o método?

Você tem algum conselho para que as coisas procurem?

Atualizar:

@Saret: Eu não tenho de onde você vem com essa resposta e concordo. Sou bastante novo nesta empresa e ainda preciso aprender como eles fazem as coisas. No passado, conversei com meus colegas de trabalho como seria ótimo ter este produto ou usar este projeto de código aberto. O problema se resume a se o que trabalhamos em sistemas seguros e obtemos aprovação para obter essas coisas leva muito tempo, cobertura superior e lidando com toda a burocracia. Vou analisar mais a situação, porque acredito que ter um bom sistema de log de erros é importante, atualmente nada está sendo usado.

@Jim Blizard: Eu queria tentar me afastar do log/armazenar tudo em algum lugar para voltar e descobrir o que é importante para a situação que causou o erro. Eu não queria cair em sobrecarga de informações sobre o qual Roberto Barros vinculou. Meu método atual de pensar é manter uma string na memória em cada página e, se um erro for destruído, no evento Page_error, pegue essa string e anexe -a à exceção que está sendo registrada. Dessa forma, estou apenas registrando o erro/exceções que ocorreram e armazenando o log de eventos com esse erro. Se nada acontecer, esse registro que estava sendo criado será jogado no balde de um bit para nunca mais ser visto.

@Roberto Barros: Obrigado por esse link, lembro -me de ler em algum lugar, mas esqueci de salvá -lo.

Answer 1

Essa pode não ser a resposta exata que você está procurando, mas por que desenvolver seu próprio mecanismo de log de erros quando há ferramentas poderosas (que você menciona) que lidam com todos esses problemas importantes para você?

Eu posso agradecer que você não tem permissão para instalar software adicional, mas as bibliotecas de registro não são apenas classes como o seu código personalizado? Onde está a diferença fundamental? Eu acho que o tempo gasto se preocupando em implementar uma estrutura de registro pode ser melhor gasto defendendo e fazendo um caso de negócios para uma solução de log decente.

Answer 2

Certa vez, trabalhei para uma agência que não permitiria a instalação de nada que não fosse meu próprio código ou seus objetos (horríveis) com. Se você tiver esse tipo de limitação, veja se pode pegar a fonte do log4net e incluir no seu projeto.

Atualmente, não há nada melhor do que o log4net quando se trata de registro.

Answer 3

Pessoalmente, adotei a seguinte abordagem sobre o registro Erros (e apenas erros de log) em um aplicativo ASP.NET:

• usar protected void Application_Error(object sender, EventArgs e) { Server.Transfer("~/Support/ServerErrorSupport.aspx", true); } (Eu faço um Server.Transfer Para preservar todos os dados post.)

• Gere um ID de erro que seja exclusivo para esse erro (para que os reports subsequentes para o mesmo erro possam ser agrupados). O ID é um hash calculado a partir de uma string concatenada composta por: arquivo, método, linenr e error.message. Recebo os valores de arquivo, método e linenr através de uma regex no StackTrace.

• Eu registro todos os dados a seguir em uma estrutura XML (dependendo do tipo de dados, armazeno o valor de maneira diferente, tipos de valor => tostring (), iserializable => serialize, ...):

  1. MACHINENNAME: Application.Server.MachineName
  2. Physicalroot: Application.server.mappath ("~/")
  3. RequestUrl: Application.request.url.toString ()
  4. Applicationsettings: WebConfigurationManager.AppSettings
  5. ConnectionSettings: WebConfigurationManager.Connectionstrings
  6. Querystring: Application.Request.QueryString
  7. FormPost: Application.request.form
  8. Sessão: Application.Session
  9. Httpheaders: Application.Request.Headers

• Salve a estrutura XML como um arquivo local que contém o ID de erro e um registro de data e hora. Eu escolhi essa abordagem porque:

  • Eu posso enviar o relacionamento (arquivo xml) para mim (durante o teste/depuração muito fácil)
  • Armazene -o localmente ou em um banco de dados durante a produção
  • Como o arquivo é apenas um (despejo para HD), não pode dar muito a dar errado durante a criação do relatório de erro (como uma conexão do servidor, problemas de banco de dados, etc.), apenas verifique se você tem permissões de gravação.
  • Além disso, na página ServerErrorSupport.aspx, depois de salvar o arquivo XML, o usuário obtém a opção de incluir informações extras e adicionar um e -mail para se manter atualizado sobre o progresso em relação ao bug. Isso é anexado ao documento XML.
  • Eu uso um arquivo XSLT para formatar os dados de erro (XML) em um bom relatório de erro.

Answer 4

Para erros, sou um grande fã de registrar muito. Quando as coisas dão errado, a informação é muito valiosa. Eu manteria todo o log em um só lugar (arquivo de texto ou tabela de banco de dados) com um identificador de sessão para agrupar eventos relevantes.

Answer 5

Aqui está o que eu gosto de registrar:

• Nível de erro/depuração (informações, depuração, problema, falha, etc ...)
• Tempo
• texto descritivo (geralmente uma linha)
• traço de pilha (se possível)
• Dados (usuário, sessão, valores variáveis, etc ...)

A maneira mais simples é escrever em um arquivo de texto, mas pode ser bom tê -lo em um banco de dados. Você também pode usar o log de eventos do Windows. Algumas coisas a serem observadas. Hmm ... você precisará limpar seus logs periodicamente.

História engraçada: uma vez que tivemos um logger de erros que registrou o banco de dados, mas tínhamos credenciais ruins de banco de dados que causaram um erro que foi registrado ... acabou sendo transbordado de pilha da recursão (IIRC).