Pergunta

Eu atualmente trabalho em uma empresa que tem um monte de aplicativos personalizados que são feitas internamente. No momento não há padrões para um monte de coisas. Eu gostaria de implementar uma forma de erros de gravação / pista que acontecem neste programas (a maioria são asp.net).

Atualmente, estou pensando em lidar com isso no Global.asax no método Erro de aplicativo. Primeira tentativa de salvar as informações em um banco de dados Erro Log / Rastreio, e se isso falhar, tente enviar um e-mail.

Que tipo de informação é o mais útil para começar a partir da mensagem de erro e outras variáveis ??de aplicativo (página, nome de usuário etc).

Atualmente, estou pensando em usar duas tabelas, uma para obter as informações de erro e aplicação geral, e um segundo que contém as informações de exceção. Esta será uma relação um para muitos para entregar as exceções internas que podem vir de exceção nível de uma aplicação.

Estou certo de que eu estou faltando um monte de detalhes e gostaria de ouvir a sua estratégia para lidar com esta questão.

Foi útil?

Solução

Jeff Atwood escreveu um grande manipulador de exceção que você deve olhar em CodeProject

Gostaria de tentar recolher o máximo de informação possível. Informações Stack Informações da sessão Localização de erro

Gostaria também configurar um webservice que os aplicativos chamar para salvar off as informações de exceção em seu sistema.

Outras dicas

ELMAH pode ser o que você está procurando.

Se você usar uma biblioteca de registro (como Log4Net) você pode configurar vários appenders de registro para registrar a e-mail, DB, arquivos, log de eventos, etc, tendo uma única chamada de log em seu código. Este pós cobre tudo que você precisa para começar começado.

Há também ASP.NET saúde monitoramento .

EDIT:. Outra com dossel mencionados ELMAH, o que é ótimo para a gravação de erros do ASP.NET, e podem ser dinamicamente 'injetado' em aplicativos em execução

Isto é o que eu faço, e eu ainda tenho um bug devido a um problema de e-mail.

Eu nunca manter qualquer coisa sobre a DB, porque se o DB tem um erro que eu nunca terá esse erro sobre a causa DB, logicamente, a inserção falhará!

Então, eu e-mail para um endereço de e-mail especial como bugs@mydomain.com

Assunto : [nome do aplicativo] [Time Stamp: ddmmaaaa hhmmss] Mensagem :. Aplicação, mensagem de erro, Pilha informações de rastreamento mais sessão variáveis ??como variáveis ??de nome de usuário e servidor, como Referente

o melhor amigo de um desenvolvedor ASP.NET é informações rastreamento de pilha , é aqui que você vai saber o que deu errado, o que era a chamada e onde estava chamando.

o único problema que você tem neste sistema, é que você não vai conseguir nada se o e-mail tem um problema (alguma exceção ao enviar o e-mail), e por isso eu comecei a adicionar a um arquivo XML mensal [errorLog_ mmm_yyyy.xml] bem e fez um simples "drag-and-drop" página com um gridview que carregou o XML para o mês e ano em que eu queria verificar os erros.

try 
{
   // production code
}
catch(Exception ex)
{
   Utilities.Mail.SendError(ex);
}

ou a melhor maneira: Adicionar-lo para o Application_Error no global:

<%@ Application Language="C#" %>
<%@ Import Namespace="System.Diagnostics" %>
<script language="C#" runat="server">
void Application_Error(object sender, EventArgs e)
{
   //get reference to the source of the exception chain
   Exception ex = Server.GetLastError().GetBaseException();

   //log the details of the exception and page state to the
   //Windows Event Log
   EventLog.WriteEntry("myWebApplication name",
     "MESSAGE: " + ex.Message + 
     "\nSOURCE: " + ex.Source +
     "\nFORM: " + Request.Form.ToString() + 
     "\nQUERYSTRING: " + Request.QueryString.ToString() +
     "\nTARGETSITE: " + ex.TargetSite +
     "\nSTACKTRACE: " + ex.StackTrace, 
     EventLogEntryType.Error);

   Utilities.Mail.SendError(ex);
}
</script>

com o código acima você adicionar o erro no log de eventos, eu anexar o erro para o arquivo XML na função sendError (Exception).

Tenha muito cuidado ao registrar informações potencialmente confidenciais que chegou sobre https. O usuário irá esperar que ele seja end-to-end criptografada (que pode ser um requisito legal). Garantir que você não enviá-lo via e-mail simples.

Normalmente eu diria que registrar todas do pedido incluindo get, post, cookies, estado formulário (em ASPNET), agente do usuário, outros cabeçalhos, data / hora, máquina de servidor etc

Mas, sob alguns casos que resultariam em algum ser informações registradas que você não é suposto permanentemente registro (tais como números de cartão de crédito que está sendo passado para um provedor de pagamento). Enviá-lo por e-mail é ainda pior.

Vale a pena fazer uma verificação se o HTTPS está ligado, e se assim, reduzir a quantidade de informação que você log para evitar este problema. Acabei de enviar através de uma corda para dizer se o campo estava vazio ou não vazio.

Na verdade, soa como você pensou a solução muito bem.

Eu trabalho na loja de desenvolvimento web, por isso, além de registrá erros, eu também certificar-se de que quaisquer erros críticos do sistema, tais como falhando consulta db de e similares também são enviadas para que possamos saltar sobre eles e corrigi-los imediatamente.

Uma alternativa a considerar seria a de enviar e-mail um relatório a cada dia que fornece informações sobre cada erro jogado em cada pedido e qualquer informação relevante que você gostaria no e-mail.

Nós registramos todos os nossos erros em uma única tabela para essa aplicação (é claro que é mais fácil de fazer quando o seu trabalho sobre as aplicações onde os bancos de dados estão todos contidos in-house), incluindo a hora do erro e o texto completo do mensagem de exceção, que também foi enviada por email.

A mensagem de exceção contém uma função trace assim que você sabe o que a função de chamada original, bem como números de arquivo e de linha para todas as funções na pilha. Isso faz back-rastreamento de qualquer bug super simples.

Quando o log para o banco de dados falhar, você pode gravar no log de eventos do servidor, ou para um arquivo Log.txt. Você escolha aqui, em parte, depende se você tem acesso aos servidores da Web que contêm os.

O envio de e-mails de notificação de erro é uma boa idéia se você precisa de uma resposta rápida. Mas não há nenhuma lista dos erros para fazer a varredura através deles.

Eu faço isso através da criação de uma classe de exceção personalizada especial com propriedades, incluindo informações de usuário (ID, nome, se disponível), todas as variáveis ??de sessão, todas as variáveis ??de formulários (assim você pode ver como o formulário foi preenchido e que a utilizador entrou), e algumas indicações além do rastreio da pilha de onde ocorreu o erro (qual a página, que classe, o qual método). Também incluir o nome do procedimento armazenado chamado e os parâmetros enviar, ou o próprio SQL. Além disso todas as propriedades excepção (vestigiais pilha, etc). E campos DisplayMessage e InternalMessage. O DisplayMessage é exibida para o usuário. O InternalMessage é registrado no log, e exibido na página de erro personalizada quando em modo de depuração.

Eu faço o registro no Page_Error na página de base, e como prova de falhas em Application_Error.

Às vezes eu adicionar um par chave-valor em web.config para conter o meu endereço de e-mail (ou uma lista de distribuição). Se houver um vaue nessa chave, um email de notificação é enviada. Se não houver nenhum valor, nenhuma eomail é enviado. Então, durante o teste ou produção precoce, posso obter notificação pessoal imediata do problema. Após o período inicial passa, eu remover o endereço de e-mail em web.config.

logging é bom, mas monitoramento é melhor.

ressalva: eu sou o autor do CALMA

Estávamos frustrados com relatar o erro website aplicações que estavam lá fora, então nós escrevemos a nossa própria em Clearwind Consulting. É grátis e podemos usá-lo internamente para nossos projetos. Ele dá informações de erro completa, como códigos de erro completo, tipo de navegador, rastreamento, um trecho do código que causou o erro, a frequência de erro graficamente mais de 30 dias, e mais. No Clearwind, fazemos o desenvolvimento de aplicações web. Precisávamos de uma ferramenta que nos daria dados reais poderíamos utilizar eficientemente sobre os nossos websites.

Você pode escolher a forma de receber uma notificação de quando o seu site dá um erro. RSS, e-mail, ou qualquer método que funciona melhor para você tudo pode ser usado para obter notificações de erro. E sim, você pode enviar os erros para o seu iPhone, enquanto você está tendo uma bebida. É totalmente escrito em Django para que você possa usar JSON, RoR, XML, CSV, etc., se você deseja tag ou formatar seus dados. Ou apenas vir para o site.

Se você gosta, olhada www.areciboapp.com.

É grátis, facilmente adicionados (ou removidos) qualquer site e dá a informação real para que você possa corrigir os erros, em vez de apenas um 404. Não difícil vender aqui. Apenas um convite para vir dar uma olhada e ver se ele pode ajudar você e seu website. Nós pensamos que poderia.

É uma boa idéia bastante para logar em um log de eventos personalizado no servidor, bem como qualquer outra exploração madeireira e notificação. Se o erro foi causado por um problema de infra-estrutura, o mesmo problema também pode manter o manipulador de erro de envio de e-mails ou salvar em um banco de dados.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top