Logging e Tracing
Freqüentemente, em reuniões de arquitetura, orientamos os desenvolvedores a criarem mecanismos de logging e tracing, com o simples objetivo de ajudá-los a identificar problemas em produção rapidamente. Estes mecanismos fazem parte do processo de instrumentação da aplicação.
Em grandes organizações, como bancos e seguradoras, o acesso a produção é restrito(graças a Deus, nosso dinheiro agradece), não conseguimos, por exemplo, em caso de problemas, abrir nosso componente e colocar uma entrada no eventlog com aquelas mensagens clássicas "Passei por aqui!!!", portanto, instrumentar o código é de fundamental importância, e com certeza vai te poupar muita dor de cabeça. Infelizmente é algo pouco praticado pelos desenvolvedores em geral.
Uma dúvida freqüente, é a diferença entre logging e tracing. A diferença está no teor e quantidade de informações coleadas e armazenadas.
Logging: É o registro contínuo, de qualquer tipo de informação que importante para o usuário final do componente e da aplicação. O logging gera um volume de dados bem inferior a um processo de tracing devido a natureza dos dados. Exemplos de logs:
-
Registro de um erro inesperado
-
Registro do nome do usuário e data quando um dado sensível do sistema foi alterado
-
Registro dos acessos realizados a um sistema, entre outros.
Tracing: Registro de informações extremamente detalhadas e geralmente de cunho técnico, sobre o processo de execução de um componente. É uma informação relevante somente ao desenvolvedor do componente e equipe de suporte.É interessante que o trace seja parametrizável(liga/desliga) e classificável(ERROR,INFO,etc...), possibilitando que ao ligar o log, você determina que tipo de trace é desejado. Exemplos:
-
Passo a passo de execução de uma rotina
-
Dados relativos ao tempo de execução de uma rotina
-
Erro detalhado(mensagem, pilha de execução, fonte, etc..)
Cuidados a serem tomados
Expurgo: Uma vez definido quais logs e traces sua aplicação terá, é necessário definir a política de tempo que a informação ficará em repositório(File System, Banco de dados, etc...). Geralmente logs oriundos de obrigações legais, ficam em torno de 5 anos armazenados, traces, devido a natureza prolixa com propósito de curto prazo, ficam um ou dois em base. Limpar logs é necessário, pois a taxa de crescimento é expressiva e consome muitos recursos.O expurgo pode ser feito de várias formas:
-
-
Tarefa agendada do Windows que executa alguma linhas de comando que faz a atividade de expurgo
-
A própria aplicação fazê-lo de tempos em tempos(não recomendável)
-
Produtos comerciais
-
Ferramenta criadas pela própria empresa
Baixa interferência: O logging/tracing não devem onerar a aplicação submetida a instrumentação. Se houver algum tipo de latência, que seja a menor possível. Menor é subjetivo e deve estar alinhado com tempo de resposta esperado pelo processo de negócio. A melhor forma de mitigar este problema é a inclusão assíncrona destes logs, ou seja, o componente não espera a inclusão de logging/tracing para que continue sua atividade.
Frameworks
Existem diversos frameworks, e utilitários já disponíveis para instrumentar a aplicação, dos quais posso citar:
TraceSource: Classe introduzida no .Net 2.0. O WCF o utiliza para o trace e diagnóstico de problemas
Log4Net: Um dos mais famosos frameworks para esta finalidade e portado do Java.
Logging Application block: Parte integrante do Enterprise Library.
Este é basicamente um post teórico e com objetivo de elucidar dúvidas sobre algo tão pouco posto em prática. Assim que possível, vou postar algo mais prático, mostrando algumas maneiras de instrumentar a aplicação, como por exemplo, por OAP.
Referências:
The Difference Between Logging and Tracing
Application Instrumentation