Atualização: para extensões ao System.Diagnostics, fornecendo alguns dos ouvintes que você deseja, consulte Essential.Diagnostics no CodePlex ( http://essentialdiagnostics.codeplex.com/ )
Frameworks
P: Quais estruturas você usa?
R: System.Diagnostics.TraceSource, incorporado ao .NET 2.0.
Ele fornece logs poderosos, flexíveis e de alto desempenho para aplicativos, no entanto, muitos desenvolvedores não estão cientes de seus recursos e não os utilizam totalmente.
Existem algumas áreas em que a funcionalidade adicional é útil ou, às vezes, a funcionalidade existe, mas não está bem documentada; no entanto, isso não significa que toda a estrutura de log (projetada para ser extensível) deve ser descartada e substituída completamente, 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 registro em seu aplicativo e reinventa a roda, apenas estendeu a estrutura System.Diagnostics nos poucos locais em que você precisa.
Parece-me que as outras estruturas, mesmo a EntLib, simplesmente sofrem da Síndrome de Not Invented Here, e acho que perderam tempo reinventando os conceitos básicos que já funcionam perfeitamente bem no System.Diagnostics (como a forma 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 conheça:
- O uso das sobrecargas TraceEvent que usam uma sequência de caracteres de formato e args pode 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 nenhuma chamada cara para ToString () nos valores dos parâmetros até que o sistema confirme que a mensagem será efetivamente 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 oferece suporte à rotação de arquivos. Embora no espaço para nome VisualBasic, ele pode ser usado com a mesma facilidade em um projeto C # (ou outro idioma) simplesmente incluindo a DLL.
- Ao usar EventLogTraceListener se você chamar TraceEvent com vários argumentos e com uma sequência de formato vazia ou nula, os argumentos serão passados diretamente para EventLog.WriteEntry () se você estiver usando recursos de mensagem localizados.
- A ferramenta Service Trace Viewer (do WCF) é útil para visualizar gráficos de arquivos de log correlatos de atividades (mesmo se você não estiver usando o WCF). Isso pode realmente ajudar a depurar problemas complexos em que vários segmentos / atividades estão envolvidos.
- Evite sobrecarga limpando todos os ouvintes (ou removendo o Padrão); caso contrário, o padrão passará tudo para o sistema de rastreamento (e incorrerá em todas as despesas gerais de ToString ()).
Áreas que você pode querer estender (se necessário):
- Ouvinte de rastreamento de banco de dados
- 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 na configuração
Outras Recomendações:
Use IDs de eventos estruturados e mantenha uma lista de referência (por exemplo, documente-os em uma enumeração).
Ter IDs de eventos 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 de evento e pode facilitar a orientação de erros comuns, por exemplo, erro 5178 significa que a cadeia de conexão do banco de dados está incorreta etc.
Os IDs de evento devem seguir algum tipo de estrutura (semelhante à Teoria dos Códigos de Resposta usada no email e HTTP), que permite tratá-los por categoria sem conhecer códigos específicos.
por exemplo, o primeiro dígito pode detalhar a classe geral: 1xxx pode ser usado para operações 'Iniciar', 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 banco de dados (41xx para avisos do banco de dados, 51xx para erros do banco de dados), 22xx para o modo de cálculo (42xx para avisos de cálculo, etc.), 23xx para outro módulo, etc.
Os IDs de eventos estruturados atribuídos também permitem que você os use em filtros.
P: Se você usa o rastreamento, utiliza Trace.Correlation.StartLogicalOperation?
R: Trace.CorrelationManager é muito útil para correlacionar instruções de log em qualquer tipo de ambiente multithread (que é praticamente qualquer coisa hoje em dia).
Você precisa pelo menos definir o ActivityId uma vez para cada operação lógica para correlacionar.
Iniciar / Parar e o LogicalOperationStack podem ser usados para um contexto simples baseado em pilha. Para contextos mais complexos (por exemplo, operações assíncronas), o uso de TraceTransfer para o novo ActivityId (antes de alterá-lo) permite a correlação.
A ferramenta Service Trace Viewer pode ser útil para exibir gráficos 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? Gostaria de compartilhar um trecho de código?
R: Você pode criar uma classe de escopo, por exemplo, LogicalOperationScope, que (a) configura o contexto quando criado e (b) redefine o contexto quando descartado.
Isso permite que você escreva códigos como os seguintes para quebrar 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, chame StartLogicalOperation e, em seguida, registre uma mensagem TraceEventType.Start. Em Dispose, ele pode registrar uma mensagem de parada e, em seguida, chamar StopLogicalOperation.
P: Você fornece alguma forma de granularidade sobre fontes de rastreamento? Por exemplo, o WPF TraceSources permite que você os configure em vários níveis.
R: Sim, várias fontes de rastreamento são úteis / importantes à medida que os sistemas aumentam.
Embora você provavelmente deseje registrar consistentemente todas as mensagens de Aviso e acima, ou Todas as informações e acima, para qualquer sistema de tamanho razoável, o volume de registro de rastreamento de atividades (iniciar, parar etc.) e verboso simplesmente se torna excessivo.
Em vez de ter apenas um comutador que ativa ou desativa tudo, é útil poder ativar essas informações para uma seção do sistema por vez.
Dessa forma, você pode localizar problemas significativos a partir do log normalmente (todos os avisos, erros, etc.) e, em seguida, "aumentar o zoom" nas seções desejadas e configurá-las para os níveis de Rastreamento de Atividade ou mesmo de Depuração.
O número de fontes de rastreamento necessárias depende do seu aplicativo, por exemplo, você pode desejar uma fonte de rastreamento por montagem ou por seção principal do seu aplicativo.
Se você precisar de um controle ainda mais preciso, adicione switches booleanos individuais para ativar / desativar o rastreamento de alto volume específico, por exemplo, descargas brutas de mensagens. (Ou uma fonte de rastreamento separada pode ser usada, semelhante ao WCF / WPF).
Você também pode considerar fontes de rastreio separadas para o rastreamento de atividades versus o registro geral (outros), pois pode facilitar um pouco a configuração dos filtros exatamente como você deseja.
Observe que as mensagens ainda podem ser correlacionadas via ActivityId, mesmo que fontes diferentes sejam usadas, portanto, use quantas você precisar.
Ouvintes
P: Quais saídas de log você usa?
Isso pode depender do tipo de aplicativo que você está escrevendo e do que está sendo registrado. Geralmente coisas diferentes acontecem em lugares diferentes (ou seja, várias saídas).
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 reportar).
Nesse caso, todos os eventos Fatais, Erro, Aviso e Informações (em nível de serviço) devem ir para o Log de Eventos do Windows. O nível de informação deve ser reservado para esse tipo de evento de alto nível, aquele que você deseja exibir no log de eventos, por exemplo, "Serviço iniciado", "Serviço interrompido", "Conectado ao Xyz" e talvez até "Programação iniciada" , "Usuário conectado", etc.
Em alguns casos, convém tornar a gravação no log de eventos uma parte interna do seu aplicativo e não através do sistema de rastreamento (por exemplo, gravar diretamente as entradas do log de eventos). Isso significa que não pode ser desativado 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 os informava ao usuário (embora eles também possam fazer logon no Log de Eventos do Windows).
Os eventos 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 eventos, contadores de desempenho, gravação no sistema de rastreamento e relatórios ao usuário para que eles ocorram em o mesmo tempo.
ou seja, se um usuário vir uma mensagem de erro em um determinado momento, você poderá encontrar a mesma mensagem de erro no log de eventos do Windows e, em seguida, o mesmo evento com o mesmo registro de data e hora no log de rastreamento (junto com outros detalhes de rastreamento).
(2) Atividades - arquivos de log de aplicativo ou tabela de banco de dados (e arquivos de rastreio)
Essa é a atividade regular que um sistema realiza, por exemplo, página da web veiculada, negociação na bolsa de valores, pedido efetuado, cálculo realizado etc.
O rastreamento de atividades (iniciar, parar etc.) é útil aqui (na granualidade correta).
Além disso, é muito comum usar um log de aplicativo específico (às vezes chamado de log de auditoria). Geralmente, esta é uma tabela de banco de dados ou um arquivo de log do aplicativo e contém dados estruturados (ou seja, um conjunto de campos).
As coisas podem ficar um pouco desfocadas 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 sistema de cálculo em que cada operação é registrada juntamente 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 ela possui um importante valor comercial, no entanto, o principal de correlacioná-la com outras ações ainda é importante.
Além de logs de aplicativos personalizados, as atividades também costumam ter contadores de desempenho relacionados, por exemplo, número de transações por segundo.
Em geral, você deve coordenar o log 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 depuração serão mais fáceis (do que se todos ocorrerem em horários / locais diferentes no código).
(3) Rastreio de depuração - arquivo de texto ou talvez XML ou banco de dados.
São informações no nível detalhado e inferior (por exemplo, comutadores booleanos personalizados 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 do seu aplicativo (daí as várias fontes). Você não quer essas coisas bagunçando o Log de Eventos do Windows. Às vezes, um banco de dados é usado, mas é mais provável que estejam rolando arquivos de log que são eliminados após um certo tempo.
Uma grande diferença entre essas informações e um arquivo de log de aplicativos é que elas não são estruturadas. Enquanto um log de aplicativo pode ter campos para, de, quantidade, etc., os rastreamentos de depuração detalhados podem ser o que um programador colocar, por exemplo, "verificando valores X = {valor}, Y = falso" ou comentários / marcadores aleatórios como " Feito isso, tentando novamente ".
Uma prática importante é garantir que as coisas inseridas 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ê planeja usar um visualizador de log específico porque possui uma correlação complexa, por exemplo, o Service Trace Viewer, precisará usar um formato apropriado, por exemplo, XML. Caso contrário, um arquivo de texto simples geralmente é bom o suficiente - nos níveis inferiores, as informações são amplamente desestruturadas, portanto, você pode encontrar despejos de matrizes, despejos de pilha, etc. Desde que você possa se correlacionar com logs mais estruturados em níveis mais altos, as coisas devem fique bem.
P: Se estiver usando arquivos, você usa logs contínuos ou apenas um único arquivo? Como você disponibiliza os logs para as pessoas consumirem?
R: Para arquivos, geralmente você deseja rolar arquivos de log do ponto de vista de capacidade de gerenciamento (com System.Diagnostics, basta usar VisualBasic.Logging.FileLogTraceListener).
A disponibilidade novamente depende do sistema. Se você está falando apenas de arquivos e, em seguida, de 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 acesso).
Se você não tiver acesso fácil ao sistema de arquivos, o rastreamento de depuração em um banco de dados poderá ser mais fácil. [ie implementar um banco de dados TraceListener].
Uma solução interessante que vi para um aplicativo da GUI do Windows foi que ele registrou informações de rastreamento muito detalhadas em um "gravador de vôo" enquanto estava em execução e, em seguida, quando você o desligava se não houvesse problemas, simplesmente excluía o arquivo.
Se, no entanto, travar ou encontrar um problema, o arquivo não será excluído. Se ele detectar o erro, ou na próxima vez em que ele for executado, ele notará o arquivo e poderá executar uma ação, por exemplo, compactá-lo (por exemplo, 7zip) e enviá-lo por e-mail ou disponibilizar.
Atualmente, muitos sistemas incorporam relatórios automatizados de falhas a um servidor central (após verificação com os usuários, por exemplo, por motivos de privacidade).
Visualizando
P: Quais ferramentas você usa para visualizar os logs?
R: Se você tiver vários logs por diferentes motivos, usará vários visualizadores.
O Notepad / vi / Notepad ++ ou qualquer outro editor de texto é o básico para logs de texto sem formatação.
Se você possui operações complexas, por exemplo, atividades com transferências, obviamente usaria uma ferramenta especializada como o Service Trace Viewer. (Mas se você não precisar, 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 ícones de aviso / erro bastante). Você só precisa começar a procurar por arquivos de texto se não houver o suficiente no log, embora pelo menos o log lhe dê um ponto de partida. (Nesse ponto, garantir que seus logs tenham entradas coordenadas se torna útil).
Geralmente, o Registro de Eventos do Windows também disponibiliza esses eventos significativos para ferramentas de monitoramento como MOM ou OpenView.
Outras --
Se você fizer login em um banco de dados, pode ser fácil filtrar e classificar informações (por exemplo, ampliar um ID de atividade específico. (Com arquivos de texto, você pode usar o Grep / PowerShell ou similar para filtrar o GUID particiular que você deseja)
MS Excel (ou outro programa de planilha). Isso pode ser útil para analisar informações estruturadas ou semiestruturadas, se você puder importá-las com os delimitadores certos, para que valores diferentes entrem em colunas diferentes.
Ao executar um serviço em depuração / teste, eu geralmente o hospedo em um aplicativo de console por simplicidade. Acho um logger de console colorido útil (por exemplo, vermelho por erros, amarelo por avisos etc.). Você precisa implementar um ouvinte de rastreamento personalizado.
Observe que a estrutura não inclui um registrador de console colorido ou um registrador de banco de dados; portanto, neste momento, você precisará escrevê-los se precisar deles (não é muito difícil).
Realmente me incomoda que várias estruturas (log4net, EntLib, etc) tenham perdido tempo reinventando a roda e reimplementando o log básico, a filtragem e o log em arquivos de texto, o log de eventos do Windows e arquivos XML, cada um por conta própria maneira diferente (as instruções de log são diferentes em cada uma); cada um implementou sua própria versão de, por exemplo, um criador de logs de banco de dados, quando a maioria já existia e tudo o que era necessário era mais alguns ouvintes de rastreamento do System.Diagnostics. Fale sobre um grande desperdício de esforços duplicados.
P: Se você está criando uma solução ASP.NET, também usa o Monitoramento de integridade do ASP.NET? Você inclui saída de rastreio nos eventos do monitor de integridade? E o Trace.axd?
Essas coisas podem ser ativadas / desativadas conforme necessário. Acho o 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 a longo prazo.
P: E os contadores de desempenho personalizados?
Para um aplicativo profissional, especialmente um servidor / serviço, espero vê-lo totalmente instrumentado com os contadores do Performance Monitor e com o log no Windows Event Log. Essas são as ferramentas padrão do Windows e devem ser usadas.
Você precisa certificar-se de incluir instaladores para os contadores de desempenho e logs de eventos 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).
Esse é um bom motivo para praticar o desenvolvimento como não administrador (tenha uma conta de administrador separada para quando você precisar instalar serviços, etc.). Se gravar no log de eventos, 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 o sistema e não poderá usá-lo porque não está executando como administrador.