Estratégias para Monitorizar uma Nova Aplicação de Java

Aceitar todas as predefinições pode ser uma boa forma de iniciar a monitorização de uma aplicação sobre a qual o administrador tem muito pouco ou nenhum conhecimento. Em seguida, após monitorizar com todas as predefinições durante algum tempo, o administrador pode começar a ajustar as definições com base em alertas de monitorização, dados do Application Diagnostics e relatórios do Application Advisor. Para obter informações, consulte Como Monitorizar Aplicações de Java.

Definir um grupo de destino permite limitar a monitorização a um conjunto específico de servidores. Para implementações muito grandes de uma aplicação, normalmente, não é necessário monitorizar todas as instâncias da aplicação. Uma amostra representativa é suficiente para obter os dados necessários. Se utilizar apenas uma amostra representativa, manterá a quantidade de dados recolhidos e armazenados inferior.

Aumentar o limiar de sensibilidade permite filtrar métodos muito sensíveis, o que reduz o “ruído” geral e a profundidade de execução da pilha de chamadas, facilitando a identificação do local onde está o problema. Também reduz utilização de largura de banda de rede.

A definição de sensibilidade é utilizada para determinar se uma chamada de função deve constar da pilha de chamadas. Qualquer função que seja executada e devolvida mais rapidamente do que o nível de sensibilidade é ignorada, impedindo que funções muito sensíveis ocultem o problema real. Recorde que a utilização da sensibilidade apenas reduz o número de funções apresentadas na pilha de chamadas para eventos específicos, continuando a ser gerado um evento se o limiar global for ultrapassado.

Pode ajustar o limiar de sensibilidade no ficheiro de configuração, tal como descrito no Guia de Pacotes de Gestão para a Monitorização do Desempenho de Aplicações de Java.

Também é possível em alta sensibilidade para ocultar os problemas. Na situação em que uma função chama outra função, se o tempo de resposta do recetor da chamada aumentar, mesmo que apenas ligeiramente, podem ocorrer problemas na aplicação. Por exemplo, se uma função de processamento de dados chamar uma função de pesquisa 1.000 vezes e o tempo de processamento da função de pesquisa aumentar 1 ms, o tempo de resposta da função de nível superior aumentará um segundo. Isto poderá ser mascarado pela alta sensibilidade. Quando encontrar uma situação deste tipo, é possível adicionar o recetor como um método e definir uma sensibilidade personalizada para o mesmo, de modo a assegurar que o recetor é sempre medido de acordo com o limiar inferior de sensibilidade.

Os alertas de falha da aplicação são falhas da aplicação ou do código, que são detetados na aplicação. É possível escolher não receber alertas de falha da aplicação, que, potencialmente, podem ocorrer muito frequentemente se uma aplicação tiver problemas, porque este tipo de alertas costuma necessitar de modificações no código da aplicação para os resolver. Se desativar esta funcionalidade, reduzirá o "ruído" de muitos alertas desencadeados que não podem ser resolvidos diretamente pela equipa de operações.