Logging Framework, uma boa idéia?

Question

Em primeiro lugar, desculpas para o título soando subjetiva. Este destina-se como uma pergunta direta.

No momento eu estou trabalhando em um conjunto de ferramentas:

• A C # Windows Service, para primariamente manter um banco de dados Oracle.
• A C # Windows Service, (que será usado em vários sites de nó) para conteúdo processo do banco de dados.
• Uma interface web ASP.NET para facilitar a gestão da geral "Sistema"

Atualmente, o tho Windows Services foram desenvolvidos como aplicações da consola (para facilitar a depuração / desenvolvimento) e eu estou no meio de converter estes para Services. Depois de testar por alguns dias agora com estes serviços, eu estou achando que eu gostaria de aumentar a granularidade do meu registro. Eu estou achando que eu sinto falta Console.WriteLine () e eu gostaria de fornecer uma fonte de log alternativo como um arquivo simples para este tipo de saída. Isso me levou a pensar: "Eu deveria estar usando um quadro, ou que eu tenho o suficiente?"

A razão de eu ter mencionado os aspectos que estou desenvolvendo é o de proporcionar uma visão para a minha situação. A DLL "core" foi criado, comum em todos os componentes, abstrair a camada de interação entre as aplicações e banco de dados. É dentro deste DLL que uma classe foi criada, que tentará "log para uma tabela no banco de dados" else em falhar "log para log de eventos local". É isso, essa é a extensão do registro.

Ao longo das ferramentas acima mencionadas, existem várias instâncias de login não muito diferente:

Log.LogError("Code", e.Message + "\n" + e.StackTrace);

Apesar de bastante básico, este método faz uso de reflexão para identificar a origem do erro.

Minha pergunta

Olhando para a minha solução de log atual parece "suficiente" em termos do que ele faz e como ele é integrado com todas as minhas soluções. No entanto, eu estive olhando os quadros madeireiras (Notavelmente log4net) e suas características me impressionar. A capacidade de, se necessário, no futuro, adicionar outro formato de saída (como um servidor SMTP) soa bem legal para mim! :)

O que eu gostaria de saber são os benefícios de se mudar para um quadro (como log4net)? A medida de quanto eu vou ter que adaptar o meu código? Seja ou não estou apenas olhando para a grama mais verde do outro lado? E, finalmente, mas provavelmente o mais importante, eu estou fazendo a coisa certa? Devo apenas adicionar a capacidade de minha classe Log para "LogDebug" e ser feito com ele? A última coisa que eu gostaria de fazer é alterar completamente a minha suite, apenas para um recurso "básico", mas se há outros benefícios (para o design, a confiança, a boa prática? Etc.) Eu estou interessado.

Obrigado,

Answer 1

logging adequada é especialmente benéfico quando a execução de código em vários sistemas remotos, tanto quanto me lembro, log4net permitirá que você envie seus registros para um servidor remoto syslog sem muito codificação cima (ou seja, você pode ver seus registros de todas as máquinas em um local centralizado) fazendo isso irá reduzir maciçamente o tempo que você leva para obter informações relativas a um erro ou problema com o sistema, e deve também dar-lhe uma indicação de quão prevalente é o problema.

Como mencionado em outros lugares, log4net também permite múltiplas appenders e vários níveis de log, por isso, determinar onde você quer que certas informações de log (ou seja, em um banco de dados ou em um arquivo simples local, hey log4net ainda permite que você espeto registros ao longo de telnet ) a ser armazenado é um doddle absoluto.

Como para implementá-lo, existem vários sites bons falando através da instalação. Como você realmente fazer uso do registro de objetos que log4net dá-lhe é uma escolha de arquitectura, mas você pode simplesmente mudar o construtor de um objeto para tirar um objeto log4net e de dentro desse objeto, basta usar o objeto log4net como faria Console.WriteLine .

Acho que a série tutorial aqui particularmente útil, e também vou entrar em mais profundidade do que eu aqui sobre os benefícios e as diferentes formas de configurar log4net.

Answer 2

Sim. Usando uma estrutura de log existente, comprovada (como Log4net) é uma boa idéia.

Log4Net é configurável em tempo de execução (ótimo para rastrear problemas no código de produção).

Como um comentarista apontou, também é muito simples de usar.

Answer 3

Sim, você definitivamente quer usar uma estrutura de log. A estrutura de log irá permitir-lhe:

• Definir os níveis de log para as diferentes instâncias do registrador.
• Defina as "appenders" ou de saída para cada uma das diferentes instâncias logger.

Talvez, mais importante, se você usar uma estrutura de log, é muito fácil de trocar uma implementação do quadro de registro para outra (talvez uma implementação nula de que simplesmente descarta mensagens); Considerando que, se você escrever todas as suas declarações de log, diretamente, trocando a implementação vai ser um pesadelo.

Answer 4

Eu acho que você deve usar Log4net, simplesmente porque é sempre melhor reutilização do que construir sua própria coisa. log4net tem sido usado por um monte de desenvolvedores e são bastante amadurecido.

Pense sobre a sua perspectiva de manutenção; um ou dois meses na estrada, você pode precisar de ajustar a sua classe de log personalizado um pouco, para adicionar algum multithreading suporte etc. E quando você está corrigindo os erros surgiu a partir de sua classe de log, você vai perder Log4net.

Answer 5

Bem, uma das maiores benefícios é não ter que manter o código você mesmo. Na maioria das vezes, os quadros madeireiras têm uma funcionalidade muito mais do que a sua própria solução. Porque eles estão tão focados sobre a exploração madeireira, essas estruturas são geralmente bastante completo na funcionalidade e maneiras de implementá-lo. E depois há a confiabilidade; não há nada pior do que um quadro de log que não está registrando nada porque ele está sob escuta. ;)

Tome por exemplo ELMAH para aplicações ASP.NET. Ele também inclui notificações, as exportações para vários formatos de destino, etc. Coisas que são muito útil, mas você nunca vai construir-se a menos que você realmente precisa dele.

Como muitas alterações em seu código são necessários, obviamente, depende tanto do seu código e do quadro de escolha. É difícil dizer nada sobre isso.

Answer 6

Eu vou dar um grito para fora NLog ( http://nlog-project.org/home ) uma vez que não sofrem com o 'Straight Java Port - então reescrever'. síndrome de mais oss .Net libs

Alguns dos principais benefícios para nós foram o muito rápido Logger.IsFooEnabled (Leia volátil) e o desempenho geral do sistema.

Para cada sua própria embora, mas eu, pessoalmente, prefiro NLog para meus projetos (e alguns dos meus clientes também).

Cheers, Florian

Answer 7

A vantagem de usar uma boa estrutura de log como log4net é que eles têm um pequeno impacto sobre seu código em termos de linhas de código que você tem de alterar (em outras palavras, você só tem que alterar cada linha de log existente).

Além disso, se você está preocupado em alterar o seu código se você mudar os quadros, ou se você sentir que você desejar construir sua própria, então você pode sempre criar sua própria interface para um framework login. Então você só tem que mudar seu código em um lugar depois disso.

Answer 8

Eu acho que os administradores de sistemas esperar serviços para log no log de eventos do aplicativo no Windows.

Olhe para cima System.Diagnostics.EventLog, embora log4net vai escrever para que também ..

Answer 9

A declaração inicial na log4j website poderia ajudar em alguns dos seus questões, os princípios subjacentes são os mesmos de log4net:

Com log4j é possível permitir log em tempo de execução, sem modificar o binário do aplicativo. o log4j pacote é projetado para que estes declarações podem permanecer no código enviado sem incorrer em uma performance pesado custo. Log comportamento pode ser controlada pela edição de uma configuração arquivar, sem tocar a aplicação binário.

Usando uma hierarquia logger é possível para controlar qual o log declarações são emitidos a arbitrariamente granularidade fina, mas também grande facilidade. Isso ajuda a reduzir o volume de logged o rendimento e minimizar o custo de logging.

Neste caso, há claramente não precisa reinventar a roda. A maioria dos quadros de Log são um pouco simples, de modo a estender de mudanças provavelmente irá depender do tamanho dos seus programas existentes.

Answer 10

Se você escrever sua classe logger adequadamente, ele será facilmente dispensável para algumas de suas necessidades. Qualquer quadro poderia impressioná-lo com muitos recursos, mas outra estrutura é outra variável no seu processo de depuração, pois ele pode dar-lhe um erro que não existe ou pode cometer um erro por si só em combinação com a sua aplicação. Se você está pronto para fazer o teste beta para o projeto de software de fonte aberta é bem ...

Em seu lugar eu iria escrever classe de log com capacidade de estender Possui você achar interessante para você projeto com base na lista de características estruturas conhecidas têm. Eu não vejo nenhum problema para registrar algo para arquivo e, em seguida, enviá-lo através smpt, apenas uma pequena função faz o trabalho.

Além disso, você pode escrever sua própria classe que vai ser muito abstrato e colocar o seu código básico lá, se você nunca precisará usar enquadramento externo para testar você classe seria capaz de usá-lo com um impacto mínimo no código. Basta dar uma olhada como há quadros são implementados no nível de código.

pensar que você terá que aprender como usar corretamente estes quadros quando suas únicas necessidades para agora fazer logon parte muito pequena dela ...