timeout del gateway (504)

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

Sintomo

L'applicazione client riceve un codice di stato HTTP 504 con il messaggio Gateway Timeout come risposta alle chiamate API.

L'errore del codice di stato HTTP - 504 Gateway Timeout indica che il client non ha ricevuto una risposta tempestiva da Edge Gateway o dal server di backend durante l'esecuzione di un'API

Messaggi di errore

L'applicazione client riceve il seguente codice di risposta:

HTTP/1.1 504 Gateway Timeout

In alcuni casi, potrebbe essere visualizzato anche il seguente messaggio di errore:

{
   "fault": {
      "faultstring": "Gateway Timeout",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.GatewayTimeout"
       }
    }
}

Quali sono le cause dei timeout del gateway?

Il percorso tipico di una richiesta API tramite la piattaforma Edge sarà Client -> Router -> Processore di messaggi -> Server di backend, come mostrato nella figura seguente:

L'applicazione client, i router e i Message Processor all'interno della piattaforma Edge sono configurati con valori di timeout adatti. La piattaforma Edge si aspetta che una risposta venga inviata entro un determinato periodo di tempo per ogni richiesta API in base ai valori di timeout. Se non ricevi la risposta entro il periodo di tempo specificato, viene restituito 504 Gateway Timeout Error.

La tabella seguente fornisce ulteriori dettagli sui casi in cui possono verificarsi timeout in Edge:

Occorrenza di timeout Dettagli
Il timeout si verifica nel processore di messaggi
  • Il server di backend non risponde al processore di messaggi entro un periodo di timeout specificato sul processore di messaggi.
  • Il Message Processor scade e invia lo stato di risposta 504 Gateway Timeout al Router.
Si verifica un timeout sul router
  • Il Message Processor non risponde al router entro il periodo di timeout specificato sul router.
  • Il router scade e invia lo stato di risposta 504 Gateway Timeout all'applicazione client.
Si verifica un timeout nell'applicazione client
  • Il router non risponde all'applicazione client entro il periodo di timeout specificato sul router.
  • L'applicazione client scade e termina lo stato di risposta come 504 Gateway Timeout per l'utente finale.

Possibili cause

In Edge, le cause tipiche dell'errore 504 Gateway Timeout sono:

Causa Dettagli Passaggi indicati per
Server di backend lento Il server di backend che elabora la richiesta API è troppo lento a causa di un carico elevato o di prestazioni scadenti. Utenti di cloud pubblico e privato
Elaborazione lenta delle richieste API da parte di Edge Edge impiega molto tempo per elaborare la richiesta dell'API a causa di un carico elevato o di prestazioni ridotte.

Server di backend lento

Se il server di backend è molto lento o impiega molto tempo per elaborare la richiesta API, verrà visualizzato un errore 504 Gateway Timeout. Come spiegato nella sezione precedente, il timeout può verificarsi in uno dei seguenti scenari:

  1. Il processore di messaggi scade prima che il server di backend risponda.
  2. Il router scade prima che il server di elaborazione dei messaggi/di backend risponda.
  3. Timeout dell'applicazione client prima che il router/il processore di messaggi/il server di backend risponda.

Le sezioni seguenti descrivono come diagnosticare e risolvere il problema in ciascuno di questi scenari.

Scenario 1 Il processore di messaggi scade prima che il server di backend risponda

Diagnosi

Puoi utilizzare le seguenti procedure per diagnosticare se si è verificato l'errore 504 Gateway Timeout a causa del lento server di backend.

Procedura 1: utilizzo di Trace

Se il problema è ancora attivo (504 errori continuano a verificarsi), segui questi passaggi:

  1. Traccia l'API interessata nella UI Edge. Attendi che si verifichi l'errore o, se hai la chiamata API, effettua alcune chiamate API e riproduci l'errore 504 Gateway Timeout.
  2. Una volta verificato l'errore, esamina la richiesta specifica che mostra il codice di risposta come 504.
  3. Controlla il tempo trascorso in ogni fase e prendi nota della fase in cui viene impiegato più tempo.
  4. Se noti l'errore con il tempo trascorso più lungo subito dopo una delle fasi seguenti, significa che il server di backend è lento o impiega molto tempo per elaborare la richiesta:
    • Richiesta inviata al server di destinazione
    • Criterio ServiceCallout

Di seguito è riportato un Trace di esempio che mostra che il server di backend non ha risposto nemmeno dopo 55 secondi, generando un errore 504 Gateway Timeout:

Nella traccia riportata sopra, l'elaborazione dei messaggi scade dopo 55002 ms perché il server di backend non risponde.

Procedura 2: utilizzo dei log del processore di messaggi

  1. Controlla il log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log)

  2. Se trovi errori Gateway Timeout e onTimeoutRead per la richiesta del proxy API specifica al momento specifico, significa che il tempo di elaborazione del messaggio è scaduto.

    Esempio di log del processore di messaggi che mostra l'errore di timeout del gateway

    2015-09-29 20:16:54,340 org:myorg env:staging api:profiles rev:13 NIOThread@1
ERROR ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
AbstractResponseListener.onError(HTTPResponse@4d898cf1, Gateway
Timeout)
2015-09-29 20:16:57,361 org:myorg env:staging api:profileNewsletters rev:8
NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onTimeout() :
SSLClientChannel[C:XX.XX.XX.XX:443 Remote
host:192.168.38.54:38302]@120171 useCount=2 bytesRead=0
bytesWritten=824 age=55458ms lastIO=55000ms .onTimeoutRead

    Nel log del processore di messaggi riportato sopra, noti che il server di backend con l'indirizzo IP XX.XX.XX.XX non ha risposto nemmeno dopo 55 secondi (lastIO=55000ms). Di conseguenza, il Message Processor ha eseguito il timeout e ha inviato l'errore 504 Gateway Timeout.

    Dai un'occhiata a questo articolo: Come viene controllato il timeout in Message Processor?

    • Come viene controllato il timeout nel processore di messaggi. I processori di messaggi sono in genere impostati con un valore di timeout predefinito di 55 secondi) tramite la proprietà HTTPTransport.io.timeout.millis. Questo valore di timeout è applicabile a tutti i proxy API che appartengono a un'organizzazione servita da questo elaboratore di messaggi.
      • Se il server di backend non risponde entro 55 secondi, l'elaborazione dei messaggi scade e viene inviato un errore 504 Gateway Timeout al client.
    • Il valore di timeout specificato nel Message Processor può essere sostituito dalla proprietà io.timeout.millis specificata all'interno del proxy API. Questo valore di timeout è applicabile a un proxy API specifico in cui è specificata la proprietà sopra indicata. Ad esempio, se il valore io.timeout.millis è impostato su 10 secondi nel proxy API, verrà utilizzato il valore di timeout di 10 secondi per questo proxy API specifico.
      • Se il server di backend non risponde entro 10 secondi per il proxy API specifico, il processore di messaggi scade e invia l'errore 504 Gateway Timeout al client.

Risoluzione

  1. Controlla perché il server di backend impiega più di 55 secondi e verifica se può essere corretto/ottimizzato per rispondere più velocemente.
  2. Se non è possibile correggere/ottimizzare il server di backend o se è noto che quest'ultimo impiega più tempo del timeout configurato, aumenta il valore di timeout sul router e sul processore di messaggi impostandolo su un valore appropriato.

Scenario #2: il router scade prima che il Message Processor/server di backend risponda

Potresti ricevere errori 504 Gateway Timeout se il router scade prima che il server di elaborazione dei messaggi/di backend risponda. Ciò può verificarsi in una delle seguenti circostanze:

  • Il valore di timeout impostato sul router è inferiore al valore di timeout impostato sul Processore di messaggi. Ad esempio, supponiamo che il timeout sul router sia di 50 secondi, mentre quello del Nucleo di elaborazione dei messaggi sia di 55 secondi.
    Timeout sul router Timeout nel processore di messaggi
    50 secondi 55 secondi
  • Il valore del timeout nel Message Processor viene sostituito con un valore del timeout più elevato utilizzando la proprietà io.timeout.millis impostata nella configurazione dell'endpoint di destinazione del proxy API:

    Ad esempio, se sono impostati i seguenti valori di timeout:

    Timeout sul router Timeout nel processore di messaggi Timeout nel proxy API
    57 secondi 55 secondi 120 secondi

    Tuttavia, io.timeout.millis è impostato su 120 secondi nel proxy API:

    <HTTPTargetConnection>
     <Properties>
          <Property name="io.timeout.millis">120000</Property>
      </Properties>
      <URL>http://www.apigee.com</URL>
</HTTPTargetConnection>

    Quindi, il processore di messaggi non scadrà dopo 55 secondi anche se il suo valore di timeout (55 secondi) è inferiore al valore di timeout sul router (57 secondi). Questo accade perché il valore del timeout di 55 secondi nel Message Processor viene sostituito dal valore di 120 secondi impostato nel proxy API. Pertanto, il valore del timeout del Message Processor per questo proxy API specifico sarà di 120 secondi.

    Poiché il router ha un valore di timeout inferiore (57 secondi) rispetto ai 120 secondi impostati nel proxy API, il router si spegnerà se il server di backend non risponde dopo 57 secondi.

Diagnosi

  1. Controlla il log di accesso NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)

  2. Se il router scade prima del processore di messaggi, vedrai lo stato 504 nei log di accesso NGINX per la richiesta API specifica e il valore message id del processore di messaggi verrà impostato su -. Questo accade perché il router non ha ricevuto alcuna risposta dal Message Processor entro il periodo di timeout impostato sul router.

    Voce del log NGINX di esempio che mostra 504 a causa del timeout del router

  3. Nell'esempio riportato sopra, nota lo stato di 504 su NGINX, l'ID messaggio del Processore messaggi è - e il tempo totale trascorso è 57,001 secondi. Questo perché il router ha superato il tempo di attesa dopo 57.001 secondi e non abbiamo ricevuto alcuna risposta dall'Elaboratore di messaggi.
  4. In questo caso, vedrai eccezioni Broken Pipe nei log del Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log). 
    2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
java.io.IOException: Broken pipe
        at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
         … <snipped>

Questo errore viene visualizzato perché, una volta scaduto il timeout del router, la connessione con il Processore dei messaggi viene chiusa. Al termine dell'elaborazione, il Message Processor tenta di scrivere la risposta sul router. Poiché la connessione al router è già chiusa, viene visualizzato il messaggio Broken Pipe exception nel Message Processor.

Questa eccezione dovrebbe verificarsi nelle circostanze spiegate sopra. Pertanto, la causa effettiva dell'errore 504 Gateway Timeout è ancora il tempo di risposta più lungo del server di backend e devi risolvere il problema.

Risoluzione

  1. Se si tratta di un server di backend personalizzato:
    1. Controlla perché il server di backend sta impiegando molto tempo per rispondere e scopri se può essere corretto/ottimizzato per rispondere più velocemente.
    2. Se non è possibile correggere/ottimizzare il server di backend o se è noto che il server di backend richiede molto tempo, aumenta il valore del timeout su Router e Message Processor.

      Idea: imposta il valore del timeout sui diversi componenti nell'ordine seguente:

      Timeout sul client > Timeout sul router > Timeout sul messaggio Processore > Timeout all'interno del proxy API
  2. Se si tratta di un server di backend NodeJS:
    1. Controlla se il codice NodeJS effettua chiamate ad altri server di backend e se impiega molto tempo per restituire una risposta. Controlla perché i server di backend impiegano più tempo e risolvi il problema in base alle circostanze.
    2. Controlla se i processori di messaggi stanno riscontrando un utilizzo elevato della CPU o della memoria:
      1. Se un Message Processor presenta un elevato utilizzo della CPU, genera tre dump del thread ogni 30 secondi utilizzando il seguente comando: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. Se un processore di messaggi riscontra 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. Riavvia il processore di messaggi utilizzando il comando seguente. Dovrebbe ridurre la CPU e la memoria: 
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. Monitora le chiamate API per verificare se il problema persiste.
      5. Contatta l'assistenza Apigee Edge e fornisci i dump thread, il dump dell'heap e i log del Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)per aiutarci a esaminare la causa dell'elevato utilizzo di CPU/memoria.

Da controllare: come viene controllato il timeout per i server di backend Node.js su Message Processor

  • Il server di backend NodeJS viene eseguito all'interno del processo JVM del processore di messaggi. Il valore di timeout per i server di backend NodeJS è controllato tramite la proprietà http.request.timeout.seconds nel file nodejs.properties. Questa proprietà è impostata su 0 per impostazione predefinita, ovvero il timeout è disattivato per impostazione predefinita per tutti i proxy API che appartengono a un'organizzazione servita da questo elaboratore di messaggi. Pertanto, anche se un server di backend NodeJS richiede molto tempo, il Message Processor non scade.
  • Tuttavia, se il server di backend NodeJS richiede molto tempo e se il tempo impiegato dalla richiesta API è superiore a 57 secondi, il router scade e invia l'errore 504 Gateway Timeout al client.

Scenario 3: l'applicazione client scade prima che il router/l'elaboratore di messaggi/il server di backend risponda

Potresti ricevere errori 504 Gateway Timeout se l'applicazione client scade prima che il server di backend risponda. Questa situazione può verificarsi se:

  1. Il valore di timeout impostato per l'applicazione client è inferiore a quello impostato sul router e sul processore di messaggi:

    Ad esempio, se sono impostati i seguenti valori di timeout:

    Timeout sul client Timeout sul router Timeout nel processore di messaggi
    50 secondi 57 secondi 55 secondi

    In questo caso, il tempo totale disponibile per ricevere una risposta per una richiesta API tramite Edge è <= 50 secondi. Sono inclusi il tempo necessario per effettuare una richiesta API, l'elaborazione della richiesta da parte di Edge (router, Message Processor), l'invio della richiesta al server di backend (se applicabile), l'elaborazione della richiesta e l'invio della risposta da parte del backend, l'elaborazione della risposta da parte di Edge e infine il suo invio al client.

    Se il router non risponde al client entro 50 secondi, il client scade e chiude la connessione con il router. Il client riceverà il codice di risposta 504.

    In questo modo, NGINX imposterà un codice di stato 499 che indica che il client ha chiuso la connessione.

Diagnosi

  1. Se l'applicazione client scade prima di ricevere una risposta dal router, chiude la connessione con il router. In questa situazione, vedrai un codice di stato 499 nei log di accesso NGINX per la richiesta API specifica.

    Voce del log NGINX di esempio che mostra il codice di stato 499

  2. Nell'esempio precedente, tieni presente che lo stato di 499 su NGINX e il tempo totale trascorso sono 50.001 secondi. Ciò indica che il client ha superato il tempo di attesa dopo 50.001 secondi.
  3. In questo caso, vedrai Broken Pipe Eccezioni nei log del Processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log).
    2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
java.io.IOException: Broken pipe
        at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
         … <snipped>
  4. Dopo il timeout, il router chiude la connessione con il Message Processor. Quando il Processore dei messaggi completa l'elaborazione, tenta di scrivere la risposta al Router. Poiché la connessione al router è già chiusa, visualizzi Broken Pipe exception nell'elaboratore di messaggi.
  5. Questa eccezione è prevista nelle circostanze spiegate sopra. Pertanto, la causa effettiva dell'errore 504 Gateway Timeout è ancora che il server di backend impiega molto tempo per rispondere e devi risolvere il problema.

Risoluzione

  1. Se si tratta del tuo server di backend personalizzato:
    1. Controlla il server di backend per determinare il motivo per cui impiega più di 57 secondi e verifica se può essere corretto/ottimizzato per rispondere più velocemente.
    2. Se non è possibile correggere/ottimizzare il server di backend o se sai che il server di backend richiederà molto tempo, aumenta il valore di timeout sul router e sul processore di messaggi.

      Idea: Imposta il valore di timeout sui diversi componenti nel seguente ordine:

      Timeout sul client > Timeout sul router > Timeout sul messaggio Processore > Timeout all'interno del proxy API
  2. Se si tratta di un backend NodeJS:
    1. Controlla se il codice NodeJS effettua chiamate ad altri server di backend e se impiega molto tempo per restituire un valore. Controlla perché questi server di backend richiedono più tempo.
    2. Controlla se i processori di messaggi registrano un utilizzo elevato di CPU o memoria:
      1. Se un Message Processor presenta un elevato utilizzo della CPU, genera tre dump del thread ogni 30 secondi utilizzando il seguente comando: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. Se un Message Processor sta riscontrando un elevato utilizzo della 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. Riavviare il Message Processor utilizzando il comando seguente. In questo modo, dovresti ridurre la CPU e la memoria: 
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. Monitora le chiamate API per verificare se il problema persiste.
      5. Contatta l'assistenza Apigee Edge e fornisci i dump thread, il dump dell'heap e i log del Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)per aiutarli a esaminare la causa dell'elevato utilizzo di CPU/memoria.

Aumenta il valore di timeout sul router e sul processore di messaggi

Scegli con attenzione i valori di timeout da impostare sul router e sul Message Processor in base alle tue esigenze. Non impostare valori di timeout arbitrariamente grandi. Se hai bisogno di aiuto, contatta l'assistenza Apigee Edge.

Router

chown apigee:apigee /opt/apigee/customer/application/router.properties
  1. Crea il file /opt/apigee/customer/application/router.properties sulla macchina del router, se non esiste già.
  2. Aggiungi la seguente riga a questo file: 
    conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS

    Ad esempio, se vuoi impostare il valore del timeout su 120 secondi, impostalo come segue:

    conf_load_balancing_load.balancing.driver.proxy.read.timeout=120
  3. Assicurati che questo file sia di proprietà di apigee:
  4. Riavvia il router: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  5. Se hai più di un router, ripeti i passaggi precedenti su tutti i router.

processore di messaggi

  1. Crea il file /opt/apigee/customer/application/message-processor.properties sulla macchina del processore di messaggi, se non esiste già.
  2. Aggiungi la seguente riga a questo file: 
    conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS

    Ad esempio, se vuoi impostare il valore del timeout su 120 secondi, impostalo come segue:

    conf_http_HTTPTransport.io.timeout.millis=120000
  3. Assicurati che questo file sia di proprietà di apigee: 
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  4. Riavvia il Message Processor: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. Se hai più di un elaboratore di messaggi, ripeti i passaggi precedenti su tutti gli elaboratori di messaggi.

Idea: imposta il valore del timeout sui diversi componenti nel seguente ordine:

Timeout sul client > Timeout sul router > Timeout sul processore di messaggi > Timeout nel proxy API

Elaborazione lenta delle richieste API da parte di Edge

Se Edge è molto lento e/o impiega molto tempo per elaborare la richiesta API, verrà visualizzato un errore 504 Gateway Timeout.

Diagnosi

  1. Traccia l'API interessata nella UI Edge.
  2. Attendi che si verifichi l'errore o, se hai la chiamata API, effettua alcune chiamate API e riproduci l'errore 504 Gateway Timeout.
  3. Tieni presente che in questo caso potresti visualizzare una risposta positiva nel tracciato.
    1. Il router/client scade perché il Message Processor non risponde entro il periodo di timeout specificato sul router/client (a seconda di quale sia il periodo di timeout più breve). Tuttavia, il processore di messaggi continua a elaborare la richiesta e potrebbe essere completata correttamente.
    2. Inoltre, il valore HTTPTransport.io.timeout.millis impostato sul processore di messaggi si attiva solo se il processore di messaggi comunica con un server di backend HTTP/HTTPS. In altre parole, questo timeout non verrà attivato quando un criterio (diverso dal criterio ServiceCallout) all'interno di API Proxy richiede molto tempo.
  4. Dopo che si è verificato l'errore, esamina la richiesta specifica con il tempo trascorso più lungo.
  5. Controlla il tempo trascorso in ogni fase e prendi nota della fase in cui viene impiegato più tempo.
  6. Se noti il tempo trascorso più lungo in uno dei criteri diversi da quello per i callout di servizio, significa che Edge impiega molto tempo per elaborare la richiesta.
  7. Ecco una traccia della UI di esempio che mostra un tempo di esecuzione molto elevato per il criterio JavaScript:

  8. Nell'esempio riportato sopra, noterai che il criterio JavaScript richiede un tempo insolitamente lungo di circa 245 secondi.

Risoluzione

  1. Controlla se il criterio ha richiesto molto tempo per rispondere e se è presente un codice personalizzato che potrebbe richiedere molto tempo per l'elaborazione. Se esiste un codice di questo tipo, prova a ripararlo/ottimizzarlo.
  2. Se non è presente codice personalizzato che potrebbe causare tempi di elaborazione elevati, controlla se i processori di messaggi stanno riscontrando un elevato utilizzo della CPU o della memoria:
    1. Se un Message Processor presenta un elevato utilizzo della CPU, genera tre dump del thread ogni 30 secondi utilizzando il seguente comando: 
      JAVA_HOME/bin/jstack -l PID > FILENAME
    2. Se un qualsiasi elaboratore di messaggi ha un utilizzo elevato della 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. Riavviare il Message Processor utilizzando il comando seguente. In questo modo, la CPU e la memoria dovrebbero diminuire. 
      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
    4. Monitora le chiamate API e verifica se il problema persiste.
    5. Contatta l'assistenza Apigee Edge e fornisci i dump del thread, il dump dell'heap e i log del Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)per aiutarli a esaminare la causa dell'elevato utilizzo di CPU/memoria.

Diagnostica dei problemi utilizzando il monitoraggio delle API

Il monitoraggio delle API consente di isolare rapidamente le aree problematiche per diagnosticare i problemi di errore, prestazioni e latenza e la relativa origine, ad esempio app per sviluppatori, proxy API, target backend o piattaforma API.

Esegui uno scenario di esempio che mostra come risolvere i problemi 5xx relativi alle API utilizzando il monitoraggio delle API. Ad esempio, potresti configurare un avviso per ricevere una notifica quando il numero di codici di stato 504 supera una determinata soglia.