Registrando as melhores práticas

Gostaria de obter histórias sobre como as pessoas estão manipulando o rastreamento e o registro em aplicativos reais. Aqui estão algumas perguntas que podem ajudar a explicar sua resposta.

Frameworks

Quais frameworks você usa?

  • log4net
  • System.Diagnostics.Trace
  • System.Diagnostics.TraceSource
  • Bloco de aplicação de log
  • De outros?

Se você usar o rastreamento, você faz uso de Trace.Correlation.StartLogicalOperation?

Você escreve este código manualmente ou usa algum tipo de programação orientada a aspectos para fazer isso? Cuidados para compartilhar um trecho de código?

Você fornece alguma forma de granularidade sobre fonts de rastreamento? Por exemplo, o WPF TraceSources permite configurá-los em vários níveis:

  • System.Windows – configurações para todo o WPF
  • System.Windows.Animation – anular especificamente para Animação.

Ouvintes

Quais saídas de log você usa?

  • Arquivos de texto
  • Arquivos XML
  • Log de events
  • De outros?

Se estiver usando arquivos, você usa logs de rolagem ou apenas um único arquivo? Como você disponibiliza os logs para as pessoas consumirem?

Visualizar

Quais ferramentas você usa para visualizar os logs?

  • Bloco de annotations
  • Rabo
  • Visualizador de events
  • Gerente de Operações do System Center / Microsoft Operations Manager
  • Visualizador de rastreio do serviço WCF
  • De outros?

Se você está construindo uma solução ASP.NET, você também usa o ASP.NET Health Monitoring? Você inclui saída de rastreamento nos events do monitor de integridade? E quanto ao Trace.axd?

E quanto aos contadores de desempenho personalizados?


Atualização: para extensões para System.Diagnostics, fornecendo alguns dos ouvintes ausentes que você pode desejar, consulte Essential.Diagnostics on CodePlex ( http://essentialdiagnostics.codeplex.com/ )


Frameworks

P: Quais frameworks você usa?

A: System.Diagnostics.TraceSource, incorporado ao .NET 2.0.

Ele fornece registros poderosos, flexíveis e de alto desempenho para aplicativos, no entanto muitos desenvolvedores não estão cientes de suas capacidades e não fazem uso total deles.

Existem algumas áreas onde funcionalidade adicional é útil, ou algumas vezes a funcionalidade existe mas não está bem documentada, entretanto isso não significa que toda a estrutura de logging (que é projetada para ser extensível) deve ser descartada e completamente substituída como algumas alternativas populares (NLog, log4net, Common.Logging e até mesmo EntLib Logging).

Em vez de alterar a maneira como você adiciona instruções de criação de log ao seu aplicativo e reinventa a roda, apenas estenda a estrutura System.Diagnostics nos poucos locais em que você precisa.

Parece-me que os outros frameworks, até mesmo o EntLib, simplesmente sofrem da síndrome de não inventado aqui, e eu acho que eles perderam tempo reinventando o básico que já funciona perfeitamente bem em System.Diagnostics (por exemplo, como você escreve instruções de log), em vez de preencher as poucas lacunas existentes. Em resumo, não os use – eles não são necessários.

Recursos que você talvez não saiba:

  • Usar as sobrecargas do TraceEvent que usam uma string de formato e argumentos podem ajudar no desempenho, pois os parâmetros são mantidos como referências separadas até que o Filter.ShouldTrace () tenha sido bem-sucedido. Isso significa que não há chamadas caras para ToString () nos valores dos parâmetros até que o sistema tenha confirmado que a mensagem realmente será registrada.
  • O Trace.CorrelationManager permite correlacionar instruções de log sobre a mesma operação lógica (veja abaixo).
  • VisualBasic.Logging.FileLogTraceListener é bom para gravar arquivos de log e suporta a rotação de arquivos. Embora no namespace VisualBasic, ele pode ser facilmente usado em um projeto C # (ou outra linguagem) simplesmente incluindo a DLL.
  • Ao usar EventLogTraceListener, se você chamar TraceEvent com vários argumentos e com uma string de formato vazia ou nula, os argumentos serão passados ​​diretamente para o EventLog.WriteEntry () se você estiver usando resources de mensagens localizados.
  • A ferramenta Service Trace Viewer (do WCF) é útil para visualizar charts de arquivos de log correlacionados com a atividade (mesmo se você não estiver usando o WCF). Isso pode realmente ajudar a depurar problemas complexos onde vários threads / atividades estão envolvidos.
  • Evite sobrecarga, limpando todos os ouvintes (ou removendo o padrão); caso contrário, o Padrão transmitirá tudo para o sistema de rastreio (e incorrerá em todas as despesas gerais do ToString ()).

Áreas que você pode querer examinar (se necessário):

  • Ouvinte de rastreamento do database
  • Ouvinte de rastreamento do console colorido
  • Ouvintes de rastreamento MSMQ / Email / WMI (se necessário)
  • Implemente um FileSystemWatcher para chamar Trace.Refresh para alterações dinâmicas de configuração

Outras Recomendações:

Use ids de events estruturados e mantenha uma lista de referências (por exemplo, documente-os em um enum).

Ter IDs de events exclusivos para cada evento (significativo) em seu sistema é muito útil para correlacionar e encontrar problemas específicos. É fácil rastrear o código específico que registra / usa os IDs do evento e pode facilitar o fornecimento de orientação para erros comuns, por exemplo, erro 5178 significa que a cadeia de conexão do database está incorreta etc.

Os IDs de evento devem seguir algum tipo de estrutura (semelhante à Teoria dos códigos de resposta usados ​​em email e HTTP), que permite tratá-los por categoria sem conhecer códigos específicos.

Por exemplo, o primeiro dígito pode detalhar a class geral: 1xxx pode ser usado para operações ‘Start’, 2xxx para comportamento normal, 3xxx para rastreamento de atividades, 4xxx para avisos, 5xxx para erros, 8xxx para operações ‘Stop’, 9xxx para erros fatais, etc.

O segundo dígito pode detalhar a área, por exemplo, 21xx para informações do database (41xx para avisos de database, 51xx para erros de database), 22xx para modo de cálculo (42xx para avisos de cálculo, etc), 23xx para outro módulo etc.

Ids de events estruturados e designados também permitem que você os use em filtros.

P: Se você usar o rastreamento, você faz uso do Trace.Correlation.StartLogicalOperation?

R: Trace.CorrelationManager é muito útil para correlacionar instruções de log em qualquer tipo de ambiente multi-thread (o que é praticamente qualquer coisa atualmente).

Você precisa pelo menos definir o ActivityId uma vez para cada operação lógica para poder correlacionar.

Iniciar / Parar e o LogicalOperationStack pode ser usado para contexto simples baseado em pilha. Para contextos mais complexos (por exemplo, operações assíncronas), o uso do TraceTransfer para o novo ActivityId (antes de alterá-lo) permite a correlação.

A ferramenta Service Trace Viewer pode ser útil para visualizar charts de atividades (mesmo se você não estiver usando o WCF).

P: Você escreve esse código manualmente ou usa alguma forma de programação orientada a aspectos para fazer isso? Cuidados para compartilhar um trecho de código?

R: Você pode querer criar uma class de escopo, por exemplo, LogicalOperationScope, que (a) configura o contexto quando criado e (b) redefine o contexto quando descartado.

Isso permite que você escreva um código como o seguinte para agrupar automaticamente as operações:

using( LogicalOperationScope operation = new LogicalOperationScope("Operation") ) { // .. do work here } 

Na criação, o escopo pode primeiro definir ActivityId, se necessário, chamar StartLogicalOperation e, em seguida, registrar uma mensagem TraceEventType.Start. Em Dispose, pode registrar uma mensagem de parada e, em seguida, chamar StopLogicalOperation.

P: Você fornece alguma forma de granularidade sobre fonts de rastreamento? Por exemplo, o WPF TraceSources permite que você os configure em vários níveis.

R: Sim, várias origens de rastreamento são úteis / importantes à medida que os sistemas aumentam.

Embora você provavelmente deseje sempre registrar todos os avisos & acima, ou todas as informações e mensagens acima, para qualquer sistema de tamanho razoável, o volume de Rastreamento de Atividades (Início, Parada, etc) e Registro Detalhado simplesmente se torna excessivo.

Em vez de ter apenas um comutador que liga ou desliga, é útil poder ativar essas informações para uma seção do sistema por vez.

Dessa forma, você pode localizar problemas significativos do log geralmente (todos os avisos, erros, etc.) e, em seguida, “aumentar o zoom” nas seções desejadas e configurá-los para Rastreamento de atividade ou até mesmo níveis de Depuração.

O número de fonts de rastreamento de que você precisa depende do seu aplicativo, por exemplo, você pode querer uma origem de rastreamento por assembly ou por seção principal de seu aplicativo.

Se você precisar de um controle ainda mais preciso, adicione switches booleanos individuais para ativar / desativar o rastreamento específico de alto volume, por exemplo, despejos de mensagens brutas. (Ou uma fonte de rastreamento separada pode ser usada, semelhante ao WCF / WPF).

Você também pode querer considerar origens de rastreamento separadas para Rastreamento de Atividades versus registro geral (outro), pois pode tornar um pouco mais fácil configurar os filtros exatamente como você deseja.

Observe que as mensagens ainda podem ser correlacionadas via ActivityId, mesmo que diferentes fonts sejam usadas, portanto, use quantas forem necessárias.


Ouvintes

P: Quais saídas de log você usa?

Isso pode depender do tipo de aplicativo que você está escrevendo e de quais coisas estão sendo registradas. Geralmente, coisas diferentes acontecem em lugares diferentes (isto é, múltiplas saídas).

Eu geralmente classifico as saídas em três grupos:

(1) Eventos – Log de Eventos do Windows (e arquivos de rastreamento)

Por exemplo, se estiver escrevendo um servidor / serviço, a melhor prática no Windows é usar o Log de Eventos do Windows (você não tem uma interface do usuário para relatar).

Nesse caso, todos os events de Informações Fatais, Erro, Aviso e (nível de serviço) devem ir para o Log de Eventos do Windows. O nível de Informações deve ser reservado para esses tipos de events de alto nível, aqueles que você deseja ir no log de events, por exemplo, “Serviço Iniciado”, “Serviço Interrompido”, “Conectado ao Xyz” e talvez até “Programado Iniciado” , “Usuário logado em”, etc.

Em alguns casos, talvez você queira tornar a gravação no log de events uma parte interna de seu aplicativo e não através do sistema de rastreio (isto é, gravar inputs do Log de Eventos diretamente). Isso significa que não pode ser desligado acidentalmente. (Observe que você também deseja observar o mesmo evento em seu sistema de rastreio para poder correlacionar).

Por outro lado, um aplicativo GUI do Windows geralmente relataria isso ao usuário (embora eles também possam efetuar login no log de events do Windows).

Os events também podem ter contadores de desempenho relacionados (por exemplo, número de erros / s) e pode ser importante coordenar qualquer gravação direta no log de events, contadores de desempenho, gravação no sistema de rastreamento e relatório para o usuário, para que eles ocorram em o mesmo tempo.

Por exemplo, se um usuário vir uma mensagem de erro em um horário específico, você poderá encontrar a mesma mensagem de erro no Log de Eventos do Windows e o mesmo evento com o mesmo registro de data e hora (junto com outros detalhes de rastreio).

(2) Atividades – Arquivos de Log do Aplicativo ou tabela de database (e arquivos de rastreio)

Esta é a atividade regular que um sistema faz, por exemplo, página da web servida, comércio do mercado de ações apresentado, ordem tomada, cálculo executado, etc.

O Rastreamento de Atividades (iniciar, parar, etc) é útil aqui (na granularidade correta).

Além disso, é muito comum usar um log de aplicativo específico (às vezes chamado de log de auditoria). Normalmente, isso é uma tabela de database ou um arquivo de log de aplicativo e contém dados estruturados (ou seja, um conjunto de campos).

As coisas podem ficar um pouco borradas aqui, dependendo da sua aplicação. Um bom exemplo pode ser um servidor da web que grava cada solicitação em um log da web; exemplos semelhantes podem ser um sistema de mensagens ou um sistema de cálculo em que cada operação é registrada junto com detalhes específicos do aplicativo.

Um exemplo não tão bom é o mercado de ações ou um sistema de pedidos de vendas. Nesses sistemas, você provavelmente já está registrando a atividade, pois eles têm um importante valor comercial, no entanto, o principal de correlacioná-los com outras ações ainda é importante.

Assim como os logs de aplicativos personalizados, as atividades também costumam ter contadores de desempenho relacionados, por exemplo, número de transactions por segundo.

Em geral, você deve coordenar o registro de atividades em diferentes sistemas, ou seja, gravar no log do aplicativo ao mesmo tempo em que aumenta o contador de desempenho e registra no sistema de rastreamento. Se você fizer tudo ao mesmo tempo (ou logo após o outro no código), os problemas de debugging serão mais fáceis (do que se todos ocorrerem em tempos / locais diferentes no código).

(3) Debug Trace – arquivo de texto, ou talvez XML ou database.

Esta é a informação em nível detalhado e inferior (por exemplo, opções booleanas personalizadas para ativar / desativar despejos de dados brutos). Isso fornece as entranhas ou detalhes do que um sistema está fazendo em um nível de subatividade.

Este é o nível que você deseja ativar / desativar para seções individuais de sua aplicação (daí as múltiplas fonts). Você não quer que esse material atravesse o log de events do Windows. Às vezes, um database é usado, mas é mais provável que os arquivos de log sejam removidos após um determinado período.

Uma grande diferença entre essas informações e um arquivo de log do aplicativo é que ele não é estruturado. Embora um Log de Aplicativo possa ter campos para Para, De, Quantidade etc., os rastreamentos de debugging detalhados podem ser o que um programador colocar, por exemplo, “verificando valores X = {valor}, Y = falso” ou comentários / marcadores randoms como ” Feito isso, tentando de novo “.

Uma prática importante é garantir que as coisas que você coloca nos arquivos de log do aplicativo ou no Log de Eventos do Windows também sejam registradas no sistema de rastreamento com os mesmos detalhes (por exemplo, registro de data e hora). Isso permite correlacionar os diferentes logs ao investigar.

Se você está planejando usar um visualizador de log em particular, porque você tem uma correlação complexa, por exemplo, o Service Trace Viewer, então você precisa usar um formato apropriado, ou seja, XML. Caso contrário, um arquivo de texto simples geralmente é bom o suficiente – nos níveis inferiores a informação é em grande parte não estruturada, então você pode encontrar lixeiras de matrizes, despejos de pilha, etc. fique bem.

P: Se estiver usando arquivos, você usa logs de rolagem ou apenas um único arquivo? Como você disponibiliza os logs para as pessoas consumirem?

R: Para arquivos, geralmente você deseja mover arquivos de log do ponto de vista de gerenciamento (com System.Diagnostics, simplesmente use VisualBasic.Logging.FileLogTraceListener).

Disponibilidade novamente depende do sistema. Se você está falando apenas de arquivos, então, para um servidor / serviço, os arquivos contínuos podem ser acessados ​​apenas quando necessário. (Log de Eventos do Windows ou Logs de Aplicativos de Banco de Dados teriam seus próprios mecanismos de access).

Se você não tiver access fácil ao sistema de arquivos, o rastreamento de debugging para um database poderá ser mais fácil. [ou seja, implementar um database TraceListener].

Uma solução interessante que eu vi para uma aplicação Windows GUI foi que ele registrou informações de rastreamento muito detalhadas para um “gravador de vôo” durante a execução e, em seguida, quando você desligá-lo se não tivesse problemas, simplesmente apagou o arquivo.

Se, no entanto, ele caiu ou encontrou um problema, então o arquivo não foi excluído. Ou se ele detectar o erro ou na próxima vez que ele for executado, ele observará o arquivo e, em seguida, poderá executar uma ação, por exemplo, compactá-lo (por exemplo, 7zip), enviá-lo por e-mail ou disponibilizá-lo.

Atualmente, muitos sistemas incorporam relatórios automatizados de falhas em um servidor central (após a verificação com os usuários, por exemplo, por questões de privacidade).


Visualizar

P: Quais ferramentas você usa para visualizar os logs?

R: Se você tiver vários registros por motivos diferentes, você usará vários visualizadores.

Notepad / vi / Notepad ++ ou qualquer outro editor de texto é o básico para logs de texto simples.

Se você tem operações complexas, por exemplo, atividades com transferências, então, obviamente, você usaria uma ferramenta especializada como o Service Trace Viewer. (Mas se você não precisa, então um editor de texto é mais fácil).

Como geralmente registro informações de alto nível no Log de Eventos do Windows, ele fornece uma maneira rápida de obter uma visão geral, de maneira estruturada (procure os icons de erro / aviso). Você só precisa começar a procurar arquivos de texto se não houver o suficiente no log, embora pelo menos o log forneça um ponto inicial. (Neste ponto, certificar-se de que seus registros tenham inputs coordenadas se torna útil).

Geralmente, o Log de Eventos do Windows também disponibiliza esses events significativos para ferramentas de monitoramento, como o MOM ou o OpenView.

Outras —

Se você logar em um database, pode ser fácil filtrar e ordenar informações (por exemplo, aumentar o zoom em um determinado ID de atividade. (Com arquivos de texto, você pode usar o Grep / PowerShell ou semelhante ao filtro no GUI particular desejado)

MS Excel (ou outro programa de planilha eletrônica). Isso pode ser útil para analisar informações estruturadas ou semiestruturadas, se você puder importá-las com os delimitadores corretos para que valores diferentes entrem em colunas diferentes.

Ao executar um serviço em debug / test, geralmente o hospedo em um aplicativo de console para simplificar, eu acho útil um logger de console colorido (por exemplo, vermelho para erros, amarelo para avisos, etc). Você precisa implementar um ouvinte de rastreamento personalizado.

Note que o framework não inclui um logger de console colorido ou um logger de database, então, agora, você precisaria escrevê-los se precisar deles (não é muito difícil).

É realmente irritante que vários frameworks (log4net, EntLib, etc) tenham perdido tempo reinventando a roda e reimplementado o log básico, filtragem e registro em arquivos de texto, o log de events do Windows e arquivos XML, cada um em seu próprio maneira diferente (instruções de log são diferentes em cada); cada um deles implementou sua própria versão de, por exemplo, um registrador de database, quando a maioria já existia e tudo o que era necessário era mais alguns ouvintes de rastreamento para System.Diagnostics. Fale sobre um grande desperdício de esforço duplicado.

P: Se você está criando uma solução ASP.NET, você também usa o ASP.NET Health Monitoring? Você inclui saída de rastreamento nos events do monitor de integridade? E quanto ao Trace.axd?

Essas coisas podem ser ativadas / desativadas conforme necessário. Acho Trace.axd bastante útil para depurar como um servidor responde a certas coisas, mas geralmente não é útil em um ambiente muito usado ou para rastreamento de longo prazo.

P: E quanto aos contadores de desempenho personalizados?

Para um aplicativo profissional, especialmente um servidor / serviço, espero vê-lo totalmente instrumentado com os dois contadores do Monitor de desempenho e registrando no log de events do Windows. Estas são as ferramentas padrão no Windows e devem ser usadas.

Você precisa ter certeza de include instaladores para os contadores de desempenho e logs de events que você usa; estes devem ser criados no momento da instalação (ao instalar como administrador). Quando seu aplicativo está sendo executado normalmente, ele não precisa ter privilégios de administração (e, portanto, não poderá criar logs ausentes).

Este é um bom motivo para praticar o desenvolvimento como um não administrador (ter uma conta de administrador separada para quando você precisar instalar serviços, etc). Se estiver escrevendo no log de events, o .NET criará automaticamente um log ausente na primeira vez que você gravar nele; Se você se tornar um não-administrador, perceberá isso cedo e evitará uma surpresa desagradável quando um cliente instalar seu sistema e não puder usá-lo porque ele não está sendo executado como administrador.

Eu tenho que participar do coro recomendando o log4net, no meu caso vindo de um ponto de vista de flexibilidade de plataforma (desktop .Net / Compact Framework, 32/64 bits).

No entanto, envolvê-lo em uma API de label privado é um grande anti-padrão . log4net.ILogger é a contraparte .Net da API do wrapper do Commons Logging , portanto, o acoplamento já está minimizado para você e, como também é uma biblioteca Apache, geralmente não é uma preocupação, porque você não está desistindo de nenhum controle: fork se você precisar.

A maioria das bibliotecas de invólucros de casas que vi também comete uma ou mais de uma ladainha de falhas:

  1. Uso de um registrador singleton global (ou equivalente a um ponto de input estático) que perde a resolução fina do padrão recomendado de registrador por class para nenhum outro ganho de seletividade.
  2. Falha ao expor o argumento de Exception opcional , levando a vários problemas:
    • Isso torna uma diretiva de log de exceções ainda mais difícil de manter, portanto, nada é feito consistentemente com exceções.
    • Mesmo com uma política consistente, a formatação da exceção em uma string perde os dados prematuramente. Escrevi um decorador de ILayout customizado que executa drill down detalhado em uma exceção para determinar a cadeia de events.
  3. Falha ao expor as propriedades Is Level Enabled , que descarta a capacidade de ignorar o código de formatação quando as áreas ou níveis de log estão desativados.

Eu não desenvolvo frequentemente no asp.net, no entanto quando se trata de loggers eu acho que muitas das melhores práticas são universais. Aqui estão alguns dos meus pensamentos randoms sobre registro que aprendi ao longo dos anos:

Frameworks

  • Use uma estrutura de abstração do criador de logs – como o slf4j (ou faça o seu próprio), para que você desvincule a implementação do criador de logs da sua API. Eu vi um número de estruturas de logger vêm e vão e você é melhor poder adotar um novo sem muita trabalheira.
  • Tente encontrar uma estrutura que suporte uma variedade de formatos de saída.
  • Tente encontrar uma estrutura que suporte plug-ins / filtros personalizados.
  • Use uma estrutura que pode ser configurada por arquivos externos, para que seus clientes / consumidores possam ajustar a saída do log com facilidade, para que possam ser lidos com facilidade por aplicativos comerciais de gerenciamento de logs.
  • Certifique-se de não exagerar nos níveis de criação de log personalizados, caso contrário, você não poderá mover para diferentes estruturas de criação de log.

Saída do logger

  • Tente evitar logs de estilo XML / RSS para log que podem encontrar falhas catastróficas. Isso é importante porque, se a chave liga / desliga for desligada sem que seu registrador escreva a tag fechamento, seu log está quebrado.
  • Tópicos de log. Caso contrário, pode ser muito difícil rastrear o stream do seu programa.
  • Se você tiver que internacionalizar seus logs, você pode querer que um desenvolvedor faça login apenas em inglês (ou no idioma de sua escolha).
  • Às vezes, ter a opção de inserir instruções de registro em consultas SQL pode ser um salva-vidas em situações de debugging. Tal como:
  - Invocando a class: com.foocorp.foopackage.FooClass: 9021
     SELECT * FROM foo; 
  • Você deseja log de nível de class. Você normalmente não quer instâncias estáticas de registradores também – não vale a pena a micro-otimização.
  • Marcar e categorizar exceções registradas é, às vezes, útil porque nem todas as exceções são criadas iguais. Portanto, conhecer um subconjunto de exceções importantes é útil se você tiver um monitor de log que precisa enviar notifications sobre estados críticos.
  • Os filtros de duplicação salvam sua visão e seu disco rígido. Você realmente quer ver a mesma declaração repetida 10 ^ 10000000 vezes? Não seria melhor apenas receber uma mensagem como: This is my logging statement - Repeated 100 times

Veja também esta questão minha .

Eu não estou qualificado para comentar sobre a criação de log para .Net, já que meu pão com manteiga é Java, mas nós tivemos uma migration em nosso log nos últimos 8 anos, você pode encontrar uma analogia útil à sua pergunta.

Começamos com um registrador Singleton que foi usado por cada encadeamento dentro da JVM e definimos o nível de registro para todo o processo. Isso resultou em enormes logs se tivéssemos que depurar até mesmo uma parte muito específica do sistema, então a lição número um é segmentar seu registro.

Nossa atual encarnação do logger permite múltiplas instâncias com uma definida como padrão. Podemos instanciar qualquer número de registradores-filhos que possuam diferentes níveis de registro, mas a faceta mais útil dessa arquitetura é a capacidade de criar registradores para pacotes e classs individuais simplesmente alterando as propriedades de registro. A segunda lição é criar um sistema flexível que permita replace seu comportamento sem alterar o código.

Estamos usando a biblioteca Apache commons-logging envolvida em torno de Log4J.

Espero que isto ajude!

* Editar *

Depois de ler o post de Jeffrey Hantin abaixo, percebi que deveria ter notado o que nosso wrapper de registro interno realmente se tornou. Agora é essencialmente uma fábrica e é estritamente usado para obter um logger de trabalho usando o arquivo de propriedades correto (que, por motivos legados, não foi movido para a posição padrão). Desde que você pode especificar o arquivo de configuração de registro na linha de comando agora, eu suspeito que ele se tornará ainda mais enxuto e se você estiver iniciando um novo aplicativo, eu definitivamente concordaria com a afirmação dele de que você não deveria se preocupar em empacotar o registrador.

Usamos o Log4Net no trabalho como o provedor de logging, com um wrapper singleton para a instância de log (embora o singleton esteja sob revisão, questionando se eles são uma boa ideia ou não).

Nós escolhemos pelas seguintes razões:

  • Configuração / reconfiguração simples em vários ambientes
  • Bom número de anexadores pré-construídos
  • Um dos CMS’s que usamos já o construiu
  • Bom número de níveis de log e configurações em torno deles

Devo mencionar, isso está falando de um ponto de vista de desenvolvimento do ASP.NET

Eu posso ver alguns méritos no uso do Trace que está no .NET framework, mas eu não estou totalmente vendido nele, principalmente porque os componentes com os quais eu trabalho realmente não fazem chamadas de Trace. A única coisa que eu uso freqüentemente que faz é System.Net.Mail do que eu posso dizer.

Então nós temos uma biblioteca que envolve o log4net e dentro do nosso código nós só precisamos de coisas como esta:

 Logger.Instance.Warn("Something to warn about"); Logger.Instance.Fatal("Something went bad!", new Exception()); try { var i = int.Parse("Hello World"); } catch(FormatException, ex) { Logger.Instance.Error(ex); } 

Nos methods, verificamos se o nível de log está ativado, para que você não tenha chamadas redundantes para a API log4net (portanto, se a debugging não estiver ativada, as instruções de debugging serão ignoradas), mas quando eu tiver algum tempo Vou atualizá-lo para expor aqueles para que você possa fazer os testes sozinho. Isso evitará que avaliações sejam realizadas quando não deveriam, por exemplo:

 Logger.Instance.Debug(string.Format("Something to debug at {0}", DateTime.Now); 

Isso vai se tornar:

 if(Logger.DebugEnabled) Logger.Instance.Debug(string.Format("Something to debug at {0}", DateTime.Now); 

(Salve um pouco do tempo de execução)

Por padrão, registramos em dois locais:

  1. Sistema de arquivos do site (em uma extensão de arquivo não atendida)
  2. Envio de email para erro e fatal

Os arquivos são feitos como rolagem de cada dia ou 10mb (IIRC). Nós não usamos o EventLog, pois pode exigir maior segurança do que muitas vezes queremos dar a um site.

Acho Notepad funciona muito bem para ler logs.

Quais frameworks você usa?

Usamos uma mistura do bloco de aplicativo de registro e um auxiliar de registro customizado que funciona em torno dos bits do framework .Net. O LAB é configurado para gerar arquivos de log bastante extensos, incluindo arquivos de rastreamento gerais separados para input / saída do método de serviço e arquivos de erro específicos para problemas inesperados. A configuração inclui data / hora, encadeamento, pId etc. para assistência de debugging, bem como detalhes completos da exceção e pilha (no caso de uma exceção inesperada).

O auxiliar de criação de log personalizado faz uso do Trace.Correlation e é particularmente útil no contexto de criação de log no WF. Por exemplo, temos uma máquina de estado que invoca uma série de streams de trabalho sequenciais. Em cada uma dessas atividades de chamada, registramos o início (usando StartLogicalOperation) e, no final, interrompemos a operação lógica com um manipulador de events de retorno gererico.

Isto provou ser útil algumas vezes ao tentar depurar falhas em sequências de negócios complexas, pois nos permite determinar coisas como Decisões de ramificação If / Else, etc. mais rapidamente com base na sequência de execução da atividade.

Quais saídas de log você usa?

Nós usamos arquivos de texto e arquivos XML. Arquivos de texto são configurados através do bloco de aplicativos, mas também temos saídas XML do nosso serviço WF. Isso nos permite capturar os events de tempo de execução (persistência etc.), bem como as exceções genéricas de tipo de negócio. Os arquivos de texto estão rolando logs que são rolados por dia e tamanho (acredito que o tamanho total de 1MB é um ponto de rollover).

Quais ferramentas você usa para visualizar os logs?

Estamos usando o Notepad e o WCF Service Trace Viewer, dependendo de qual grupo de saída estamos analisando. O WCF Service Trace Viewer é realmente muito útil se você tiver a configuração de saída correta e puder tornar a leitura da saída muito mais simples. Dito isso, se eu souber mais ou menos onde está o erro, basta ler um arquivo de texto bem anotado.

Os logs são enviados para um único diretório, que é então dividido em sub-diretórios com base no serviço de origem. O diretório raiz é exposto através de um site que tem seu access controlado por um grupo de usuários de suporte. Isso nos permite dar uma olhada nos logs de produção sem ter que fazer solicitações e passar por longos processos de burocracia para os dados de produção.

Como autores da ferramenta, é claro que usamos o SmartInspect para registrar e rastrear aplicativos .NET. Geralmente, usamos o protocolo de pipe nomeado para logs ativos e arquivos de log binários (criptografados) para logs de usuários finais. Usamos o SmartInspect Console como o visualizador e a ferramenta de monitoramento.

Na verdade, existem alguns frameworks e ferramentas de logging para o .NET. Há uma visão geral e comparação das diferentes ferramentas no DotNetLogging.com .

Existem muitas ótimas recomendações nas respostas.

Uma prática recomendada geral é considerar quem lerá o log. No meu caso, será um administrador no site do cliente. Então, eu faço o log de mensagens que lhes dão algo em que podem agir. Por exemplo, “não é possível inicializar o aplicativo. Isso geralmente é causado por ……”

Nós usamos o log4net em nossos aplicativos da web.

A capacidade de personalizar o registro em tempo de execução, alterando o arquivo de configuração XML, é muito útil quando um aplicativo não está funcionando corretamente em tempo de execução e você precisa ver mais informações.

Ele também permite que você direcione classs ou atributos específicos para efetuar logon. Isso é muito útil quando você tem uma ideia de onde o erro está ocorrendo. Um exemplo clássico é o NHibernate, onde você quer ver apenas o SQL indo para o database.

Editar:

Nós escrevemos todos os events em um database e no sistema Trace. O log de events que usamos para erros ou exceções. Registramos a maioria dos events em um database para que possamos criar relatórios personalizados e permitir que os usuários visualizem o log se quiserem direto do aplicativo.

No que diz respeito ao logging orientado a aspectos, eu recomendei o PostSharp a outra pergunta SO –

Registro Orientado a Aspectos com Unity \ T4 \ else else

O link fornecido na resposta vale a pena ser visitado se você estiver avaliando estruturas de registro.