de tais eventos. Anton Chuvakin e Gunnar Peterson sugerem os seguintes eventos:Autenticacao, autorizacao e acesso:Decisoes com falha ou sucesso relacionadas a autorizacao e autenticacao.Acesso a sistema, a dados e componentes; eAcesso remoto, incluindo aqueles entre componentes de uma mesma aplicacao em ambientes distribuidos.Mudancas:Mudancas em sistema ou aplicacao (especialmente quando envolva alteracao de privilegios).Mudancas de dados (incluindo a criacao e destruicao), eInstalacao e mudancas em componentes e aplicacoes.Problemas de disponibilidade:Inicio e encerramento de sistemas, aplicacoes e modulos ou componentes de aplicacoes, eSucesso e falhas de backup que afete disponibilidade.Problemas com recursos: Recursos excedendo suas capacidades.Problemas com conectividade.Limites estourados.Indicacao de ameacas:Entradas invalidas ou outros abusos da aplicacao.Outros problemas com a aplicacao que comprometa a sua operacao.E praticamente impossivel levantar todos os eventos de uma aplicacao, mas quanto mais ampla for a lista, mais condicoes se tem de conduzir a forma de elaboracao do registro. Definidos os eventos, voce pode estabelecer uma convencao de dados do registro relacionado a cada evento. Essa e uma forma de reduzir o poder discricionario do desenvolvedor em definir o conteudo do log, fonte patente de problemas.Definidos os eventos, e recomendavel usar uma forma de categorizacao dos registros do log. Tal categorizacao lhe permite priorizar sua atencao diante dos eventos produzidos pela aplicacao. A maneira amplamente difundida e pela sua prioridade ou criticidade, que na maioria dos casos varia de trace, nivel menos critico, ate fatal, nivel mais critico. A justificativa para cada categoria segue abaixo:FATAL apropriado para eventos que indiquem uma falha critica de servico. Se um servico emitir um erro FATAL, ele esta completamente incapaz de responder. Ex. Indisponibilidade total de um dos componentes-chave da aplicacao.ERRO apropriado para eventos que indiquem uma descontinuidade em uma requisicao ou habilidade do servico em responder. Um servico deve ter alguma capacidade de continuar a responder a requisicoes mesmo na presenca de ERROs. Os ERROs nao podem ser tolerados pela aplicacao e devem ser investigados imediatamente.AVISO apropriado para eventos que indiquem um erro nao critico em determinado servico. Erros resumidos ou brechas menores em requisicoes recaem sobre essa categoria. A distincao entre AVISO e ERRO e muito tenue. Um criterio simples e se a falha resulta em chamada de suporte pelo usuario. Caso a resposta seja positiva, escolha ERRO, caso contrario use AVISO. Os AVISOs podem ser tolerados pela aplicacao, mas devem sempre ser justificados e examinados. Ex. Aplicacao operando em modo debug. O console da aplicacao nao impoe controle de acesso.INFO apropriado para eventos do ciclo de vida de servicos e outras informacoes cruciais relacionadas. Mensagens INFO para uma determinada categoria de servico devem revelar qual o estado corrente do servico. Outra definicao de mensagens INFO, registram acoes que alteram significativamente o estado da aplicacao. Ex. Atualizacao do banco de dados, requisicao. DEBUG apropriado para mensagens que incorporam informacoes extras aos eventos de ciclo de vida. Informacao de desenvolvimento ou mais aprofundada necessaria para o suporte e a base para esta prioridade. Pode-se considerar a pilha de execucao e mensagens trocadas com sistemas externos a aplicacao.TRACE informacao muito detalhada de interesse de desenvolvedores. Tais mensagens sao mantidas por um periodo de