© Copyright International Business Machines Corporation 2000, 2007. Tutti i diritti riservati. Limitazioni previste per gli utenti del Governo degli Stati Uniti - L'uso, la duplicazione o la divulgazione sono limitati dal GSA ADP Schedule Contract con la IBM Corp.
Per utilizzare la sicurezza SSL durante l'importazione dei dati di prestazione da TMTP, è necessario impostare il workbench per puntare i file keystore e truststore appropriati.
Se si è generato il proprio truststore e keystore da utilizzare con TMTP, allora utilizzare quei file in quanto segue. Altrimenti, utilizzare il file agent.jks predefinito fornito con TMTP Management Agent (tipicamente posizionato in C:\Program Files\ibm\tivoli\MA\config\keyfiles su Windows).
Copiare il file agent.jks da una macchina con l'installazione di Management Agent. Sulla macchina dove è installato il workbench, creare una sottodirectory di sicurezza della directory di installazione del toolkit. Inserire una copia del file agent.jks nella nuova directory di sicurezza.
Quindi, modificare il file rationalsdp.ini, che si trova nella directory di installazione del toolkit. Aggiungere le due seguenti righe:
VMArgs=-Djavax.net.ssl.trustStore=d:\myrpainstall\security\agent.jks
VMArgs=-Djavax.net.ssl.keyStore=d:\myrpainstall\security\agent.jksNota: Se il percorso d:\myrpainstall contiene uno spazio, utilizzare le virgolette prima e dopo il nome del percorso; ad esempio:
...trustStore="c:\Program Files\IBM\Rational\SDP\rpa\security\agent.jks"Riavviare il workbench. E' ora possibile utilizzare SSL durante l'importazione dei dati di creazione profilo da TMTP.
Se si prova a disconnettersi dalla rete, o si cambia l'indirizzo IP, o si passa tra le connessioni wireless e ethernet mentre si esegue qualsiasi tipo di profilo, o anche tra le sessioni di profilo, si sperimentano risultati non previsti.
Per correggere il problema, è necessario riavviare il workbench e i collettori di dati.
Alcune informazioni di connessione vengono memorizzate nella cache nel workbench per motivi di prestazione. Evitare di cambiare gli indirizzi IP, o arrestare tutto prima e riavviare quando si ottiene il nuovo IP.
Se il server di applicazioni viene configurato per essere utilizzato con l'infrastruttura di raccolta dei dati, solo i tipi J2EE Performance Analysis e ARM Performance Analysis e sono supportati. Se il server non è dotato di strumentazione, sono supportati tutti i tipi a parte J2EE Performance Analysis e ARM Performance Analysis.
Non è possibile utilizzare più di un tipo di profilo alla volta.
Se si desidera utilizzare altri tipi di profili, annullare la configurazione del server, riconfigurarlo come richiesto dal prodotto di base (Rational Application Developer, Rational Performance Tester o altri, come indicato nella guida all'installazione di quel prodotto), quindi creare il profilo. Per annullare la configurazione del server, fare riferimento all'argomento della guida online "Rimozione del virtualizzatore per supportare altri tipi di creazione del profilo." Per utilizzare di nuovo i tipi di creazione del profilo supportati, configurare il server per utilizzare l'infrastruttura di raccolta dati, seguendo le istruzioni nella guida di installazione.
Quando si creano profili per un'applicazione attiva, alcuni tipi di transazioni non vengono seguiti (non vengono creati i profili). Queste includono:
- Se un servlet genera un thread, e il nuovo thread si disattiva ed esegue alcune transazioni secondarie, allora non verrà tenuta traccia di queste nuove transazioni secondarie.
- Se un servlet viene reindirizzato o inoltrato, e questo reindirizzamento causa la generazione di un nuovo thread (anche se viene generato da un contenitore servlet), allora non verrà tenuta traccia degli eventi di transazione nel servlet reindirizzato.
Ci sono problemi noti intermittenti con l'installazione dell'infrastruttura di raccolta dati sulle macchine Windows Server 2003 che utilizzando percorsi lunghi o con spazi. Se possibile, evitare queste directory. Questo si applica non solo alla directory di installazione di destinazione, ma anche alla directory dalla quale si sta eseguendo l'installazione.
Se la raccolta dati non riesce su Windows 2003 Server, allora provare ad eseguire il componente Agent Controller come applicazione della console di un servizio Windows:
- Aprire il pannello dei servizi Windows selezionando Start > Impostazioni > Pannello di controllo > Strumenti di gestione > Servizi.
- Selezionare il servizio IBM Rational Agent Controller e arrestarlo.
- Selezionare Start > Impostazioni > Pannello di controllo > Sistema.
- Sulla scheda Avanzate, fare clic sulle variabili di ambiente.
- Fare clic su Nuovo (se la variabile RASERVER_HOME già esiste, fare clic su Modifica). Inserire RASERVER_HOME nel campo del nome variabile e x:\dir\IBM_Agent_Controller nel campo del valore, dove x:\dir\ è la directory di installazione. Fare clic su OK.
- Aprire un prompt dei comandi ed andare alla sottodirectory IBM_Agent_Controller\bin della directory di installazione.
- Eseguire raserver.exe.
- Riavviare l'infrastruttura di raccolta dati selezionando Start > Programmi > IBM Software Development Platform > IBM Rational Data Collection Infrastructure> Arresta il monitoraggio e quindi Avvia il monitoraggio.
La funzione di sicurezza dell'infrastruttura di raccolta dati è in conflitto con la registrazione di Rational Performance Tester e con il rilevamento dinamico della raccolta dati, e quindi non è supportata. Come un'alternativa per la sicurezza, utilizzare l'opzione Elenco host nell'installazione della raccolta dati e specificare un elenco specifico di host che possono accedere all'infrastruttura di raccolta dati sulla macchina corrente.
In alcuni casi, i dati restituiti dall'infrastruttura di raccolta dati potrebbero essere messaggi di restituzione mancanti e si ricevono solo le chiamate. Cioè, il diagramma Interazioni di classe UML2SD mostra solo frecce intere (chiamate), ma non a puntini (restituzioni).
Per risolvere temporaneamente questo problema, verificare che l'orologio sulla macchina remota sia impostato alla stessa ora o ad un'ora successiva rispetto alla macchina del workbench. Non è necessario modificare le impostazioni di fuso orario. Ad esempio, se l'ora locale della macchina remota è 7:30 e quella della macchina del workbench è 8:31 (e le ore sono corrette per il fuso orario in cui si trovano), semplicemente regolare l'ora sulla macchina remota 7:32, o impostare l'ora della macchina del workbench su 8:29.
Se non è possibile modificare le ore della macchina, inviare i dati di creazione profilo ad un file specifico nella pagina Destinazione nella finestra di dialogo di Avvio configurazione, e quindi importare quel file. Per i profili distribuiti dove ci sono più agenti, ogni agente deve essere collegato prima ed avere impostata l'opzione del file di creazione profili. Ogni agente dovrebbe creare il profilo su un file diverso.
Tivoli Monitoring for Transaction Performance Management Server è impostato per impostazione predefinita in modo da riepilogare i dati solo una volta all'ora. Questo significa che i dati vengono creati dalla verifica, ma non raccolti.
Se non si desidera attendere finché si verifica il rollup ogni ora, eseguire questi passaggi:Ora, i dati verranno riepilogati fino a Management Server ogni cinque minuti, così i dati dalla verifica di strumentazione saranno disponibili all'importazione nel toolkit un massimo di cinque minuti dopo aver eseguito la verifica.
Aprire il seguente file nella directory di installazione TMTP: config\autorollup.properties
Verificare che l'impostazione tms.autorollup.enable sia true.
Impostare tms.autorollup.period su 5, che significa cinque minuti, che è il valore minimo consentito. I valori inferiori a 5 saranno trattati come cinque minuti.
Per ogni politica a cui si desidera applicazione questo riepilogo automatico, aggiungere la riga di seguito riportata:
tms.autorollup.policyN=policy_name
Dove N è un numero intero che inizia con 1 (1, 2, 3, ecc.) e policy_name è il nome della politica. Il file autorollup.properties risultante appare nel modo seguente:
tms.autorollup.enable=true
tms.autorollup.period=5
tms.autorollup.policy1=myPolicy
tms.autorollup.policy2=yourPolicy
tms.autorollup.policy3=anotherPolicy
Arrestare e riavviare il TMTP Management Server.
Nota: Questa impostazione di riepilogo viene applicata ai dati di istanza. I dati aggregati non sono accurati fino a che non è passato un'ora.
Quando si importano i dati di prestazione da ITCAM for WebSphere (precedentemente WSAM), ci sono due livelli di autenticazione coinvolti. Il primo è l'autenticazione WebSphere che rifiuta ed invalida l'utente e la password sul sistema e provoca la visualizzazione nel toolkit di una finestra di dialogo di autenticazione. L'altro è ITCAM per l'autenticazione WebSphere che semplicemente non restituisce nessun dato disponibile all'importazione se l'autenticazione non riesce.
L'unico caso in cui l'autenticazione WebSphere passa e l'autenticazione ITCAM for WebSphere non riesce è quando l'utente immette un nome utente valido sul sistema operativo sottostante (ad es. root), ma quell'utente non è registrato in ITCAM for WebSphere. In questo caso, gli utenti dovrebbero essere consapevoli che il server non rileva un errore quando l'autenticazione non riesce, ma questi non vedono nessun trap disponibile dal quale importare.
La vista statistica, per impostazione predefinita, prova a tracciare un punto ad ogni spunta nel grafico delle statistiche. Se non esiste alcun punto per una spunta data, questo presuppone che il punto era zero. Se i punti sono troppo sparsi, questo risulta in una riga su zero ogni n punti. Questo è un artefatto creato dal grafico e non riflette ciò che sta effettivamente accadendo sul sistema. Per evitare questo artefatto, impostare il funzionamento su "non disegnare niente" o "disegna il valore precedente" nella finestra di dialogo "Altro..." per impostare le opzioni avanzate. Questo disegna delle righe a intervalli o continue dove non ci sono punti da tracciare.
Quando si importano i dati da una trap di IBM Tivoli Composite Application Manager for WebSphere, verificare che gli orologi del server di gestione ed del workbench siano sincronizzati. Nella procedura guidata di importazione di Tivoli Performance Data, l'opzione per importare le ultime unità di tempo n utilizza l'ora corrente sulla macchine locale, ma interroga le trap che hanno attività in quel periodo sull'orologio del server di gestione. In questo modo l'orologio del server di gestione va avanti di 10 minuti, quindi o si attendono 10 minuti prima che la procedura guidata di importazione trova questa transazione disponibile sul server, o si interrogano 10 minuti nel futuro.
Quando si visualizzano i dati di statistici di controllo delle risorse nella "Vista delle statistiche", se si dispone dell'opzione di attivazione/disattivazione del "Link con il programma di visualizzazione" abilitata nella vista "Controllo dei profili" e si seleziona un elemento diverso, la vista viene reimpostata e e attiva automaticamente l'opzione di attivazione/disattivazione della modalità di inseguimento dove il grafico segue l'ora corrente. Per risolvere temporaneamente questo problema, provare a visualizzare i dati sul nodo comune (ad esempio, il controllo) dove tutti i dati dagli agenti verranno visualizzati nello stesso grafico, o spegnere semplicemente l'opzione di inseguimento facendo clic sul pulsante ">" a destra del righello orizzontale.
Durante l'importazione di response time breakdown da IBM Tivoli Monitoring for Transaction Performance, IBM Tivoli Composite Application Manager for WebSphere, o IBM Tivoli Composite Application Manager for Response Time Tracking, è possibile selezionare più transazioni originate su più host ed importarle tutte a un'unica importazione. Esiste un difetto conosciuto che provoca la memorizzazione dei dati in un agente singolo mentre si mostrano due agenti, piuttosto che distribuire i dati appropriati a ogni agente. La soluzione temporanea è di importare per ogni host separatamente (eseguire tramite la procedura guidata di importazione una volta per ogni host, ogni volta che si seleziona solo un host).
Nota: in questo modo non viene interessata l'importazione delle transazioni distribuite, ma solo di quelle su host separati.
Durante l'importazione da IBM Tivoli Composite Application Manager for WebSphere, il nome utente e la password devono essere quelle utilizzate per accedere a IBM Tivoli Composite Application Manager for WebSphere Management Server, non quelle per WebSphere stesso. Se si utilizza il nome utente e la password WebSphere, l'importazione non riesce senza riportare che la causa è un'autenticazione no riuscita. Se il nome utente e la password non corrispondono a WebSphere stesso o a IBM Tivoli Composite Application Manager for WebSphere, viene mostrato il messaggio di autenticazione corretto.
Quando l'infrastruttura di raccolta di dati (DCI) parte, deve cercare l'indirizzo IP del computer locale. Il DCI utilizza una chiamata InetAddress.getLocalHost() per eseguire questa ricerca. Questa chiamata non restituisce sempre l'indirizzo IP corretto. Un indirizzo IP non corretto impedisce alla funzione di scoperta dinamica di funzionare correttamente. L'indirizzo IP non corretto può essere restituito in diverse situazioni:
- Su Linux, la chiamata talvolta restituisce 127.0.0.1. Questo è un difetto noto in JVM: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4665037.
- Sui computer con diversi adattatori installati dove si collega a una diversa rete. Ad esempio, un adattatore di rete può connettersi a una rete pubblicamente accessibile, mentre un altro adattatore potrebbe collegarsi a una rete privata.
- Sui computer con voci non corrette nei file HOSTS.
Se si verifica questo problema, un errore serio verrà scritto nel file RPA_MA.log nella directory <DCI_INSTALL>/rpa_prod/rpa_comp/logs. Il file di registro è specificato dall'argomento JVM -Djava.util.logging.FileHandler.pattern=<filename> .
Per risolvere questo problema, specificare l'indirizzo IP del computer manualmente. Aggiungere una riga al file <DCI_INSTALL>/rpa_prod/rpa_comp/rpa.properties:
IP_ADDRESS=-Dcom.ibm.rpa.runtime.ip=<indirizzo IP>
Ad esempio, se l'indirizzo IP del computer è 9.67.50.44, aggiungere la riga
IP_ADDRESS=-Dcom.ibm.rpa.runtime.ip=9.67.50.44
Riavviare il DCI dopo aver eseguito le modifiche a rpa.properties.
Gli strumenti di analisi delle prestazioni e dei problemi utilizzano TPTP (Test and Performance Tools Platform). Le note di rilascio e l'altra documentazione per TPTP è disponibile alla paginahttp://www.eclipse.org/tptp/home/documents/index.html.
Se si sta controllando WebSphere Application Server con IBM Tivoli Monitoring, applicare la correzione appropriata presente inhttp://www-1.ibm.com/support/docview.wss?rs=180&context=SSEQTP&q1=1219396&uid=swg21219396&loc=en_US&cs=utf-8&lang=en WebSphere Application Server. Queste correzioni devono essere applicate al server per risolvere i problemi alla modifica dell'orario solare.
Se si esegue un pianificazione dalla riga dei comandi con la raccolta di response time breakdown abilitata, nessun dato di response time breakdown verrà raccolto. Per raccogliere i dati di response time breakdown da una pianificazione, eseguire la pianificazione dall'interfaccia grafica del workbench.
Quando si importano i dati response time breakdown da un server Tivoli Monitoring, è possibile notare uno dei seguenti messaggi di errore:
IWAY0084E Si è verificato un timeout di comunicazione.
IWAY0106E Si è verificato un errore I/O durante l'importazione dei dati delle prestazioni Tivoli.
Inoltre, le pagine della procedura guidata di importazione potrebbero essere vuote. WebSphere Application Server accede al computer mentre Tivoli Monitoring si trova e possibile mostrare un OutOfMemoryError. Questo problema si verifica se mentre si prova a importare un grosso quantitativo di dati. Per risolvere il problema, restringere l'intervallo di tempo per il quale si prova a importarei dati.
Se si applica un filtro alla tabella di response time breakdown per un determinato elemento di una pagina, tale filtro sarà impostato su tutte le tabelle response time breakdown che verranno aperte successivamente. Questo filtro viene mantenuto per tutti gli altri elementi di pagina in tutte le altre verifiche e pianificazioni. Poiché viene mantenuto questo filtro per tutte le tabelle, è possibile che venga raccolta soltanto una parte dei dati previsti. Se il filtro non viene applicato alle transazioni successive allora la tabella potrebbe essere visualizzata come vuota, dando così l'impressione all'utente che non sono stati raccolti dati. La soluzione consiste nel rimuovere i filtri per un determinato elemento di pagina prima di aprire i risultati di response time breakdown per un altro elemento.
Application Server Instrumenter modifica gli script di avvio e arresto su server BEA WebLogic mentre il server è in esecuzione. Immediatamente dopo la strumentazione o l'annullamento della strumentazione, è possibile che si verifichino degli errori quando si arresta il server. Questi possono essere messaggi di errore visualizzati sulla console BEA WebLogic o un comportamento non previsto per cui il server viene riavviato prima di essere arrestato completamente. Questi errori si verificano perché il processo del server attivo viene avviato con lo script di avvio originale, ma viene arrestato con lo script di arresto modificato.
Per risolvere questo problema, verificare che il server BEA WebLogic venga arrestato completamente e riavviato mediante lo script di avvio modificato. Potrebbe essere necessario arrestare il server BEA WebLogic due volte.