Questa pagina è stata tradotta dall'API Cloud Translation.

Impossibile creare la sessione di traccia

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. informazioni

Sintomo

L'utente non è in grado di creare una sessione di traccia nella UI di Edge.

Messaggio di errore

Visualizzerai un messaggio di errore nella UI di Edge, come mostrato di seguito:

Error creating trace session for API proxy <api proxy name>, revision <revision number>, environment <environment name>.
Failed to create DebugSession <session number>

Ecco lo screenshot di un esempio di messaggio di errore osservato nella UI di Edge:

Possibili cause

Alcune delle possibili cause di questo errore sono elencate di seguito:

Causa	Descrizione	Istruzioni per la risoluzione dei problemi applicabili a
Problema di connettività di rete	Errore di comunicazione tra il server di gestione e il processore di messaggi a causa di problemi di connettività di rete o regole firewall.	Utenti del cloud privato perimetrale
Ambiente non caricato sul processore di messaggi	L'ambiente specifico (in cui si sta tentando di abilitare la traccia) non è stato caricato nel processore di messaggi a causa di un errore.
Voci del processore di messaggi inattivi	Il server di gestione fa riferimento a processori di messaggi inesistenti (inattivi).
Processore di messaggi non raggiungibile	Il processore di messaggi è stato interrotto o non è più raggiungibile.
Problema di utilizzo elevato delle risorse	Uno o più processori di messaggi stanno riscontrando un elevato utilizzo di risorse (CPU, memoria o carico).
Impossibile eseguire il deployment del proxy API su uno o più processori di messaggi	Potrebbe non essere eseguito il deployment del proxy API su uno o più processori di messaggi a causa della mancata notifica degli eventi durante il deployment.
Problema con l'interfaccia utente Edge	La UI di Edge non è in grado di creare una sessione di traccia a causa di un errore.

Passaggi di diagnosi comuni

Esegui questa API di gestione:

curl -v <management-server-host>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/apis/<apiproxy-name>/revisions/<revision-number>/debugsessions -u <user>

Se si verificano errori, indicali. Passa a Problema di connettività di rete.
Se ottieni una risposta corretta, significa che la sessione di traccia può essere creata tramite l'API di gestione. Tuttavia, potrebbe esserci un problema con l'interfaccia utente Edge, a causa dell'impossibilità di creare una sessione di traccia nell'interfaccia utente. Passa a Problema con l'interfaccia utente Edge.

Causa: problema di connettività di rete

Diagnosi

Controlla il log del server di gestione /opt/apigee/var/log/edge-management-server/logs/system.log e verifica se sono presenti errori durante la creazione della sessione di traccia/debug.

Esempio di errore dal log del server di gestione

2018-02-08 09:08:21,310 org:myorg env:uat  qtp1073741635-1074 ERROR DISTRIBUTION - DebugSessionAPI.createDebugSession() : createDebugSession : Unable to connect to the server with UUID cedeabd2-e4d1-40bb-8f18-d6afc8835e5b
org.apache.http.conn.HttpHostConnectException: Connect to 10.84.75.92:8082 [/10.84.75.92] failed: Connection refused
    at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:140) ~[httpclient-4.3.5.jar:4.3.5]
    at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:318) ~[httpclient-4.3.5.jar:4.3.5]
    at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363) ~[httpclient-4.3.5.jar:4.3.5]
...<snipped>
Caused by: java.net.ConnectException: Connection refused
    at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_65]
    at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[na:1.8.0_65]
...<snipped>

L'errore di esempio riportato sopra mostra che vengono visualizzati errori "Connessione rifiutata" quando il server di gestione tenta di connettersi al processore di messaggi sulla porta n. 8082. Di conseguenza, il server di gestione non è in grado di creare la sessione di traccia.
Se non vedi errori relativi alla connettività di rete o un errore simile a quello mostrato nell'esempio precedente, passa a Ambiente non caricato sul processore di messaggi.
Se si verificano errori relativi alla connettività di rete o simili a quelli mostrati nell'esempio precedente, segui questi passaggi.
Verifica la connettività dal server di gestione al processore di messaggi sulla porta 8082 seguendo questi passaggi:
1. Se è disponibile telnet, utilizza telnet:
```
telnet <MessageProcessor_IP> 8082
```
2. Se Telnet non è disponibile, utilizza netcat per verificare la connettività come segue:
```
nc -vz <MessageProcessor_IP> 8082
```
3. Se viene visualizzata la risposta "Connessione rifiutata" o "Timeout della connessione", vai al passaggio successivo.
Accedi a ciascuno dei processori di messaggi con l'indirizzo IP corrispondente che ha mostrato l'errore ed esegui i seguenti passaggi:
1. Controlla se il processore di messaggi è in ascolto sulla porta 8082:
```
netstat -an | grep LISTEN | grep 8082
```
2. Se il processore di messaggi è in ascolto sulla porta 8082, passare al punto 7.
3. Se il processore di messaggi non è in ascolto sulla porta 8082, riavvialo utilizzando questo comando:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
4. Attendi che il processore di messaggi sia completamente avviato utilizzando questo comando:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor wait_for_ready
```
5. Una volta attivato il processore di messaggi, ricontrolla se è in ascolto sulla porta 8082.
6. Se il processore di messaggi è in ascolto sulla porta 8082, passare al punto 7.
Verifica se ora è possibile avviare la sessione di traccia nell'interfaccia utente. Se il problema non si verifica più, salta i passaggi seguenti.
Se il processore di messaggi è in esecuzione e in ascolto sulla porta 8082, ma non riesci ancora a connetterti dagli altri server, ad esempio dal server di gestione, è probabile che sia presente un firewall che blocca le connessioni esterne.
Utilizza il comando appropriato per verificare le regole del firewall. Ad esempio, potresti eseguire il comando iptables per elencare tutte le regole firewall definite nel tuo sistema:
```
iptables -L -n
```
Se non sono state impostate regole firewall per la porta 8082, passa a Problema di utilizzo elevato delle risorse.
Se sulla porta 8082 sono configurate regole firewall, passa alla sezione Risoluzione qui sotto.

Risoluzione

Collabora con l'amministratore di rete per consentire il traffico in entrata/uscita dai server esterni sulla porta 8082.

Se il problema persiste, vai alla pagina Devi raccogliere informazioni diagnostiche.

Causa: ambiente non caricato nel processore di messaggi

Diagnosi

Controlla i log del server di gestione /opt/apigee/var/log/edge-management-server/logs/system.log e controlla se si sono verificati errori durante la creazione della sessione di traccia/debug.

Durante la creazione della sessione di traccia/debug, potrebbe essere visualizzato un messaggio di errore come "nessuna risposta valida da parte di MP":

2018-01-30 08:28:09,721 org:mynonprod env:uat  qtp2007599722-712162 ERROR DISTRIBUTION - DebugSessionAPI.createDebugSession() : no valid responses from MP(s), throwing error
2018-01-30 08:28:09,723 org:mynonprod env:uat  qtp2007599722-712162 ERROR REST - CustomJAXRSInvoker.performInvocation() : CustomJAXRSInvoker.performInvocation : Method com.apigee.distribution.DebugSessionAPI.createDebugSession threw an exception.
2018-01-30 08:28:09,724 org:mynonprod env:uat  qtp2007599722-712162 ERROR REST - ExceptionMapper.toResponse() : Error occurred : Failed to create DebugSession 1517297564678
2018-01-30 08:28:09,724 org:mynonprod env:uat  qtp2007599722-712162 ERROR REST - ExceptionMapper.toResponse() : Returning error response : ErrorResponse{errorCode = distribution.CreateDebugSessionFailed, errorMessage = Failed to create DebugSession 1517297564678}

Questo errore indica che per qualche motivo i processori di messaggi non rispondono al server di gestione.

Se non visualizzi un errore simile a quello mostrato nell'esempio precedente, vai alle Voci del processore di messaggi inattivi.
Se riscontri un errore simile a quello mostrato nell'esempio precedente, segui questi passaggi.
Una delle cause più probabili di questo errore è che l'ambiente in cui si sta tentando di creare la sessione di traccia non viene caricato sui processori di messaggi.
Accedi a ciascuno dei processori di messaggi e controlla se l'ambiente specifico in cui si sta tentando di creare la sessione di traccia è caricato sul processore di messaggi utilizzando il comando seguente:
```
curl -s http://localhost:8082/v1/runtime/organizations/<org-name>/environments
```
Output di esempio:

Vedrai l'elenco degli ambienti appartenenti all'organizzazione specifica caricati sul processore di messaggi nell'output del comando precedente. Ad esempio, se gli ambienti preprod e test vengono caricati sul processore di messaggi, l'output verrà visualizzato come segue:

[ "preprod", "test" ]
Se l'ambiente specifico, pronuncia "dev", in cui stai tentando di creare una sessione di traccia, è elencato come parte del comando precedente, quindi passa alle Voci del processore di messaggi inattivi.
Se l'ambiente specifico, pronuncia "dev", non è elencato come parte del comando riportato sopra, verifica la presenza di eventuali errori in /opt/apigee/var/log/edge-message-processor/logs/system.log e /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log sui processori di messaggi durante il caricamento degli ambienti.
Potrebbero esserci molti errori diversi che potrebbero portare al mancato caricamento di un ambiente sul processore di messaggi. La risoluzione dipende dall'errore che si è verificato.

Risoluzione

L'ambiente potrebbe non essere caricato sul processore di messaggi per diversi motivi. Questa sezione illustra un paio di possibili motivi che possono causare questo problema e spiega come risolverlo.

Se nel log del processore di messaggi viene visualizzato uno dei seguenti errori, la causa è un problema rilevato con i certificati/le chiavi che sono stati aggiunti all'archivio chiavi o all'archivio attendibilità specificato nell'ambiente specificato.

Errore 1: java.security.KeyStoreException: impossibile sovrascrivere il proprio certificato

2018-01-30 12:04:38,248 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator 
com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mycert in key store : mytruststore in environment : test
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na] 
at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na] 
at com.apigee.entities.AbstractConfigurator.propagateEvent(AbstractConfigurator.java:85) ~[config-entities-1.0.0.jar:na] 
at com.apigee.messaging.runtime.Environment.handleUpdate(Environment.java:238) [message-processor-1.0.0.jar:na] 
… 
Caused by: java.security.KeyStoreException: Cannot overwrite own certificate 
at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:355) ~[sunjce_provider.jar:1.8.0_151] 
at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_151] 
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]
... 20 common frames omitted
2018-01-30 12:04:38,250 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

Errore 2: java.security.KeyStoreException: impossibile sovrascrivere la chiave segreta

2017-11-01 03:28:47,560 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator 
com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mstore in key store : myTruststore in environment : dev 
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na] 
at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na] 
... 
Caused by: java.security.KeyStoreException: Cannot overwrite secret key 
at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:354) ~[sunjce_provider.jar:1.8.0_144] 
at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_144] 
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na] 
... 20 common frames omitted 

2017-11-01 03:28:47,562 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

Recupera i dettagli dell'archivio chiavi/dell'archivio attendibilità specificato nel messaggio di errore mostrato nel passaggio precedente utilizzando la seguente chiamata API di gestione:

curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user>

Output di esempio:

{ 
"certs": [ 
"mycert", 
"mycert-new" 
], 
"keys": [ 
"mycert" 
], 
"name": "myTruststore" 
}

L'output di esempio mostra che ci sono due certificati e una chiave nell'archivio attendibilità myTruststore. In genere l'archivio attendibilità non contiene una chiave. Se sì, è meglio avere un singolo certificato e un'unica chiave.

Ottieni i dettagli sui due certificati utilizzando la seguente API:

curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>

Controlla la data di scadenza di ciascuno dei certificati e determina se il certificato è scaduto o meno.
Elimina il certificato scaduto o indesiderato dall'archivio attendibilità "myTruststore".

Se il problema persiste o se ricevi errori diversi da quelli menzionati nel precedente passaggio 1, vai a Raccogliere informazioni diagnostiche necessarie.

Causa: voci del processore di messaggi inattivi O processori di messaggi non raggiungibili

Diagnostica

Se l'interfaccia utente di Edge richiede molto tempo e non riesce a creare la sessione di traccia, ecco alcune delle possibili cause:
1. Il server di gestione potrebbe fare riferimento a processori di messaggi inesistenti (inattivi)
2. L'elaboratore dei messaggi è stato interrotto o non è più raggiungibile
3. I processori di messaggi stanno consumando molta memoria/CPU
Controlla i log del server di gestione /opt/apigee/var/log/edge-management-server/logs/system.log e verifica se si verificano errori durante la creazione della sessione di traccia/debug.

Durante la creazione della sessione di traccia/debug, potrebbe essere visualizzato un messaggio di errore come "server <UUID> is not up or reachable" (il server <UUID> non è attivo o raggiungibile) durante la creazione della sessione di traccia/debug, come mostrato di seguito:

2017-12-27 07:42:38,975 org:cocacola env:prod qtp2007599722-222063 INFO DISTRIBUTION - DebugSessionAPI.createDebugSession() : server 458b5910-2646-441c-a6e2-428b6d84e021 is either not up or reachable, skipping the server

Dopo un po' di tempo potrebbe verificarsi un altro errore di timeout della connessione, come mostrato di seguito:

2017-12-27 07:44:46.000 UTC org:cocacola env:prod qtp2007599722-222063 ERROR DISTRIBUTION - DebugSessionAPI.createDebugSession() : createDebugSession : Unable to connect to the server with UUID {}, skipping it458b5910-2646-441c-a6e2-428b6d84e021 org.apache.http.conn.HttpHostConnectException: Connect to 192.168.101.7:8080 [/192.168.101.7] failed: Connection timed out (Connection timed out) at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:140) ~[httpclient-4.3.5.jar:4.3.5] at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:318) ~[httpclient-4.3.5.jar:4.3.5] at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363) ~[httpclient-4.3.5.jar:4.3.5] at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:219) ~[httpclient-4.3.5.jar:4.3.5] 
…<snipped>
Caused by: java.net.ConnectException: Connection timed out (Connection timed out) at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_144] at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[na:1.8.0_144]
…<snipped>

Questi due errori potrebbero essere causati da processori di messaggi specifici:
1. Non aggiornato (non più esistente)
2. Non disponibile/non raggiungibile per un motivo non determinato
Segui la risoluzione appropriata in base allo scenario riscontrato.

Risoluzione

Scenario 1 : processori di messaggi inattivi (non esistenti)

Scarica l'elenco dei processori di messaggi utilizzando la seguente API di gestione:

curl -u <sysadmin> "http://<management-server-host>:8080/v1/servers?pod=<podName>&regions=<regionName>"

Prendi nota dell'indirizzo IP o del nome host che corrisponde agli UUID dei processori di messaggi menzionati nel messaggio di errore nei log del server di gestione (passaggio 3 della sezione Diagnostica sopra). Verifica se si tratta di processori di messaggi validi utilizzando uno dei seguenti metodi:
1. Diagramma di configurazione della topologia Private Cloud più recente
2. Indirizzo IP server perimetrale più recente - Tabella di mappatura nome host
Se ritieni che processori di messaggi validi, passa allo Scenario 2 : processori di messaggi non raggiungibili.

Elimina i processori di messaggi inattivi (non esistenti) utilizzando le API di gestione seguenti:

Annulla la registrazione del processore di messaggi dagli ambienti dell'organizzazione:

curl -X POST http://<management-server-host>:8080/v1/o/<orgName>/e/<envName>/servers -d "uuid={uuid}&region=<regionName>&pod=<podName}&action=remove"

Annulla registrazione del tipo di server:

curl http://<management-server-host>:8080/v1/servers -X POST -d "type={message-processor}&region=<regionName>&pod=<podName>&uuid=<uuid>&action=remove"

Elimina il server:

curl http://<management-ip>:8080/v1/servers/<uuid> -X DELETE

Ripeti il passaggio 3 se il problema persiste in qualsiasi altro ambiente dell'organizzazione.

Scenario 2: processori di messaggi non raggiungibili

Accedi a ciascuno dei processori di messaggi determinando gli indirizzi IP/i nomi host in base agli UUID osservati nel messaggio di errore nei log del server di gestione.

Riavvia il processore di messaggi:

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Ricontrolla se riesci a creare la sessione di traccia. Se il problema persiste, consulta la pagina Raccogliere informazioni diagnostiche.

Causa: problema di utilizzo elevato delle risorse

Diagnostica

Accedi a ciascuno dei processori di messaggi e controlla se l'utilizzo delle risorse è elevato: CPU, memoria o carico. Puoi utilizzare il comando top nei sistemi operativi basati su Unix per ottenere le informazioni sull'utilizzo delle risorse del processo del processore di messaggi:
```
top
```
Se l'utilizzo delle risorse non è elevato per gli elaboratori dei messaggi, passa a Must Raccogliere informazioni diagnostiche.
Se i processori di messaggi riscontrano un utilizzo elevato di CPU o memoria, è possibile che il processore di messaggi non risponda in tempo al server di gestione. Questo ti impedisce di creare una sessione di traccia.
1. Se un processore di messaggi riscontra un utilizzo elevato della CPU, genera tre dump dei thread ogni 30 secondi utilizzando il seguente comando:
```
sudo <JAVA_HOME>/bin/jstack -l <pid> > <filename>
```
2. Se un processore di messaggi utilizza un numero elevato di memoria, genera un dump dell'heap utilizzando il seguente comando:
```
sudo -u apigee <JAVA_HOME>/bin/jmap -dump:live,format=b,file=<filename> <pid>
```
3. Passa alla risoluzione.

Risoluzione

Riavvia il processore di messaggi utilizzando il comando riportato di seguito. Questa operazione dovrebbe ridurre l'utilizzo di CPU e memoria:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
Monitora le chiamate API e verifica se il problema persiste.
Contatta l'assistenza Apigee Edge e fornisci i log di dump dei thread, dump dell'heap e processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log) per aiutarli a indagare sulla causa dell'elevato utilizzo di CPU/memoria.

Causa: il deployment del proxy API non è stato eseguito su uno o più processori di messaggi

Raramente è possibile che non venga eseguito il deployment di un proxy API su uno o più processori di messaggi. Ciò accade principalmente a causa della mancata notifica degli eventi dal server di gestione al processore di messaggi durante il deployment del proxy API specifico. Inoltre, in questo caso non potrai creare la sessione di traccia nella UI di Edge.

Diagnostica

Accedi a ciascuno dei processori di messaggi e controlla se è stato eseguito il deployment della revisione specifica del proxy API utilizzando il seguente comando:
```
curl -v localhost:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
```
Output di esempio:

Vedrai l'elenco delle revisioni come output del comando riportato sopra. Ad esempio, se viene eseguito il deployment della revisione 12, vedrai l'output come segue:

[ "12" ]
Se la revisione specifica del proxy API non viene visualizzata come output del comando citato nel passaggio 1 precedente, riavvia il processore di messaggi specifico come spiegato nella sezione Risoluzione riportata di seguito.
Ripeti i passaggi 1-2 per tutti i processori di messaggi.
Se su tutti i processori di messaggi viene eseguito il deployment della revisione specifica del proxy API, non è questa la causa del problema. Passa a Devi raccogliere informazioni diagnostiche.

Risoluzione

Riavvia i processori di messaggi specifici su cui non è stato eseguito il deployment della revisione specifica del proxy API:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```

Causa: problema con l'interfaccia utente Edge

Diagnostica

Controlla i log dell'interfaccia utente di Edge /opt/apigee/var/log/edge-ui/application.log e /opt/apigee/var/log/edge-ui/edge-ui.log e controlla se sono presenti errori.
Contatta l'assistenza Apigee Edge e condividi questi file per ulteriori indagini.

È necessario raccogliere informazioni diagnostiche

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni diagnostiche. Contatta e inviale all'assistenza Apigee Edge:

Output del comando:

curl -v <management-server-host>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/apis/<apiproxy-name>/revisions/<revision-number>/debugsessions -u <user>

Log del server di gestione

/opt/apigee/var/log/edge-management-server/logs/system.log.

Log del processore di messaggi

/opt/apigee/var/log/edge-message-processor/logs/system.log.

Output dei comandi telnet/nc dal server di gestione al processore di messaggi:
```
telnet <MessageProcessor_IP> 8082
nc -vz <MessageProcessor_IP> 8082
```
Output del comando netstat seguente nei processori di messaggi:
```
netstat -an > netstat.txt
```
Se viene rilevato un problema relativo alla UI Edge, fornisci i log dell'interfaccia utente Edge /opt/apigee/var/log/edge-ui/application.log e /opt/apigee/var/log/edge-ui/edge-ui.log.
Dettagli sulle sezioni di questa guida pratica messe a punto e altri approfondimenti che ci aiuteranno a risolvere il problema in modo rapido.