timeout del gateway (504)

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

Sintomo

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

Il codice di stato HTTP - 504 Gateway Timeout errore indica che il client non ha ricevuto una risposta tempestiva dal gateway perimetrale 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, può essere visualizzato anche il seguente messaggio di errore:

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

Che cosa causa i timeout del gateway?

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

L'applicazione client, i router e i processori di messaggi all'interno della piattaforma Edge sono configurati con valori di timeout appropriati. La piattaforma Edge prevede che venga inviata una risposta 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
Si verifica un timeout sul processore di messaggi
  • Il server di backend non risponde al processore di messaggi entro un periodo di timeout specificato sul processore di messaggi.
  • Il processore di messaggi scade e invia lo stato di risposta come 504 Gateway Timeout al router.
Si verifica un timeout sul router
  • Il processore di messaggi non risponde al router entro il periodo di timeout specificato sul router.
  • Il router scade e invia lo stato di risposta come 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 della risposta come 504 Gateway Timeout per l'utente finale.

Possibili cause

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

Causa Dettagli Passi 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 pubblici e privati
Elaborazione delle richieste API lenta da parte di Edge Edge impiega molto tempo per elaborare la richiesta API a causa del carico elevato o delle prestazioni scadenti.

Server di backend lento

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

  1. Timeout del processore di messaggi prima che il server di backend risponda.
  2. Timeout del router prima di rispondere al server di backend o processore di messaggi.
  3. Si verifica il timeout dell'applicazione client prima che il router/processore messaggi/server di backend risponda.

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

Scenario 1 Timeout del processore di messaggi prima che il server di backend risponda

Diagnostica

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

Procedura 1 con Trace

Se il problema è ancora attivo (gli errori 504 persistono), svolgi i passaggi che seguono:

  1. Traccia l'API interessata nella UI Edge. Attendi che si verifichi l'errore oppure, se hai la chiamata API, quindi effettua alcune chiamate API e riproduci l'errore 504 Gateway Timeout.
  2. Una volta che si è 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 dedicato la maggior parte del tempo.
  4. Se noti l'errore con il tempo trascorso più lungo subito dopo una delle seguenti fasi, significa che il server di backend è lento o impiega molto tempo per elaborare la richiesta:
    • Richiesta inviata al server di destinazione
    • Norme sui callout di servizio

Di seguito è riportata una traccia di esempio che mostra che il server di backend non ha risposto anche dopo 55 secondi, generando un errore 504 Gateway Timeout:

Nella traccia precedente, il processore di messaggi scade dopo 55.002 ms perché il server di backend non risponde.

Procedura 2 con l'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 proxy API specifica in un determinato momento, significa che l'elaboratore di messaggi è 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 indicato con l'indirizzo IP XX.XX.XX.XX non ha risposto anche dopo 55 secondi (lastIO=55000ms). Di conseguenza, l'elaboratore di messaggi è scaduto e ha inviato 504 Gateway Timeout errore.

    Controlla qui: come viene controllato il timeout sul processore di messaggi?

    • Come viene controllato il timeout nel processore di messaggi. I processori di messaggi vengono 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 gestita da questo processore di messaggi.
      • Se il server di backend non risponde entro 55 secondi, il processore di messaggi scade e invia l'errore 504 Gateway Timeout al client.
    • Il valore di timeout specificato nel processore di messaggi può essere ignorato dalla proprietà io.timeout.millis specificata nel proxy API. Questo valore di timeout è applicabile a un proxy API specifico in cui è specificata la proprietà sopra menzionata. Ad esempio, se 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. Verifica 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 il server di backend 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 - Timeout del router prima che il server di backend o il processore di messaggi risponda

Potresti ricevere errori 504 Gateway Timeout se il timeout del router è terminato prima che il processore di messaggi/server di backend risponda. Ciò può accadere in una delle seguenti circostanze:

  • Il valore di timeout impostato sul router è più breve di quello impostato sul processore di messaggi. Ad esempio, supponiamo che il timeout sul router sia di 50 secondi, mentre il processore di messaggi è di 55 secondi.
    Timeout sul router Timeout sul processore di messaggi
    50 secondi 55 secondi
  • Il valore di timeout sul processore di messaggi viene sostituito con un valore di timeout più elevato utilizzando la proprietà io.timeout.millis impostata all'interno della configurazione dell'endpoint di destinazione del proxy API:

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

    Timeout sul router Timeout sul processore di messaggi Timeout all'interno del 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 va in timeout dopo 55 secondi anche se il suo valore di timeout (55 secondi) è inferiore al valore di timeout sul router (57 secondi). Questo perché il valore di timeout di 55 secondi nel processore di messaggi viene sostituito dal valore di 120 secondi impostato nel proxy API. Il valore di timeout del processore di messaggi per questo proxy API specifico sarà quindi 120 secondi.

    Poiché il valore di timeout del router è inferiore (57 secondi) rispetto ai 120 secondi impostati nel proxy API, il router andrà in timeout se il server di backend non risponde dopo 57 secondi.

Diagnostica

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

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

    Esempio di voce di log NGINX che mostra 504 a causa del timeout del router

  3. Nell'esempio precedente, puoi notare lo stato di 504 su NGINX, l'ID del messaggio del processore di messaggi è - e il tempo totale trascorso è 57,001 secondi. Questo perché il router è scaduto dopo 57,001 secondi e non abbiamo ricevuto alcuna risposta dal processore di messaggi.
  4. 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-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, il router chiude la connessione con il processore di messaggi. Quando il processore di messaggi completa l'elaborazione, prova a scrivere la risposta al router. Poiché la connessione al router è già chiusa, ricevi Broken Pipe exception sul processore di messaggi.

Questa eccezione dovrebbe essere riscontrata nelle circostanze spiegate sopra. Di conseguenza, la causa effettiva dell'errore 504 Gateway Timeout è che il server di backend impiega più tempo per rispondere e devi risolvere il problema.

Risoluzione

  1. Se si tratta di un server di backend personalizzato:
    1. Verifica perché il server di backend sta impiegando molto tempo per rispondere e verifica se può essere corretto/ottimizzato per rispondere più velocemente.
    2. Se non è possibile correggere/ottimizzare il server di backend o se è risaputo che il server di backend impiega 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 su client > Timeout sul router > Timeout sul processore di messaggi > Timeout nel 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. Verifica perché i server di backend impiegano più tempo e risolvi il problema in modo opportuno.
    2. Controlla se i processori di messaggi stanno riscontrando un utilizzo elevato di CPU o memoria:
      1. Se un processore di messaggi riscontra un utilizzo elevato della CPU, genera tre dump dei 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 utilizzando 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 riportato di seguito. 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 log di dump dei thread, dump dell'heap e processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log)per aiutare a indagare la causa dell'elevato utilizzo di CPU/memoria.

Controlla qui: come viene controllato il timeout per i server di backend NodeJS sul processore di messaggi

  • Il server di backend NodeJS viene eseguito all'interno del processo JVM del Message Processor. 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, ossia il timeout è disabilitato per impostazione predefinita per tutti i proxy API che appartengono a un'organizzazione gestita da questo processore di messaggi. Quindi, anche se un server di backend NodeJS richiede molto tempo, il processore di messaggi non si farà timeout.
  • Tuttavia, se il server di backend NodeJS impiega molto tempo e se il tempo impiegato dalla richiesta API è superiore a 57 secondi, il router si spegnerà e invia l'errore 504 Gateway Timeout al client.

Scenario 3 - Timeout dell'applicazione client prima che il router/il processore 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 nell'applicazione client è inferiore al valore di timeout 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 sul processore di messaggi
    50 secondi 57 secondi 55 secondi

    In questo caso, il tempo totale disponibile per ricevere una risposta a una richiesta API tramite Edge è <= 50 secondi. Questo include il tempo impiegato per effettuare una richiesta API, la richiesta elaborata da Edge (router, processore di messaggi), la richiesta inviata al server di backend (se applicabile), il backend che elabora la richiesta e invia la risposta, elabora la risposta a livello perimetrale e, infine, la invia nuovamente al client.

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

    Questo farà sì che NGINX imposti un codice di stato 499 che indica che il client ha chiuso la connessione.

Diagnostica

  1. Se l'applicazione client scade prima di ricevere una risposta dal router, la connessione con il router verrà chiusa. In questo caso, vedrai il codice di stato 499 nei log degli accessi NGINX per la richiesta API specifica.

    Esempio di voce di log NGINX 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 è di 50,001 secondi. Questo indica che il client è scaduto 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 del router, la connessione con il processore di messaggi viene chiusa. Quando il processore di messaggi completa l'elaborazione, prova a scrivere la risposta al router. Poiché la connessione al router è già chiusa, ricevi Broken Pipe exception sul processore di messaggi.
  5. Questa eccezione è prevista nelle circostanze spiegate sopra. 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 perché sta richiedendo più di 57 secondi e vedere 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 impiegherà 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 su client > Timeout sul router > Timeout sul processore di messaggi > Timeout nel proxy API
  2. Se è un backend NodeJS:
    1. Controlla se il codice NodeJS effettua chiamate ad altri server di backend e se la restituzione sta richiedendo molto tempo. Controlla perché questi server di backend stanno richiedendo più tempo.
    2. Controlla se i processori di messaggi stanno riscontrando un elevato utilizzo di CPU o memoria:
      1. Se un processore di messaggi riscontra un utilizzo elevato della CPU, genera tre dump dei 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 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. Riavvia il processore di messaggi utilizzando il comando riportato di seguito. L'operazione 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 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 la causa dell'elevato utilizzo di CPU/memoria.

Aumenta il valore di timeout su router e processore di messaggi

Scegli attentamente i valori di timeout da impostare sul router e sul processore di messaggi 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 un valore di timeout di 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 disponi di più router, ripeti i passaggi precedenti su tutti i router.

processore di messaggi

  1. Crea il file /opt/apigee/customer/application/message-processor.properties sul computer 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 un valore di timeout di 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 processore di messaggi: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. Se disponi di più processori di messaggi, ripeti i passaggi precedenti su tutti i processori di messaggi.

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

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

Elaborazione delle richieste API lenta da parte di Edge

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

Diagnostica

  1. Traccia l'API interessata nella UI Edge.
  2. Attendi che si verifichi l'errore o, se hai la chiamata API, quindi effettua alcune chiamate API e riproduci l'errore 504 Gateway Timeout.
  3. Tieni presente che, in questo caso, potresti visualizzare una risposta corretta in Trace.
    1. Il router/client si spegne perché il processore di messaggi non risponde entro il periodo di timeout specificato sul router/client (a seconda di quale sia il periodo di timeout più basso). Tuttavia, il Processore di messaggi continua a elaborare la richiesta e potrebbe completarla correttamente.
    2. Inoltre, il valore HTTPTransport.io.timeout.millis impostato sul processore di messaggi si attiva solo se quest'ultimo comunica con un server di backend HTTP/HTTPS. In altre parole, questo timeout non verrà attivato quando un criterio (diverso da quello di ServiceCallout) nel proxy API sta richiedendo 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 trascorso più tempo.
  6. Se osservi il tempo trascorso più lungo in uno qualsiasi dei criteri diversi da quello del callout di servizio, significa che Edge sta impiegando molto tempo per elaborare la richiesta.
  7. Di seguito è riportata una traccia UI di esempio che mostra un tempo trascorso molto elevato sul criterio JavaScript:

  8. Nell'esempio precedente, noti che il criterio JavaScript richiede un tempo insolitamente lungo, pari a circa 245 secondi.

Risoluzione

  1. Controlla se la risposta del criterio ha richiesto molto tempo e se è presente codice personalizzato che potrebbe richiedere molto tempo per l'elaborazione. Se esiste questo codice, prova a correggere/ottimizzare il codice identificato.
  2. Se non esiste un codice personalizzato che potrebbe causare tempi di elaborazione elevati, controlla se i processori di messaggi stanno riscontrando un utilizzo elevato di CPU o memoria:
    1. Se un processore di messaggi riscontra un utilizzo elevato della CPU, genera tre dump dei thread ogni 30 secondi utilizzando il seguente comando: 
      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. Riavvia il processore di messaggi utilizzando il comando riportato di seguito. Questa operazione dovrebbe ridurre la CPU e la memoria. 
      /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 log dei thread dump, del 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'elevato utilizzo di CPU/memoria.

Diagnostica i problemi utilizzando API Monitoring

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 di backend o la piattaforma API.

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