Note al rilascio dell'analisi di prestazione e dei problemi

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

Note al rilascio

1.0 Limitazioni note, problemi, e soluzioni temporanee
   1.1 Impostazione del keystore e del truststore per le comunicazioni SSL durante l'importazione dei dati di profilo da IBM Tivoli Monitoring for Transaction Performance
   1.2 Problemi durante la disconnessione, e il passaggio degli indirizzi IP
   1.3 Supporto tipi di profilo
   1.4 Alcune transazioni non sono seguite durante la creazione dei profili
   1.5 Evitare di utilizzare percorsi lunghi o percorsi con spazi durante l'installazione su Windows Server 2003
   1.6 La raccolta dati non riesce su Windows Server 2003
   1.7 La registrazione della prova e la scoperta dinamica non riescono se viene utilizzata la raccolta dei dati protetta
   1.8 Restituzione dati mancanti
   1.9 Nessun dato disponibile per una verifica con strumentazione ARM appena eseguita
   1.10 Nessun errore per l'autenticazione non riuscita con IBM Tivoli Composite Application Manager for WebSphere
   1.11 La visualizzazione dei dati sparsi nella vista statistica potrebbe mostrare gli zero nel grafico
   1.12 Sincronizzazione orologio durante l'utilizzo di IBM Tivoli Composite Application Manager for WebSphere
   1.13 La modalità di inseguimento delle reimpostazioni vista statistica quando si collega con il programma di visualizzazione abilitato
   1.14 Problemi durante l'importazione di response time breakdown da più politiche e host in una singola importazione
   1.15 Errore di autenticazione IBM Tivoli Composite Application Manager for WebSphere
   1.16 L'infrastruttura di raccolta dati non riesce a trovare l'indirizzo IP corretto
   1.17 Piattaforma di verifica e di strumenti delle prestazioni
   1.18 Le modifiche all'orario solare influenzano IBM WebSphere Application Server
   1.19 La raccolta di response time breakdown non è disponibile dalla riga di comando
   1.20 Timeout o errore I/O durante l'importazione dei dati response time breakdown
   1.21 Il filtro viene mantenuto su tutte le tabelle di response time breakdown
   1.22 Errori durante l'arresto di server BEA WebLogic

1.0 Limitazioni note, problemi, e soluzioni temporanee

1.1 Impostazione del keystore e del truststore per le comunicazioni SSL durante l'importazione dei dati di profilo da IBM Tivoli Monitoring for Transaction Performance

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

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

1.2 Problemi durante la disconnessione, e il passaggio degli indirizzi IP

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.
 

1.3 Supporto tipi di profilo

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.

1.4 Alcune transazioni non sono seguite durante la creazione del profilo

Quando si creano profili per un'applicazione attiva, alcuni tipi di transazioni non vengono seguiti (non vengono creati i profili). Queste includono:

1.5 Evitare di utilizzare lunghi percorsi o percorsi durante l'installazione su Windows Server 2003

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. 

1.6 La raccolta dati non riesce su Windows Server 2003

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:
  1. Aprire il pannello dei servizi Windows selezionando Start > Impostazioni > Pannello di controllo > Strumenti di gestione > Servizi.
  2. Selezionare il servizio IBM Rational Agent Controller e arrestarlo.
  3. Selezionare Start > Impostazioni > Pannello di controllo > Sistema.
  4. Sulla scheda Avanzate, fare clic sulle variabili di ambiente.
  5. 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.
  6. Aprire un prompt dei comandi ed andare alla sottodirectory IBM_Agent_Controller\bin della directory di installazione.
  7. Eseguire raserver.exe.
  8. 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.

1.7 La registrazione della verifica e il rilevamento dinamico non riesce durante la raccolta dati sicura utilizzata

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. 

1.8 Restituire i dati mancanti

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.

1.9 Nessun dato disponibile per una verifica con strumentazione ARM appena eseguita

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:

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

Nota: Questa impostazione di riepilogo viene applicata ai dati di istanza. I dati aggregati non sono accurati fino a che non è passato un'ora.

1.10 Nessuna autenticazione non riuscita di errore con IBM Tivoli Composite Application Manager for WebSphere

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.

1.11 La visualizzazione dei dati sparsi nella vista statistica potrebbe mostrare gli zero nel grafico

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. 

1.12 Sincronizzazione orologio durante l'utilizzo di IBM Tivoli Composite Application Manager for WebSphere

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. 

1.13 La modalità di inseguimento delle reimpostazioni vista statistica quando si collega con il programma di visualizzazione abilitato

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. 

1.14Problemi durante l'importazione di response time breakdown da più politiche e host in una singola importazione

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.

1.15 Errore di autenticazione di IBM Tivoli Composite Application Manager for WebSphere

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.

1.16 L'infrastruttura di raccolta dati non riesce a trovare l'indirizzo IP 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:

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.

1.17 Piattaforma di verifica e degli strumenti delle prestazioni

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.

1.18 Le modifiche all'orario solare influenzano IBM WebSphere Application Server

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.

1.19 La raccolta di response time breakdown non è disponibile dalla riga dei comandi

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.

1.20 Errore di timeout o I/O durante l'importazione dei dati response time breakdown

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.

1.21 Il filtro viene mantenuto su tutte le tabelle di response time breakdown

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. 

1.22 Errori durante l'arresto di server BEA WebLogic

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.