Dicas e boas práticas de aplicações registrando

temos assumido com o tempo como aspectos como segurança e testes devem ser levados em conta durante todo o ciclo de vida do projeto, de suas origens à sua conclusão. Que não são requisitos não funcionais não funcionais ou secundários, se não forem as prioridades como parte da estrutura fundamental do aplicador (não é tantas funcionalidades ou mecanismos que foram projetados e implementavam a conclusão do projeto como uma adição se eles foram feitos). No entanto, o traço de aplicação, ainda tendo mérito, não recebeu em muitos casos a mesma consideração; – p.

Neste post eu não acho que eu descubro nada de novo para aqueles que têm experiência em desenvolvimento . A ideia é exercer síntese e revisão para resumir o que, na minha opinião, são as melhores ou boas práticas do log do aplicativo. Claro, contribuições, observações, nuances e críticas são bem-vindas; Convido você a participar desse exercício.

O log ou traço do aplicativo é o processamento e armazenamento de informações sobre a execução de um aplicativo. Ele contém dados de entidades, alterações de status e componentes de software envolvidos em tal execução. Sua principal funcionalidade é facilitar o monitoramento ou análise da execução do aplicativo:

• analisar o comportamento do aplicativo durante a fase de desenvolvimento e depuração (testes de caixa branca)
• Analise os erros ou erros de execução detectados, suas causas e conseqüências
• Sirva como um registro de auditoria quando as informações contidas e o modo em que ele foi processado atende aos critérios necessários
• medida o desempenho ou o carregamento de sistemas ou aplicativos
• inverta o status do aplicativo seguido na ordem inversa O log

depende das circunstâncias em que nos encontramos O segundo dos usos é geralmente o mais relevante. Um bom log desenvolvido corretamente no código e mantido ou configurado em operação é uma garantia de resposta rápida para análise de erros; que poderia até ser feito sem a necessidade de parar o aplicativo, reconfigurar ou aplicar qualquer alteração.

O rastreio do aplicativo é geralmente formado por um conjunto de eventos armazenados sequencialmente, geralmente na ordem em que acontecer, persistentes ou recuperáveis. Eles podem ser armazenados em arquivos, em BBDD, em componentes distribuídos para este propósito … Os mecanismos de rotação ou historificação podem ser ativados, eles podem ser usados por monitores para lançar alertas, eles podem ser integrados e mesclados para fazer análises mais exaustivas. . O relevante é que as informações registradas e como ela é capaz de ser útil.

Existem inúmeras soluções e propostas de software, livres e mais completas, mais ou menos padronizadas, mais simples ou mais completas, de milhares tipos e formulários. O importante é procurar que se adapte às nossas necessidades e ambientes, esqueça a implementação do mecanismo completamente; e manter os dois aspectos mais importantes:

• o conteúdo de cada registro ou evento, a principal preocupação do desenvolvedor
• a maneira em que ela é processada, persiste e Gerencia, principal preocupação com a operação do sistema ou aplicador

O custo de implementação do registro está no IR, enquanto se desenvolve, deixando o rastreamento em diferentes pontos do código. Esta atividade deve ser feita durante o desenvolvimento, seguindo padrões, critérios e procedimentos pré-estabelecidos. Dessa forma, os desenvolvedores terão critérios comuns e o traço será consistente entre as diferentes partes do código.

O traço e a documentação do código podem ter pontos comuns em termos de sua filosofia, objetivos e Modo de aplicação, mas há uma diferença importante entre os dois: enquanto a documentação do código entra para o por que algo é feito dessa maneira, o traço deve cobrir o que é feito. Ao definir um exemplo, em um loop, a documentação do código deve indicar por que os limites ou condições de saída são tais e o registro de rastreamento durante a execução em que ponto a condição de saída foi atendida.

Informações registradas no O traço deve ser relevante e completo. Você pode considerar os seguintes aspectos ao decidir quais informações incluem:

• O que:
  que evento ou ação aconteceu.
• Quais entidades têm estado envolvido.
• Se houver uma mudança de status, qual foi o anterior? Qual é o novo estado?

onde:

• em que ponto do código ocorreu: componente, classe, arquivo de código, método ou bloco de execução, linha de código … como Muito mais detalhado é esta informação melhor para localizar o local de possível erro ou onde a execução passou, por um lado; Mas mais pode afetar o log de desempenho (informações de depuração podem ser necessárias) e a conclusão de informações de rastreamento, por outro.

quando:

• registrando o temporário momento, absolutamente ou relacionado com o início da execução ou qualquer outro evento.
• gerando um traço seqüencial ou causal, no qual os eventos que ocorrem no início do tempo ou fazem com que os outros apareçam antes.

em que contexto:

• estados de registro ou variáveis: execução de si (parâmetros), personalização ou usuário específico, referente à sessão ou transação em execução …
• indicando cadeias, transações ou pedidos relacionados quando estamos em ambientes simultâneos.

para as informações de rastreio é mais detalhado no momento da análise e mais gerenciável durante a exploração, os níveis de filtragem são estabelecidos. De tal forma que apenas esses eventos sejam mostrados ou armazenados com um nível maior ou igual ao nível de traço estabelecido. As bibliotecas de registro permitem que eventos filtrassem eventos por outros critérios, como a classe ou o contexto do evento.

Os níveis mais comuns são depurados, informações, aviso e erro. A classificação de diferentes eventos em cada nível é parte do exercício de análise e deve ser destinado ao fato de que o traço é legível e útil nos diferentes contextos do pedido, desde o desenvolvimento até a exploração.

Pode ser um exemplo de semântica dos níveis de log:

• Depuração, para informações de nível muito baixo Útil para o depuração do aplicativo, tanto no desenvolvimento quanto na análise de incidentes
  • Chamadas para funções e procedimentos e outros componentes, com parâmetros e respostas
  • fluxos de execução
  • desenvolvimento de algoritmos e procedimentos que permitem identificar e seguir sua execução de desenvolvimento
• informação, informações de nível superior que permite monitorar a execução normal
  • paradas e paradas de serviços e sistemas
  • parâmetros críticos ou configuração relevante
  • início e fim de transações e operações completas
  • alterações de Status das operações
• avisar, situações informações, que ainda sem erro, se anormal ou não previsto, embora o aplicativo tenha alternativas para resolvê-las
  • parâmetros definidos, e cujo valor é feito por padrão
  • em situações anômalas, mas que são resolvidas pelo aplicativo, deixando a operação em um estado correto
  • funcionalidades não primordiais ou essenciais, que Eles não podem ser resolvidos, mas deixam a operação em um estado correto
• erro, informações de situações que são erros e que impedem a execução correta de uma operação ou transação, Mas sem afetar outras operações ou transações (erro ou conteúdo isolado)
  • Nenhuma operação ou transação não pôde ser executada, mas não afeta outras solicitações
  • ou consultas erradas (armazenando os parâmetros de Entrada)
  • funcionalidades gerais da aplicação, que ainda afetam o funcionamento geral da aplicação IVO, não são considerados primordiais ou essenciais
• Fatal, situações de erro Informações que afetam o funcionamento geral do aplicativo (erros ou conteúdos não insulados no escopo)
  • Parâmetros não definidos ou configurações erradas
  • falta de conexão ou comunicação com outros componentes
  • erros de execução que podem afetar operações ou transações independentes, ou que afetam o funcionamento geral do aplicativo

Tanto o conteúdo quanto a forma de cada evento de log, como a semântica dos níveis, fazem parte do desenho do aplicativo. Esses critérios devem ser definidos e comunicados à equipe de desenvolvimento para aplicar de forma homogênea e coerente ao longo do desenvolvimento. Se esses critérios forem acordados com o equipamento, você pode obter muita vantagem da experiência do desenvolvedor.

Outras recomendações para levar em conta são:

• eventos de registro de uma forma Atomic, que todas as informações sobre um evento são armazenadas em um registro ou linha.
• Guia O formato das informações mostradas a serem usadas de maneira informatizada ou automática com ferramentas específicas.
• No que diz respeito a exceções:
  • sempre mostra o rastreamento completo da exceção com sua mensagem e todo o StackTrace.
  • Se a exceção for capturada, tratada e depois lançada novamente (bem a mesma ou outra) não deixe vestígios da exceção até que seja capturado e, finalmente,. Desta forma, cada exceção só será exibida uma vez. Se não fizermos dessa maneira e registrará cada captura e relançamento aparecerão no traço várias vezes e não saberemos se é o mesmo ou é vários. (Throw-Log de capturas antipatron).
  • Faça uso da prova de exceção causada ou interna quando captamos e recebemos a exceção. Em Java é o método GetCouse (), em .NET the InnerException Property.

• Faça uso de mecanismos MDC / NDC (informação de contexto) Para ambientes de múltiplos segmentos ou áreas de transação. Essas informações podem nos permitir filtrar ou especificar as informações de log em contexto de negócios específico, como clientes, usuários, produtos …
• Implementar o método de tostring () de todas as classes de negócios ou picos para facilitar o seu Traceado.
• Você tem que levar em conta as diferenças e as zonas de tempo ao trabalhar com logs de várias máquinas ou componentes.
• o log> não pode ter efeitos colaterais, você não pode modificar o status de qualquer parâmetro, variável ou procedimento. Só mostra informações. Deve ser leve, o próprio registro pode não exigir processamento longo ou caro.
• As chamadas para métodos, componentes e componentes distribuídos externos, devem ser registrados após a chamada, incluindo os parâmetros de entrada e resposta, bem como a classe / Componente e método, no nível de depuração. E no erro e nível fatal, quando ocorre um erro na chamada (se uma exceção deve ser rastrear, parâmetros de entrada e exceção)

uma saudação,

juan francisco Adame Lorite