|
|
| Linha 1: |
Linha 1: |
| O BISLogger é um serviço de "log" do sistema com a função de realizar o registro de informações do sistema para os desenvolvedores. O desenvolvedor deve chamar o BISLogger sempre que alguma informação deva ser registrada ou informada para ajudar a encontrar problemas no sistema ou mesmo auxilia-lo durante a fase de desenvolvimento para visualizar o fluxo que o sistema tomou sem ter que debugar de linha em linha. Além da possibilidade de imprimir no console, este serviço é responsável por salvar em banco todas as informações necessárias em caso de erros e/ou outros acontecimentos do sistema. | | O BISLogger é o serviço de persistência dos logs utilizado no BISERP para comsumir os Logs feitos através do serviço do [[FWLogger]]. |
|
| |
|
| | Para entender melhor de como fazer os logs e seu funcionamento, leia a página do [[FWLogger]]. |
|
| |
|
| {{stop|Log Recursivo Na Persistência|Um dos problemas do modelo criado do BISLogger é que ele não permite que o BISLogger seja utilizado nas classes que ele mesmo utiliza. No caso o método do [[BISInterceptor]] e o [[BISDAO]]. Isso porque toda vez que o BISLogger for persistir os logs no banco, gerará novos Logs sobre a persistência, e assim por diante.
| | O BISLogger é apenas uma Thread que se inicia junto com o deploy da aplicação (iniciado pelo Brainz), que de tempos em tempos procura por novos logs no [[FWLogger]] e os persiste no banco de dados. Removendo assim os recursos da memória. |
|
| |
|
| Seria possível escrever um DAO exclusivo para o BISLogger, eliminando o problema do BISLogger no [[BISDAO]], já o problema do [[BISInterceptor]] requisitaria uma fachada completa só para esse fim. Nada difícil ou impossível, mas não implementado por enquanto. Tais detalhes de Debug dessas classes devem continuar sendo jogadas somente no console comente quando em modo de desenvolvimento. Consulte o [[BISSystem]] para saber como obter se está ou não em modo desenvolvimento. }}
| | O BISLogger precisa ser forçado a desligar no fim do undeploy da aplicação, através do método de shutdown(). Depois da chamada desse método recomenda-se não realizar mais nenhum log pois eles podem ser perdidos. |
| | |
| O BISLogger se integra junto com o framework do BIS, permitindo que tudo seja registrado de forma a facilitar o debug e relatórios para o desenvolvedor. Como por exemplo, fazem parte do log as informações sobre qual empresa estava sendo utilizada, qual usuário estava logado e o UUID da sessão do usuário - quando essas informações ocorrem dentro de uma sessão de usuário.
| |
| | |
| | |
| = Funcionamento =
| |
| | |
| Antes do BISLogger é uma classe estática e pode ser usada a qualquer momento. Todas as chamadas aos métodos '''.log*()''' criam entradas de log automaticamente que ficam armazenadas em uma lista dentro do próprio BISLogger. O mais rápido possível para não impactar muito na performance. Mesmo assim a quantidade de logs realizados devem ser moderados.
| |
| | |
| Para que essa lista seja enviada para persistência, é necessário iniciar a Thread "de persistência" dento do BISLogger. Para isso o método '''.startPersistThread()''' precisa ser chamado pelo menos uma vez. Chamadas subsequentes são apenas ignoradas. Em caso de erro essa Thread não faz mais Log, mas joga todo o conteúdo no console.
| |
| | |
| Este método frequentemente pega todos os objetos de log gerados e os envia para persistência removendo eles da memória. O envio é feito através da fachada do BIS, procurando ela de forma local. Não há ainda uma maneira de configurar a lookup remoto.
| |
| | |
| Para encerrar, o BISLogger tem o método '''.shutdown()'''. Este método impede que novos Logs sejam feitos, enviando BISRunTimeExceptions() nas tentativas, e força a ''PersisThread'' a enviar todos os objetos para a persistência e se encerra.
| |
| | |
| == No BISEJB ==
| |
| | |
| Dentro do BISEJB o [[Brainz]] se responsabiliza tanto por iniciar a '''.startPersistThread()''' logo ao começo do Deploy, quando à chamar o '''.shutdown()''' como último evento antes de finalizar o unDeploy.
| |
| | |
| | |
| = Estrutura do Objeto de Log =
| |
| | |
| Cada evento de Log é um objeto diferente. Esse objeto tem uma composição de 1:1 para jogar conteúdos muito extensos para outra tabela, permitindo assim que uma listagem dos objetos seja rápida e fácil de carregar. Tratando toas as informações de grande tamanho (como arquivos, registros de XML, prints de Objetos, etc.) como um anexo ao evento de Log.
| |
| | |
| A classe BISLogger faz a separação automaticamente. Toda vez que o conteúdo passar de 300 caracteres ele é automaticamente definido como um anexo e colocado no objeto anexo.
| |
| | |
| | |
| | |
| = ABAIXO, CONTEÚDO DO BIS ANTES V10 =
| |
| | |
| O BISLogger é um serviço de "log" do sistema com a função de realizar o registro de informações do sistema para os desenvolvedores. O desenvolvedor deve chamar o BISLogger sempre que alguma informação deva ser registrada ou informada para ajudar a encontrar problemas no sistema ou mesmo auxilia-lo durante a fase de desenvolvimento para visualizar o fluxo que o sistema tomou sem ter que debugar de linha em linha. Além da possibilidade de imprimir no console, este serviço é responsável por salvar em banco todas as informações necessárias em caso de erros e/ou outros acontecimentos do sistema. Distinguindo as informações importantes das desnecessárias para evitar um "flood" no banco de logs e transformando o BISLogger em um registro de uso do sistema.
| |
| | |
| Com base nessas informações e em seu filtro de importância dos registros, o BISLogger é responsável também por filtrar e informar automaticamente a equipe de desenvolvimento sobre erros que acontecem no sistema sem que o usuário tenha que se incomodar com isso.
| |
| | |
| Os benefícios deste serviço é proporcionar a equipe de desenvolvimento informações mais precisas sobre os erros do que as informações desconexas normalmente provenientes dos usuários, além de ter certeza de ser notificado de toda falha do sistema. Evitando que usuários deixem de informar sobre os erros e acabem descontentes com o sistema.
| |
| | |
| {{nota|BISLogger, BISLoggerManager e BISLoggerFinisherTask|O conteúdo dessa página é voltado para o funcionamento do BISLogger no BISKernel e seus módulos, isto é, para o funcionamento na parte servidora.
| |
| | |
| Mas vale observar que a classe BISLogger concentra apenas os métodos de "montagem" do relatório de log, definindo o formato dos logs que serão escritos. A lógica de persistência e de finalizações de cada relatório dependem da aplicação onde o BISLogger for utilizado. No caso do BISKernel todas essa lógica se espalha pelo BISLoggerManager, BISLoggerFinisherTask e no Brainz.
| |
| | |
| Isso permite que a classe BISLogger seja reutilizada em outras aplicações paralelas (como apps para Desktop, Mobile, etc.) para montar o Log no mesmo formato e até mesmo serem sincronizadas para o BISServer.}}
| |
| | |
| | |
| = Registro =
| |
| | |
| == Registro de Mensagens de Texto ==
| |
| Na classe principal do BISLogger existem 4 métodos principais, estes registram mensagens em 4 categorias diferentes. São elas:
| |
| * '''error''' - É uma mensagem de problemas encontrados no sistema, algo anormal que deve ser levado em consideração.
| |
| * '''warn''' - Warning é uma mensagem de aviso, quando algo não está como esperado mas não deverá causar nenhum erro nos sistema. Já tem uma relevância maior que a info.
| |
| * '''info''' - Informações simples a serem exibidas no console para mostrar ao desenvolvedor sobre o que o sistema está fazendo, de forma genérica e mesmo sem muitos detalhes. Exatamente um "System Out".
| |
| * '''debug''' - Este tipo de mensagem é uma mensagem detalhada, com anotações dos objetos e detalhes da execução de um método. Geralmente usada para rastreamento preciso de algum erro que esteja acontecendo no sistema e não esteja simples de se detectar.
| |
| * '''stack''' - Permite o registro de informações (uma msg de texto) seguida da pilha de Thread, similar a stack de uma exception, para indicar o "percurso" realizado pelo programa para chegar até aquele método. Muitas vezes saber o caminho realizado até determinado ponto ajuda a determinar melhor o fluxo do programa do que diversos "debugs" espalhados pelo sistema.
| |
| | |
| == Registro de Mensagens Especiais ==
| |
| | |
| * '''report''' - O tipo de registro Report é registrado separado do relatório da Thread padrão do BISLogger. Ele é identificado por um ID passado no primeiro parâmetro do método. Os registros sucessivos utilizando o mesmo ID de relatório serão somados em um único Log até que este seja finalizado por inatividade, ou forçado no shutdown/undeploy do sistema. Independente da Thread que o faça o log, todos os farão parte do mesmo relatório. A ideia é possibilitar o registro em um mesmo relatório quando o sistema está distribuído em Threads.
| |
| | |
| == Registro de Exceptions ==
| |
| Além do registro de mensagens simples descritos anteriormente, o BISLogger apresenta métodos para registrar Exceções de forma simples! Basta chamar seu método e passar a exceção ocorrida, seu stack trace será recuperado e registrado junto com a mensagem.
| |
| | |
| == Registro de VOs ==
| |
| Em alguns casos pode haver a necessidade de se registrar os VOs completo do sistema para saber o que está causando o erro. Para tal o BISLogger dispõe de um método que lê e imprime qualquer VO do sistema. Neste caso deve ser descendente de BISDefaultVO.
| |
| | |
| = Auto-Debugger =
| |
| Com a finalidade de registrar em detalhes todas as informações importantes que acontecerem no sistema o BISLogger registrar todos os eventos relacionados a uma Thread em memória, e se antes do fim da Thread ocorrer o registro de alguma informação desejada (definida em configuração), como por exemplo uma exception, todo o LOG (incluindo msgs do tipo Debug, Info, etc.) será salvo em banco de dados e posteriormente enviado aos servidores do BISServer. Caso nada ocorra as informações serão descartadas sem que se ocupe espaço registrando informações desnecessárias.
| |
| É possível configurar o Auto-Debugger para saber quais dados são importantes para registro, verifique a sessão de Configuração para saber como.
| |
| | |
| {{nota|Relatórios|O Auto-Debugger funciona independente das configurações de impressão das mensagens. Isto é, mesmo que as configurações não permitam que o BIS escreva no console o registro dos erros, o Auto-Debugger continuará registrando estas mensagens para reportar aos servidores.}}
| |
| | |
| | |
| {{nota|BISValidationException|Quando as exceptions são da classe BISValidationException o BISLogger não faz registro automático (exceto se configurado para isso) e ignora como se não tivessem ocorrido exceptions. Isso porque não trata-se de um erro, mas sim de alguma falha de validação nos dados recebidos para processamento. Em outras palavras, as exceptions de validação não são tratadas junto com as demais exceptions do sistema. Para registrar toda e qualquer exception de Validation, o BISLogger deve ser explicitamente configurado.}}
| |
| | |
| | |
| {{nota|Nível de Registro das Mensagens|O Auto-Debugger funciona independente das configurações de impressão das mensagens. Isto é, mesmo que as configurações não permitam que o BIS escreva no console o registro dos erros, o Auto-Debugger continuará registrando estas mensagens para reportar aos servidores.}}
| |
| | |
| | |
| = Configuração BISLogger =
| |
| | |
| O BISLogger deve ser configurado no servidor, através das propriedades de sistema abaixo:
| |
| | |
| <center>
| |
| {| class="wikitable" style="width:70%; align:center; text-align:center;"
| |
| ! colspan="2" | Propriedades de Configurações BISLogger
| |
| |-
| |
| ! Propriedade
| |
| ! Efeito
| |
| |-
| |
| |br.com.biserp.biscore.bislogger.systemout.info
| |
| |True para jogar no System.out todas as informações que forem logadas. False ignora.
| |
| |-
| |
| |br.com.biserp.biscore.bislogger.systemout.warn
| |
| |True para jogar no System.out todos os alertas que forem logados. False ignora.
| |
| |-
| |
| |br.com.biserp.biscore.bislogger.systemout.error
| |
| |True para jogar no System.out todos os erros que forem logados. False ignora.
| |
| |-
| |
| |br.com.biserp.biscore.bislogger.systemout.debug
| |
| |True para jogar no System.out todos os debugs que forem logados. False ignora.
| |
| |-
| |
| |br.com.biserp.biscore.bislogger.systemout.report
| |
| |True para jogar no System.out todos os reports que forem logados. False ignora.
| |
| |-
| |
| |br.com.biserp.biscore.bislogger.systemout.validations
| |
| |True para jogar no System.out todas as exceções de validação que forem logados. False ignora.
| |
| |-
| |
| |br.com.biserp.biscore.bislogger.systemout.exceptions
| |
| |True para jogar no System.out todas as exceções (exceto de validações) que forem logados. False ignora.
| |
| |-
| |
| |br.com.biserp.biscore.bislogger.systemout.vos
| |
| |True para jogar no System.out todos os VOs que forem logados. False ignora.
| |
| |-
| |
| |br.com.biserp.biscore.bislogger.autodebugger.info
| |
| |True para enviar para o BISServer todas as informações que forem logadas. False ignora.
| |
| |-
| |
| |br.com.biserp.biscore.bislogger.autodebugger.warn
| |
| |True para enviar para o BISServer todos os alertas que forem logados. False ignora.
| |
| |-
| |
| |br.com.biserp.biscore.bislogger.autodebugger.error
| |
| |True para enviar para o BISServer todos os erros que forem logados. False ignora.
| |
| |-
| |
| |br.com.biserp.biscore.bislogger.autodebugger.debug
| |
| |True para enviar para o BISServer todos os debugs que forem logados. False ignora.
| |
| |-
| |
| |br.com.biserp.biscore.bislogger.autodebugger.report
| |
| |True para enviar para o BISServer todos os reports que forem logados. False ignora.
| |
| |-
| |
| |br.com.biserp.biscore.bislogger.autodebugger.validations
| |
| |True para enviar para o BISServer todas as exceções de validação que forem logados. False ignora.
| |
| |-
| |
| |br.com.biserp.biscore.bislogger.autodebugger.exceptions
| |
| |True para enviar para o BISServer todas as exceções (exceto de validações) que forem logados. False ignora.
| |
| |-
| |
| |br.com.biserp.biscore.bislogger.autodebugger.vos
| |
| |True para enviar para o BISServer todos os VOs que forem logados. False ignora.
| |
| |}
| |
| </center>
| |
| | |
| {{nota|Configurações Auto-Debugger|Se o Auto-Debugger estiver configurado para enviar apenas mensagens do tipo exception, significa que ele enviará apenas Logs em que tenham ocorrido registro de exceptions, porém o Log completo será enviado, com o registro dos debugs, infos, warns, e tudo mais. Não apenas a informação definida para enviar.
| |
| Em outras palavras, as configurações do auto-debugger indicam quais mensagens devem aparecer no log para que ele seja importante o suficiente a ponto de ser enviado para o BISServer.}}
| |
| | |
| = Ownership =
| |
| | |
| O BISLogger tem na ideia não gerar um único arquivo de log com tudo o que acontece, mas sim separar as informações por processamento, ou acionamento, de forma que as informações não se misturem já que se trata se uma plataforma multiusuário.
| |
| | |
| O sistema de ownership do relatório de erro foi criado para ajudar a resolver alguns problemas que impedem esse funcionamento adequadamente.
| |
| | |
| Os problemas conhecidos:
| |
| # '''pool de thread''' - para otimizar a performance, o servidor de aplicações trabalha com pools de threads que já permanecem abertas para ganhar tempo durante as chamadas de usuários. Isso ocorre por exemplo para conexões com o banco de dados, para requisições fachada, requisições http, etc. Como uma das interfaces do BIS é web, as requisições são sempre tratadas pelas mesmas threads, e como estas nunca morrem o BISLogger não consegue perceber a hora de finalizar o relatório.
| |
| #: A solução encontrada para esse problema é "fácil", forçar que no fim dos métodos de "entrada" da aplicação force a finalização do relatório de Log. Por exemplo, recebemos uma requisição http no nosso servlet, tratamos a requisição e no final fazemos a finalização no BISLogger. O que nos leva ao problema 2:
| |
| # '''multiplos pontos de entrada do sistema''' - O BIS tem múltiplos pontos de entrada no sistema, e muitos usados pelo próprio BIS. Por exemplo, podemos ter uma requisição http na camada de presentation, esta para obter os dados aciona o Fachada do CRUD para obter os dados necessários, já o CRUD precisa acionar a fachada de outro BISPlugin ou do BISCore pra obter outros dados necessários. Em outro momento, podemos ter simplesmente uma chamada diretamente na fachada, sem passar pelo http ou por fachadas de outros BISPlugins.
| |
| #: A solução para os dois problemas é definir por onde foi que a entrada ocorreu. Assim é o sistema do Ownership.
| |
| | |
| No Servlet, nas Fachadas e em qualquer outro ponto de entrada do sistema devemos registrar no BISLogger que aquela classe é o 'dono' do log! E só ele poderá finaliza-lo. Evitando assim que outros pontos de entrada consigam finaliza-lo. Em resumo, os pontos de entrada devem ter um código similar ao abaixo para tomar 'posse' do relatório de log:
| |
| | |
| {{java|Tomando Posse do Relatório de Log|<syntaxhighlight lang="java5">
| |
| Long ownerkey = BISLogger.takeOwnership();
| |
| try {
| |
| //Todo o código da aplicação normalmente
| |
| } finally {
| |
| BISLogger.finishOwner(ownerkey);
| |
| }
| |
| </syntaxhighlight>}}
| |
| | |
| | |
| {{stop|Não se preocupe (muito) com o ownership!|Normalmente o desenvolvedor não precisa se preocupar muito com o ownership, a não ser que esteja desenvolvendo alguma nova entrada de acesso ao sistema.:
| |
| * Todas as chamadas http que utilizam a camada de Presentation do BIS não precisam se preocupar com o isso, o BIS já faz a interceptação diretamente no '''BISServlet''';
| |
| * Qualquer chamada feita pelas fachadas, já têm o ownership definido pelo '''BISInterceptor''', preocupe-se apenas se a fachada não tiver o BISInterceptor registrado.}}
| |
| | |
| | |
| Com isso o BISLogger distribuirá chaves para os interessados em obter o ownership do log, mas somente o primeiro que tomar posse poderá finaliza-lo.
| |
| | |
| | |
| {{nota|Só para mesma thread!|Note que o BISLogger só consegue perceber quem é o dono do log de acordo com a thread que solicitou o ownership. Se o sistema bifurcar em threads, o BISLogger fará novos relatórios para cada nova threads.
| |
| Como o BISLogger não tem um sistema de redirecionar logs de uma thread para outra, (mesmo porque isso misturaria os logs das várias threads) é aconselhável que se crie se crie "chaves" e se registre nos relatórios das Threads, para que se for necessário o desenvolvedor possa identificar o relatório da outra Thread. Por exemplo, no fim da thread que lançará as novas threads registramos "Thread Bifurcando ID: <qualquer id randomico>", e nas Novas Threads registramos "Thread bifurcada! Continuação do ID: <mesmo id randomico do anterior>".}}
| |
| | |
| = Fork de Threads =
| |
| | |
| '''NÃO IMPLEMENTADO AINDA'''
| |
| | |
| O BISLogger permite a geração de relatórios simplesmente acessando os métodos estáticos da classe BISLogger. O log é identificado pela Thread atual, isto é, cada Thread tem um relatório específico para que as informações não se misturem.
| |
| | |
| {{nota|Múltiplas Threads|Em casos em que um processo é dividido em múltiplas threads é necessário informar o BISLogger que que todas as Threads devem fazer parte do mesmo Log para que as informações se concentrem em um único relatório. Utilize o método '''attachChildThreadToLog()''' para associar uma nova Thread ao relatório pai.}}
| |