Qual é a melhor maneira de gerenciar o log de erros para exceções?

Introdução

Se ocorrer um erro em um site ou sistema, é claro que é útil registrá-lo e mostrar ao usuário uma mensagem educada com um código de referência para o erro.

E se você possui muitos sistemas, não deseja que essas informações sejam distribuídas - é bom ter um único local centralizado para elas.

No nível mais simples, tudo o que é necessário é um ID de incremento e um despejo serializado dos detalhes do erro. (E, possivelmente, o "local centralizado" é uma caixa de entrada de e-mail.)

No outro extremo do espectro, talvez haja um banco de dados totalmente normalizado que também permita que você pressione um botão e veja um gráfico de erros por dia ou identifique qual é o tipo de erro mais comum no sistema X, se o servidor A possui mais banco de dados. erros de conexão que o servidor B e assim por diante.

O que estou me referindo aqui é registrar erros / exceções no nível do código por um sistema remoto - não o rastreamento de problemas "baseado em humanos", como feito com Jira, Trac, etc.

Questões

Estou procurando pensamentos de desenvolvedores que usaram esse tipo de sistema, especificamente com relação a:

• Quais são os recursos essenciais que você não pode prescindir?
• O que é bom ter recursos que realmente economizam seu tempo?
• Quais recursos podem parecer uma boa ideia, mas não são realmente úteis?

Por exemplo, eu diria que uma função "show duplicates" que identifica a ocorrência múltipla de um erro (sem se preocupar com detalhes 'sem importância' que possam diferir) é bastante essencial.
Um botão para "criar um problema no [Jira / etc] para esse erro" parece uma boa economia de tempo.

Apenas para reiterar, o que estou procurando são experiências práticas de pessoas que usaram esses sistemas, de preferência com o motivo pelo qual um recurso é incrível / terrível.
(Se você for teorizar de qualquer maneira, marque no mínimo sua resposta como tal.)

Eu estive em um projeto em que com erros de cliente registrados usando a biblioteca Microsoft Enterprise . Todas as exceções são enviadas para nossa caixa de correio. No assunto do email, adicionamos código hash de erro serializado para evitar mensagens duplicadas. Obviamente, é possível armazenar mensagens serializadas no banco de dados e assim por diante.

Eu recomendo que você verifique a biblioteca Microsoft Enterprise e o Log4Net .

Alguns recursos do Log4Net

• Suporte para várias estruturas
• Saída para vários destinos de log
• Arquitetura de log hierárquica
• Configuração XML
• Configuração Dinâmica
• Contexto de log
• Arquitetura comprovada
• Design modular e extensível • Alto desempenho com flexibilidade

No caso de aplicativos de banco de dados, algum tipo de ID (como <TABLE>:<PrimaryKeyID>) que permite rastrear os registros no banco de dados relacionados ao escopo em que a exceção foi capturada.

Eu fiz isso com Oracle e PL / SQL, gravando o ID em uma tabela de banco de dados dentro do aplicativo, a partir do manipulador de exceções.

Muito do que você descreve (por exemplo, as partes específicas do log) é implementado na biblioteca corporativa, como observou Amir Rezaei. Tudo o resto parece ser mais parte da análise (ou seja, o que fazer com os logs posteriormente).

No meu caso, criei alguns aplicativos pequenos e scripts sql que facilitaram algumas coisas. Aqui estão algumas das coisas que eu realmente gostei:

• O agrupamento dos mesmos erros (por exemplo, 100 usuários experimentaram o mesmo bug ao mesmo tempo é um relatório de bug com uma nota de quantas ocorrências)
• Arquivar automaticamente um ticket no rastreador de caso (nunca conseguiu fazer isso 'com o clique de um botão', mas sempre quis)
• Nome de usuário do usuário do software (não apenas a máquina, disponível na maioria dos registradores). Em alguns casos, as contas de usuário automatizadas causaram problemas, enquanto em outros, usuários específicos foram a causa dos problemas. "Eu preciso assistir Mike fazer algum trabalho, ele continua causando um erro específico."
• "Ações do usuário" - eu tinha uma pilha global que mantinha um rastreamento de cada clique acionável / botão pressionado enquanto o usuário fazia isso, e isso fazia parte dos registros de erros. A reprodução do erro costumava ser o caso de percorrer esse rastreamento e executar as mesmas etapas que o usuário (eu esperava criar um gerador de teste CodedUI que analisasse o rastreamento e executasse as etapas automaticamente, mas nunca o fez).

Às vezes, as informações do log são muito volumosas para serem armazenadas no disco. Uma abordagem que eu vi é escrever suas entradas de log em uma mangueira de incêndio (em, digamos, perl) algo como isto:

# Create socket.
my $sock = IO::Socket::INET->new(
    Proto       => 'udp',
    PeerAddr    => $bcastaddr,
    Broadcast   => 1,
) or die "Can't create socket ($bcastaddr): $!";

while (<>) {
    chomp;
    unless (/File\ does\ not\ exist:/) {
        $sock->send("$eventtype:$_") or warn "Can't send: $!";
    }
}

então um analista pode dar uma olhada no que ele / ela quer ver.

Aqui estão algumas coisas que aprendi com o monitoramento de erros em nossos aplicativos:

• Ser capaz de ajustar um arquivo de log contínuo (geralmente uso log4net / log4j para efetuar logon em aplicativos e o BareTail para seguir o log) é realmente útil para verificar a integridade atual de um sistema
• Para ver quando os problemas foram introduzidos e a taxa na qual os problemas ocorrem, é bom tê-los em um banco de dados com registros de data e hora para que você possa executar relatórios.
• A capacidade de enviar alertas por email / sms / voz é super útil para garantir que os sistemas permaneçam ativos, mas você precisa personalizar com facilidade os tipos de erros que o alertam. Se você receber 800 e-mails de erro por dia, provavelmente perderá o "Ah, não, o data center está pegando fogo".

Eu tive ótimos resultados para o log4net porque facilita muito o log em vários locais e facilita também as alterações na configuração do log.

elmah é um sistema de registro de erros de código aberto para aplicativos ASP.NET e pode ser adicionado a um sistema existente (usando o NuGet http://nuget.codeplex.com/ ) de maneira rápida e fácil. Ele suporta várias funções de back-end e notificação.

Não conheço ninguém que o tenha adicionado a um aplicativo de desktop, pois ele é executado como um site, mas não há nada que impeça você de executá-lo como um serviço e postar suas exceções na Web.

http://code.google.com/p/elmah/

O ELMAH (Módulos e Manipuladores de Registro de Erros) é um recurso de registro de erros em todo o aplicativo que é completamente conectável. Ele pode ser adicionado dinamicamente a um aplicativo Web ASP.NET em execução, ou mesmo a todos os aplicativos Web ASP.NET em uma máquina, sem a necessidade de recompilação ou reimplantação.

Depois que o ELMAH é inserido em um aplicativo Web em execução e configurado adequadamente, você obtém os seguintes recursos sem alterar uma única linha do seu código:

• Registro de quase todas as exceções não tratadas.
• Uma página da web para visualizar remotamente todo o log de exceções recodificadas.
• Uma página da web para exibir remotamente os detalhes completos de qualquer exceção registrada, incluindo rastreamentos de pilha coloridos.
• Em muitos casos, você pode revisar a tela amarela original da morte que o ASP.NET gerou para uma determinada exceção, mesmo com o customErrorsmodo desativado.
• Uma notificação por email de cada erro no momento em que ocorre.
• Um feed RSS dos últimos 15 erros do log ...