BISLogger - Histórico de revisão

Rodrigogml em 20h02min de 26 de julho de 2023

2023-07-26T20:02:14Z

← Edição anterior		Edição das 20h02min de 26 de julho de 2023
Linha 26:		Linha 26:

	A thread termina utilizando o sistema de shutdown do RFW, ou seja, quando o método '''RFW.shutdownFW()''' for chamado. Ainda assim, após o encerramento de todo o sistema, alguns que também possam depender da mesma flag para se desligarem, é recomendado a chamada do método '''BISLogger.persistEntries()''' para garantir que não sobraram entradas pendentes.		A thread termina utilizando o sistema de shutdown do RFW, ou seja, quando o método '''RFW.shutdownFW()''' for chamado. Ainda assim, após o encerramento de todo o sistema, alguns que também possam depender da mesma flag para se desligarem, é recomendado a chamada do método '''BISLogger.persistEntries()''' para garantir que não sobraram entradas pendentes.



			= Manutenção =

			Para que os registros não fiquem esquecidos "para sempre" na base de dados só acumulando dados, o BIS tem implementada a tarefa '''BISLoggerMaintenanceTask''', que é executada periodicamente e limpa os registros mais antigos que uma determinada data.

			As datas de validade de cada tipo de registro de log podem ser definidos nas configurações (propriedades) do sistema.

Rodrigogml em 16h33min de 26 de julho de 2023

2023-07-26T16:33:41Z

← Edição anterior		Edição das 16h33min de 26 de julho de 2023
Linha 3:		Linha 3:
	Para mais informações leia a documentação do RFWLogger.		Para mais informações leia a documentação do RFWLogger.

	~~Logo~~, ~~todos os logs do sistema devem seguir~~ a diretriz do RFWLogger e ~~utilizar~~ os métodos da própria classe do RFWLogger para registrar os eventos.
			= Utilização para Log =

			Por ser uma implementação baseada no RFWLogger, a utilização segue as as diretriz do RFWLogger e utiliza os métodos da própria classe do RFWLogger para registrar os eventos.

Rodrigogml em 16h13min de 26 de julho de 2023

2023-07-26T16:13:50Z

@@ Linha 1: / Linha 1: @@
-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]].
+O BISLogger é a implementação do RFWLogger utilizada no BIS10.
-Para entender melhor de como fazer os logs e seu funcionamento, leia a página do [[FWLogger]].
+Para mais informações leia a documentação do RFWLogger.
-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.
+Logo, todos os logs do sistema devem seguir a diretriz do RFWLogger e utilizar os métodos da própria classe do RFWLogger para registrar os eventos.
-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.

Rodrigogml: Página substituída por '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...'

2020-10-15T17:03:20Z

Página substituída por '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...'

Mostrar alterações

Rodrigogml em 16h03min de 27 de julho de 2018

2018-07-27T16:03:29Z

← Edição anterior		Edição das 16h03min de 27 de julho de 2018
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.


			{{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.

			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 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.		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.

Rodrigogml em 19h42min de 16 de abril de 2017

2017-04-16T19:42:18Z

← Edição anterior		Edição das 19h42min de 16 de abril de 2017
Linha 4:		Linha 4:

	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.		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.}}

Rodrigogml: /* Fork de Threads */

2017-04-16T18:23:33Z

Fork de Threads

← Edição anterior		Edição das 18h23min de 16 de abril de 2017
Linha 139:		Linha 139:

	= Fork de Threads =		= 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.		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.}}		{{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.}}

Rodrigogml: /* Registro de Mensagens de Texto */

2017-04-16T18:19:42Z

Registro de Mensagens de Texto

← Edição anterior		Edição das 18h19min de 16 de abril de 2017
Linha 14:		Linha 14:
	* '''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".		* '''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.		* '''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 ==		== Registro de Mensagens Especiais ==

Rodrigogml em 14h06min de 26 de dezembro de 2016

2016-12-26T14:06:30Z

← Edição anterior		Edição das 14h06min de 26 de dezembro de 2016
Linha 5:		Linha 5:
	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.		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.

	== Registro ==
	=== Registro de Mensagens de Texto ===		= 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:		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.		* '''error''' - É uma mensagem de problemas encontrados no sistema, algo anormal que deve ser levado em consideração.
Linha 13:		Linha 15:
	* '''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.		* '''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.

	=== Registro de Mensagens Especiais ===		== 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.		* '''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 ===		== 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.		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 ===		== 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.		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 ==		= 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.		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.		É 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.
Linha 36:		Linha 38:


	== Configuração BISLogger ==		= Configuração BISLogger =

	O BISLogger deve ser configurado no servidor, através das propriedades de sistema abaixo:		O BISLogger deve ser configurado no servidor, através das propriedades de sistema abaixo:
Linha 100:		Linha 102:
	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.}}		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 ==		= 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 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.
Linha 134:		Linha 136:
	{{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.		{{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>".}}		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 =

			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.}}

Rodrigogml em 00h05min de 21 de março de 2015

2015-03-21T00:05:55Z

← Edição anterior		Edição das 00h05min de 21 de março de 2015
Linha 122:		Linha 122:
	}		}
	</syntaxhighlight>}}		</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.}}