Impossibile creare la sessione di traccia

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

Sintomo

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

Messaggio di errore

Riceverai un messaggio di errore nella UI 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 messaggio di errore di esempio osservato nella UI Edge:

Possibili cause

Di seguito sono elencate alcune delle possibili cause di questo errore:

Causa Descrizione Istruzioni per la risoluzione dei problemi applicabili per
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 del firewall. Utenti Edge Private Cloud
Ambiente non caricato sul processore di messaggi L'ambiente specifico (in cui stai tentando di abilitare la traccia) non è stato caricato nei processori di messaggi a causa di un errore.
Voci del processore di messaggi inattivo 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 è raggiungibile.
Problema di utilizzo elevato delle risorse I processori di messaggi stanno riscontrando un elevato utilizzo di risorse (CPU, memoria o carico).
Proxy API di cui non è stato eseguito il deployment su uno o più processori di messaggi Non è possibile eseguire il deployment del proxy API su uno o più processori di messaggi a causa della notifica dell'evento mancante durante il deployment.
Problema con l'UI Edge La UI Edge non è in grado di creare una sessione di traccia a causa di alcuni errori.

Passaggi diagnostici comuni

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

  2. Se si verificano errori, indicali. Vai a Problema di connettività di rete.

  3. Se ricevi una risposta positiva, significa che la sessione di traccia può essere creata tramite l'API di gestione. Tuttavia, potrebbe esserci un problema con la UI Edge, che impedisce di creare una sessione di traccia nella UI. Vai a Problema con la UI Edge.

Causa: problema di connettività di rete

Diagnosi

  1. Controlla il 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.

    Esempio di errore nel 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>

  2. L'errore di esempio riportato sopra mostra che riceviamo errori "Connessione rifiutata" quando il server di gestione tenta di connettersi al processore di messaggi sulla porta n. 8082. Pertanto, il server di gestione non è in grado di creare la sessione di traccia.

  3. Se non vedi errori relativi alla connettività di rete o un errore simile a quello mostrato nell'esempio precedente, passa ad Ambiente non caricato sul processore di messaggi.

  4. Se riscontri uno o più errori relativi alla connettività di rete o un errore simile a quello mostrato nell'esempio precedente, segui i passaggi riportati di seguito.

  5. Verifica la connettività dal server di gestione al processore di messaggi sulla porta 8082 seguendo questi passaggi:

    1. Se telnet è disponibile, utilizza telnet:

      telnet <MessageProcessor_IP> 8082

    2. Se telnet non è disponibile, utilizza netcat per controllare la connettività come segue:

      nc -vz <MessageProcessor_IP> 8082

    3. Se ricevi la risposta "Connessione rifiutata" o "Sessione di connessione scaduta", quindi vai al passaggio successivo.

  6. Accedi a ciascuno dei processori di messaggi con l'indirizzo IP corrispondente che ha visualizzato l'errore ed esegui le seguenti operazioni:

    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, vai al passaggio 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 fino a quando il processore di messaggi non ha completato l'avvio utilizzando questo comando:

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

    5. Quando il processore di messaggi è attivo, controlla di nuovo se è in ascolto sulla porta 8082.

    6. Se il processore di messaggi è in ascolto sulla porta 8082, vai al passaggio 7.

  7. Verifica nella UI che ora puoi avviare la sessione di traccia. Se il problema non si verifica più, salta i passaggi riportati di seguito.

  8. Se il processore di messaggi è in esecuzione ed è in ascolto sulla porta 8082, ma non riesci ancora a connetterti dagli altri server, ad esempio Management Server, probabilmente c'è un firewall che deve bloccare le connessioni esterne.

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

  10. Se non sono impostate regole firewall per la porta 8082, passa a Problema di utilizzo elevato delle risorse.

  11. Se sulla porta 8082 sono configurate regole firewall, vai alla sezione Risoluzione di seguito.

Risoluzione

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

Se il problema persiste, vai alla pagina Raccogliere dati diagnostici.

Causa: ambiente non caricato sul processore di messaggi

Diagnosi

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

  2. Potresti visualizzare un messaggio di errore simile a "Nessuna risposta valida dagli MP" durante la creazione di una sessione di traccia/debug come mostrato di seguito:

    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 i processori di messaggi non rispondono al server di gestione per qualche motivo.

  3. Se non ricevi un errore simile a quello mostrato nell'esempio precedente, passa alle Voci del processore di messaggi in stato inattivo.

  4. Se riscontri un errore simile a quello mostrato nell'esempio precedente, segui questi passaggi.

  5. 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 nei processori di messaggi.

  6. Accedi a ciascuno dei processori di messaggi e verifica se l'ambiente specifico in cui stai tentando di creare la sessione di traccia viene caricato sul processore di messaggi utilizzando il comando seguente:

    curl -s http://localhost:8082/v1/runtime/organizations/<org-name>/environments

    Output di esempio:

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

    [ "preprod", "test" ]

  7. Se l'ambiente specifico, ad esempio "dev", in cui stai tentando di creare una sessione di traccia, viene elencato come parte del comando precedente, passa alle Voci del processore di messaggi inattivi.

  8. Se l'ambiente specifico, ad esempio "dev", non è elencato come parte del comando precedente, controlla /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 per verificare la presenza di errori durante il caricamento degli ambienti.

  9. Potrebbero esserci molti errori diversi che potrebbero portare al mancato caricamento di un ambiente nel 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.

  1. Se nel log del processore di messaggi viene visualizzato uno dei seguenti errori, ciò è dovuto a un problema rilevato con i certificati/le chiavi che sono stati aggiunti all'archivio chiavi/truststore specificato nell'ambiente specificato.

    Errore 1: java.security.KeyStoreEccezioni: 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.KeyStoreEccezioni: 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

  2. Per ottenere i dettagli dell'archivio chiavi/truststore specificato nel messaggio di errore mostrato nel passaggio precedente, utilizza la seguente chiamata all'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" 
}

  3. L'output di esempio mostra che sono presenti due certificati e una chiave nell'archivio di attendibilità myTruststore. L'archivio attendibili in genere non contiene una chiave. In tal caso, è meglio avere un solo certificato e una sola chiave.

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

  5. Controlla la data di scadenza di ciascun certificato e individua quello scaduto o meno recente.

  6. Elimina il certificato scaduto o indesiderato dal truststore "myTruststore".

Se il problema persiste o se vedi errori diversi da quelli menzionati nel passaggio 1 precedente, consulta la sezione Raccogliere informazioni diagnostiche.

Causa: voci del processore di messaggi inattivo OPPURE processori di messaggi non raggiungibili

Diagnosi

  1. Se la UI Edge richiede molto tempo e non riesce a creare la sessione di traccia, le possibili cause sono le seguenti:
    1. È possibile che il server di gestione riferisca a processori di messaggi inesistenti (inattivi)
    2. Il processore o i processori di messaggi sono stati arrestati o non sono più raggiungibili
    3. I processori di messaggi stanno utilizzando un elevato utilizzo di memoria/CPU
  2. 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.

  3. Potresti visualizzare un messaggio di errore simile a "server <UUID> non è attiva o non è raggiungibile" durante la creazione di una 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

    Potrebbe verificarsi il seguente errore: "Sessione di connessione scaduta" dopo qualche istante, come illustrato 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>

  4. Questi due errori potrebbero essere causati da processori di messaggi specifici:

    1. I dati sono obsoleti (non più esistenti)
    2. Non raggiungibile/non raggiungibile per qualche motivo

  5. Segui la soluzione appropriata in base allo scenario riscontrato.

Risoluzione

Scenario 1 : i processori di messaggi sono inattivi (inesistenti)

  1. Recupera l'elenco dei processori di messaggi utilizzando l'API di gestione riportata di seguito:

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

  2. 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 nella sezione Diagnosi sopra). Verifica che si tratti di processori di messaggi validi, utilizzando uno dei seguenti modi:

    1. Diagramma di configurazione più recente della topologia di cloud privato
    2. Ultimo indirizzo IP di Edge Server: tabella di mappatura dei nomi host

    Se ritieni che siano processori di messaggi validi, passa allo Scenario 2 : i processori di messaggi non sono raggiungibili.

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

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

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

    3. Elimina il server: 

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

  4. Ripeti il passaggio 3 se il problema si verifica in altri ambienti dell'organizzazione.

Scenario 2: i processori di messaggi non sono raggiungibili

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

  2. Riavvia il processore di messaggi:

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

Verifica di nuovo se riesci a creare la sessione di traccia. Se il problema persiste, vai alla pagina Devo raccogliere informazioni diagnostiche.

Causa: problema di elevato utilizzo delle risorse

Diagnosi

  1. Accedi a ciascuno dei processori di messaggi e controlla se le risorse utilizzate sono elevate: CPU, memoria o carico. Puoi utilizzare il comando top sui sistemi operativi basati su Unix per ottenere informazioni sull'utilizzo delle risorse del processo del processore di messaggi:

    top

  2. Se i processori di messaggi non riscontrano un utilizzo elevato delle risorse, passa alla sezione Devo raccogliere informazioni diagnostiche.

  3. Se i processori di messaggi riscontrano un elevato utilizzo di CPU o memoria, è possibile che il processore di messaggi non risponda in tempo al server di gestione. In questo modo, non sarai in grado di creare una sessione di traccia.

    1. Se un processore di messaggi riscontra un elevato utilizzo della CPU, genera tre dump di thread ogni 30 secondi utilizzando il seguente comando:

      sudo <JAVA_HOME>/bin/jstack -l <pid> > <filename>

    2. Se un processore di messaggi ha un utilizzo elevato della memoria, genera un dump dell'heap con il seguente comando:

      sudo -u apigee <JAVA_HOME>/bin/jmap -dump:live,format=b,file=<filename> <pid>

    3. Passa a Risoluzione.

Risoluzione

  1. Riavvia il processore di messaggi utilizzando il comando seguente. Questo dovrebbe ridurre l'utilizzo di CPU e memoria:

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

  2. Monitora le chiamate API e verifica se il problema persiste.

  3. Contatta l'assistenza Apigee Edge e fornisci i log dump dei thread, dump dell'heap e del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log) per aiutarli a indagare sulla causa dell'utilizzo elevato di CPU/memoria.

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

Raramente non è possibile eseguire il deployment di un proxy API su uno o più processori di messaggi. Ciò si verifica principalmente a causa della notifica dell'evento mancante dal server di gestione al processore di messaggi durante il deployment di un proxy API specifico. Inoltre, in questo caso non sarà possibile creare la sessione di traccia nella UI di Edge.

Diagnosi

  1. Accedi a ciascuno dei processori di messaggi e verifica 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:

    L'elenco delle revisioni sarà visualizzato come output del comando precedente. Ad esempio, se viene eseguito il deployment della revisione 12, l'output sarà visualizzato nel seguente modo:

    [ "12" ]

  2. Se la revisione specifica del proxy API non viene visualizzata come output del comando indicato nel passaggio 1 precedente, riavvia lo specifico processore di messaggi come spiegato nella sezione Risoluzione riportata di seguito.

  3. Ripeti i passaggi 1-2 per tutti i processori di messaggi.

  4. Se il deployment della revisione specifica del proxy API viene eseguito su tutti i processori di messaggi, questo non è la causa del problema. Passa a Raccogliere informazioni diagnostiche.

Risoluzione

  1. Riavvia gli specifici processori di messaggi 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'UI Edge

Diagnosi

  1. Controlla i log della UI Edge /opt/apigee/var/log/edge-ui/application.log e /opt/apigee/var/log/edge-ui/edge-ui.log e controlla se si verificano errori.
  2. Contatta l'assistenza Apigee Edge e condividi questi file per ulteriori indagini.

Raccogliere informazioni diagnostiche

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

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

  2. Log del server di gestione 

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

  3. Log del processore di messaggi

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

  4. Output dei comandi telnet/nc da Management Server al processore di messaggi:

    telnet <MessageProcessor_IP> 8082
nc -vz <MessageProcessor_IP> 8082

  5. Output del seguente comando netstat sui processori di messaggi:

    netstat -an > netstat.txt

  6. Se è stato rilevato un problema con la UI Edge, fornisci i relativi log /opt/apigee/var/log/edge-ui/application.log e /opt/apigee/var/log/edge-ui/edge-ui.log..

  7. Dettagli sulle sezioni di questo playbook che abbiamo provato e su eventuali altri approfondimenti che ci aiuteranno a risolvere rapidamente il problema.