© Copyright International Business Machines Corporation 2000, 2007. Todos direitos reservados. Direitos Restritos a Usuários do Governo dos Estados Unidos - Uso, duplicação e divulgação restritos pelo documento GSA ADP Schedule Contract com a IBM Corporation.
Para utilizar a segurança SSL ao importar dados de desempenho do TMTP, é necessário configurar o ambiente de trabalho para apontar para os arquivos de armazenamento de chave e truststore apropriados.
Se você gerou seu próprio truststore e armazenamento de chave para ser utilizado com o TMTP, utilize esses arquivos conforme a seguir. Caso contrário, utilize o arquivo agent.jks padrão fornecido com o Agente de Gerenciamento TMTP (geralmente localizado em C:\Program Files\ibm\tivoli\MA\config\keyfiles no Windows).
Copie o arquivo agent.jks de uma máquina com a instalação do Agente de Gerenciamento. Na máquina na qual o ambiente de trabalho está instalado, crie um subdiretório de segurança no diretório de instalação do toolkit. Coloque uma cópia do arquivo agent.jks no novo diretório de segurança.
Em seguida, edite o arquivo rationalsdp.ini, localizado no diretório de instalação do toolkit. Inclua as duas linhas a seguir:
VMArgs=-Djavax.net.ssl.trustStore=d:\myrpainstall\security\agent.jks
VMArgs=-Djavax.net.ssl.keyStore=d:\myrpainstall\security\agent.jksNota: Se o caminho d:\myrpainstall contiver um espaço, utilize aspas em torno do caminho e do nome do arquivo; por exemplo:
...trustStore="c:\Program Files\IBM\Rational\SDP\rpa\security\agent.jks"Reinicie o ambiente de trabalho. Agora você poderá utilizar o SSL ao importar dados de traçado de perfil do TMTP.
Se você tentar desconectar da rede, comutar endereços IP ou comutar entre conexões wireless e ethernet ao realizar qualquer tipo de traçado de perfil, ou mesmo entre as sessões de traçado de perfil, ocorrerão resultados indesejáveis.
Para corrigir o problema, você deve reiniciar o ambiente de trabalho e os coletores de dados.
Por motivos de desempenho, algumas informações de conexão são armazenadas em cache no ambiente de trabalho. Evite comutar endereços IP ou encerrar tudo antecipadamente e reiniciar quando obtém o novo IP.
Se o servidor de aplicativos estiver configurado para uso com a infra-estrutura de coleta de dados, apenas os tipos de Análise de Desempenho J2EE e Análise de Desempenho ARM são suportados. Se o servidor não for instrumentado, todos os tipos serão suportados, com exceção de Análise de Desempenho J2EE e Análise de Desempenho ARM.
Não é possível utilizar mais de um tipo de traçado de perfil ao mesmo tempo.
Se desejar utilizar outros tipos de perfil, você deverá desconfigurar o servidor, reconfigurá-lo conforme requerido pelo produto base (Rational Application Developer, Rational Performance Tester ou outro, conforme indicado no guia de instalação daquele produto) e, em seguida, executar o traçado de perfil. Para desconfigurar o servidor, consulte o tópico da ajuda on-line "Removendo o Virtualizador para Suportar Outros Tipos de Perfis." Para utilizar os tipos de gerenciamento de perfis suportados novamente, você deve configurar o servidor para utilizar a infra-estrutura de coleta de dados, seguindo as instruções no guia de instalação.
Ao traçar o perfil de um aplicativo ativo, alguns tipos de transações não são seguidas (o perfil não é traçado). Isso inclui:
- Se um servlet efetuar spawn de um encadeamento e o novo encadeamento desaparecer e executar algumas subtransações, essas novas subtransações não são rastreadas.
- Se um servlet for redirecionado e esse redirecionamento causar spawn de um novo encadeamento (mesmo se o spawn do encadeamento for efetuado pelo contêiner do servlet), nenhum evento de transação no servlet redirecionado é rastreado.
Existem problemas intermitentes conhecidos com a instalação da infra-estrutura de coleta de dados em máquinas com o Windows Server 2003 que utilizam caminhos longos ou caminhos com espaços. Evite esses tipos de diretório, se possível. Isso se aplica não apenas ao diretório de instalação de destino, mas também ao diretório do qual a instalação está sendo feita.
Se houver falha na coleta de dados no Windows 2003 Server, tente executar o componente do Agent Controller como um aplicativo de console, em vez de como um serviço Windows:
- Abra o painel Serviços do Windows, selecionando Iniciar > Configurações > Painel de Controle > Ferramentas Administrativas > Serviços.
- Selecione o serviço IBM Rational Agent Controller e pare-o.
- Selecione Iniciar > Configurações > Painel de Controle > Sistema.
- Na guia Avançado, clique em Variáveis de Ambiente.
- Clique em Novo (se a variável RASERVER_HOME já existir, clique em Editar). Digite RASERVER_HOME no campo Nome da Variável e x:\dir\IBM_Agent_Controller no campo Valor da Variável, em que x:\dir\ é o diretório de instalação. Clique em OK.
- Abra um prompt de comandos e vá para o subdiretório IBM_Agent_Controller\bin do diretório de instalação.
- Execute o raserver.exe.
- Reinicie a infra-estrutura de coleta de dados, selecionando Iniciar > Programas > IBM Software Development Platform > IBM Rational Data Collection Infrastructure > Parar Monitoramento e, em seguida, Iniciar Monitoramento.
O recurso de segurança da infra-estrutura de coleta de dados entra em conflito com o registro do Rational Performance Tester e com a descoberta dinâmica da coleta de dados e, portanto, não é suportado. Como alternativa para a segurança, utilize a opção Lista de Hosts na instalação da coleta de dados e especifique uma lista de hosts específicos que podem acessar a infra-estrutura da coleta de dados na máquina atual.
Em alguns casos, os dados retornados da infra-estrutura de coleta de dados podem perder mensagens de retorno e você receber apenas chamadas. Isto é, o diagrama de Interações de Classes UML2SD mostra apenas setas sólidas (chamadas), mas não setas pontilhadas (retornos).
Como solução alternativa para esse problema, verifique se o relógio na máquina remota está configurado para o mesmo horário ou para um horário posterior ao da máquina do ambiente de trabalho. Não é necessário alterar as configurações de fuso horário. Por exemplo, se a hora local da máquina remota for 7:30 e a da máquina do ambiente de trabalho for 8:31 (e os horários estiverem corretos para os fusos horários em que estão, uma hora de diferença), basta ajustar a hora na máquina remota para 7:32 ou configurar a hora da máquina do ambiente de trabalho para 8:29.
Caso não seja possível alterar os horários das máquinas, envie os dados de gerenciamento de perfis para um arquivo especificado na página Destino no diálogo Configuração de Ativação e, em seguida, importe esse arquivo. Para traçado de perfil distribuído, em que há vários agentes, cada agente deve estar conectado com antecedência e ter a opção do arquivo de traçado de perfil configurada. Cada agente deve traçar o perfil para um arquivo diferente.
Por padrão, o Tivoli Monitoring para Transaction Performance Management Server é configurado para mover dados apenas uma vez a cada hora. Isso significa que os dados de seu teste são criados, mas não são coletados.
Se não desejar aguardar até que a movimentação horária ocorra, execute o seguinte:Agora, os dados serão movimentados para o Servidor de Gerenciamento a cada cinco minutos, portanto os dados do teste instrumentado estarão disponíveis para importação no toolkit no máximo em cinco minutos após a execução do teste.
Abra o seguinte arquivo no diretório de instalação do TMTP: config\autorollup.properties
Certifique-se de que a definição de tms.autorollup.enable seja true.
Configure a definição de tms.autorollup.period como 5, indicando cinco minutos, que é o valor mínimo permitido. Valores menores que cinco serão tratados como cinco minutos.
Para cada política à qual você deseja que essa definição de autorollup seja aplicada, inclua a seguinte linha:
tms.autorollup.policyN=policy_name
Em que N é um inteiro, iniciando em 1 (1, 2, 3, etc.) e policy_name é o nome da política. O arquivo autorollup.properties resultante será semelhante a este:
tms.autorollup.enable=true
tms.autorollup.period=5
tms.autorollup.policy1=myPolicy
tms.autorollup.policy2=yourPolicy
tms.autorollup.policy3=anotherPolicy
Pare e reinicie o Servidor de Gerenciamento do TMTP.
Nota: Esta definição de movimentação é aplicada aos dados da instância. Dados agregados serão imprecisos até que a hora tenha decorrido.
Ao importar os dados de desempenho do ITCAM para WebSphere (anteriormente WSAM), há duas camadas de autenticação envolvidas. A primeira é a autenticação do WebSphere, que rejeitará e invalidará o usuário/senha no sistema e fará com que o toolkit exiba uma caixa de diálogo de autenticação. O outro é autenticação do ITCAM para WebSphere, que simplesmente não retornará dados disponíveis para importação se a autenticação falhar.
O único caso em que a autenticação do WebSphere será transmitida e a autenticação do ITCAM para WebSphere falhará é quando o usuário digitar um nome de usuário válido no sistema operacional básico (por exemplo, root), mas esse usuário não está registrado no ITCAM para WebSphere. Nesse caso, os usuários devem estar conscientes de que o servidor não emitirá um erro quando a autenticação falhar; em vez disso, eles não verão interrupções disponíveis para importação.
A visualização estatística, por padrão, tenta fazer o plot de um ponto a cada pulso no gráfico estatístico. Se não houver ponto para um determinado pulso, ele assumirá que o ponto era zero. Se os pontos estiverem muito espalhados, isso resultará em uma linha para zero a cada nº ponto. Isso é um artefato criado pelo gráfico e não reflete o que realmente está acontecendo no sistema. Para evitar esse artefato, configure o comportamento para "inserir nada" ou "inserir valor anterior" no diálogo "Mais..." para configurar opções avançadas. Isso fará com que sejam inseridas lacunas ou linhas contínuas diretas onde não houver pontos para o plot.
Ao importar dados de uma interrupção do IBM Tivoli Composite Application Manager para WebSphere, certifique-se de que os relógios do servidor de gerenciamento e do workbench estejam sincronizados. No assistente de importação de Dados de Desempenho da Tivoli, a opção para importar as últimas unidades n de tempo utiliza a hora atual na máquina local, mas consulta as interrupções que possuem atividade nesse período de tempo no relógio do servidor de gerenciamento. Portanto, se o relógio do servidor de gerenciamento estiver adiantado 10 minutos, você terá que esperar 10 minutos antes do assistente de importação localizar a transação disponível no servidor ou fazer a consulta 10 minutos posteriormente.
Ao visualizar os dados estatísticos de monitoramento do recurso na "Visualização Estatística", se você tiver a opção de comutação "Link com Visualizador" ativada na visualização "Monitor de Gerenciamento de Perfis" e selecionar um item diferente, a visualização será reconfigurada e ativará automaticamente a opção de comutação do modo de acompanhamento, onde o gráfico segue a a hora atual. Para solucionar o problema, tente visualizar os dados em um nó comum (por exemplo, o monitor) onde todos os dados dos agentes serão exibidos no mesmo gráfico ou simplesmente desative a opção de modo de acompanhamento clicando no botão ">" à direita das réguas horizontais.
Ao importar dados de interrupção do tempo de resposta do IBM Tivoli Monitoring para Transaction Performance, IBM Tivoli Composite Application Manager para WebSphere ou IBM Tivoli Composite Application Manager for Response Time Tracking, é possível selecionar múltiplas transações que se originaram de múltiplos hosts e importar todas de uma única vez. Há um defeito conhecido que faz com que os dados sejam armazenados em um único agente enquanto mostra dois agentes, em vez de distribuir os dados apropriados para cada agente. A solução alternativa é importar para cada host separadamente (executar pelo assistente de importação uma vez para cada host, selecionando em cada vez somente um host).
Nota: Isso não afeta as transações distribuídas de importação, somente importa as múltiplas transações que se originaram nos hosts separados.
Ao importar do IBM Tivoli Composite Application Manager para WebSphere, o nome do usuário/senha devem ser aqueles utilizados para efetuar login no IBM Tivoli Composite Application Manager para WebSphere Management Server, não o nome do usuário/senha do próprio WebSphere. Se você utilizar o nome do usuário/senha do WebSphere, a importação falhará sem relatar qual autenticação de falha foi a razão. Se o nome do usuário/senha não corresponderem ao próprio WebSphere ou ao IBM Tivoli Composite Application Manager para WebSphere, a mensagem correta de falha de autenticação será mostrada.
Quando a DCI (Infra-estrutura de Coleta de Dados) inicia, ela deve buscar o endereço IP do computador local. A DCI utiliza uma chamada para InetAddress.getLocalHost() para desempenhar esta consulta. Esta chamada nem sempre retorna o endereço IP correto. Um endereço IP incorreto evitará que o recurso de descoberta dinâmica funcione corretamente. O endereço IP incorreto pode ser retornado em situações diferentes:
- No Linux, a chamada muitas vezes retorna 127.0.0.1. Esse é um defeito conhecido na JVM: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4665037.
- Em computadores com vários adaptadores de rede instalados, onde cada adaptador conecta-se a uma rede diferente. Por exemplo, um adaptador de rede pode estar conectado a uma rede de acesso público, enquanto outro adaptador pode estar conectado a uma rede privada.
- Em computadores com entradas incorretas nos arquivos HOSTS.
Se esse problema ocorrer, um erro crítico será gravado no arquivo RPA_MA.log no diretório <DCI_INSTALL>/rpa_prod/rpa_comp/logs. (O arquivo de log é especificado pelo argumento da JVM -Djava.util.logging.FileHandler.pattern=<filename> ).
Para obter uma solução alternativa a este problema, especifique o endereço IP de seu computador manualmente. Inclua uma linha no arquivo <DCI_INSTALL>/rpa_prod/rpa_comp/rpa.properties:
IP_ADDRESS=-Dcom.ibm.rpa.runtime.ip=<IP address>
Por exemplo, se o endereço IP do computador for 9.67.50.44, você deve incluir a linha
IP_ADDRESS=-Dcom.ibm.rpa.runtime.ip=9.67.50.44
Reinicie a DCI após fazer a alteração em rpa.properties.
As ferramentas de análise de desempenho e de problemas utilizam a TPTP (Test and Performance Tools Platform - Plataforma de Ferramentas de Teste e Desempenho). Notas sobre o release e outra documentação para a TPTP podem ser localizadas em http://www.eclipse.org/tptp/home/documents/index.html.
Se você está monitorando o WebSphere Application Server utilizando o IBM Tivoli Monitoring, é necessário aplicar a correção apropriada, listada em http://www-1.ibm.com/support/docview.wss?rs=180&context=SSEQTP&q1=1219396&uid=swg21219396&loc=en_US&cs=utf-8&lang=en para o WebSphere Application Server. Essas correções devem ser aplicadas ao servidor para resolver os problemas relacionados à alteração do horário de verão.
Se você executar um planejamento a partir da linha de comandos com a coleta de interrupções de tempo de resposta ativada, os dados de interrupção do tempo de resposta não serão coletados. Para coletar os dados de interrupção do tempo de resposta de um planejamento, execute o planejamento a partir da interface gráfica do ambiente de trabalho.
Ao importar os dados de interrupção do tempo de resposta de um Tivoli Monitoring server, você pode consultar uma das seguintes mensagens de erro:
IWAY0084E Ocorreu um tempo limite de comunicação.
IWAY0106E Ocorreu um erro de E/S ao importar os dados de desempenho do Tivoli.
Além disso, as páginas do assistente de importação podem aparecer em branco. O WebSphere Application Server que efetua logon no computador onde o Tivoli Monitoring está localizado pode mostrar um OutOfMemoryError. Este problema pode ocorrer se estiver tentando importar uma grande quantidade de dados. Para buscar uma solução alternativa a este problema, restrinja o intervalo de tempo que está tentando importar os dados.
Se você aplicar um filtro à tabela de interrupção do tempo de resposta para um elemento da página particular, esse filtro será configurado em todas as tabelas de interrupção do tempo de resposta que você abrir posteriormente. Esse filtro persiste para todos os outros elementos da página em todos os outros testes e planejamentos. Como esse filtro persiste para todas as tabelas de interrupção do tempo de resposta, pode parecer que um subconjunto dos dados esperados foi coletado. Se o filtro não se aplicar às transações subseqüentes, a tabela poderá aparecer em branco, dando a impressão de que nenhum dado foi coletado. A solução alternativa é remover todos os filtros para um elemento da página particular antes de abrir os resultados da interrupção do tempo de resposta para outro elemento da página.
O Application Server Instrumenter modifica os scripts de início e parada nos servidores WebLogic BEA enquanto o servidor está em execução. Imediatamente depois da instrumentação ou da remoção da instrumentação, podem ocorrer erros quando você pára o servidor. Esses podem ser mensagens de erro exibidas no console do WebLogic BEA ou um comportamento inesperado em que o servidor é reiniciado antes de ser encerrado completamente. Esses erros ocorrem porque o processo do servidor ativo foi iniciado com o script de início original, mas está parando com o script de parada modificado.
Para obter uma solução alternativa para esse problema, certifique-se de que o servidor WebLogic BEA pare completamente e seja reiniciado utilizando o script de início modificado. Talvez seja necessário parar o servidor WebLogic BEA duas vezes.