Questa pagina è stata tradotta dall'API Cloud Translation.

timeout del gateway (504)

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione 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 - L'errore 504 Gateway Timeout indica che il client non ha ricevuto una risposta tempestiva dal gateway perimetrale o dal server di backend durante l'esecuzione 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 per una richiesta API tramite la piattaforma Edge sarà Client -> Per fresatrici verticali -> Processore di messaggi -> Server di backend, 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 adeguati. La piattaforma Edge si aspetta che venga inviata una risposta entro un determinato periodo per ogni richiesta API in base ai valori di timeout. Se non ricevi la risposta entro specificato per il periodo di tempo, viene restituito 504 Gateway Timeout Error.

La tabella seguente fornisce ulteriori dettagli su quando possono verificarsi timeout in Edge:

Timeout occorrenza	Dettagli
Il timeout si verifica nel processore di messaggi	Il server di backend non risponde al processore di messaggi entro un timeout specificato di tempo per il Elaboratore di messaggi. Il processore di messaggi scade e invia lo stato della risposta come `504 Gateway Timeout` al router.
Il timeout si verifica sul router	Il processore di messaggi non risponde al router entro il timeout specificato punto sul router. Il router scade e invia lo stato della risposta `504 Gateway Timeout` all'applicazione client.
Il timeout si verifica nell'applicazione client	Il router non risponde all'applicazione client entro il timeout specificato punto sul router. L'applicazione client scade e termina lo stato della risposta per l'utente finale come `504 Gateway Timeout`.

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 un rendimento scarso.	Utenti di cloud pubblico e privato
Elaborazione lenta delle richieste API da parte di Edge	Edge impiega molto tempo per elaborare la richiesta API a causa di un carico elevato o di una scarsa qualità le prestazioni dei dispositivi.

Lenta server di backend

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

Il processore di messaggi scade prima che il server di backend risponda.
Timeout del router prima che il processore di messaggi/il server di backend risponda.
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 base a ciascuna delle seguenti opzioni: diversi 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 server di backend lento.

Procedura n. 1: utilizzo di Trace

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

Traccia l'API interessata nella UI perimetrale. Attendi che si verifichi l'errore oppure se hai quindi effettua alcune chiamate API e riproduci l'errore 504 Gateway Timeout.
Una volta che si è verificato l'errore, esamina la richiesta specifica che mostra il codice di risposta come 504.
Controlla il tempo trascorso in ogni fase e prendi nota della fase in cui la maggior parte del tempo è speso.
Se noti l'errore con il tempo trascorso più lungo subito dopo uno dei le fasi successive, significa che il server di backend è lento o elaborare la richiesta:
- Richiesta inviata al server di destinazione
- Norme ServiceCallout

Di seguito viene fornita una traccia di esempio che mostra che il server di backend non ha risposto nemmeno dopo 55 secondi, con un conseguente errore di 504 Gateway Timeout:

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

Procedura 2: utilizzo dei log del processore di messaggi

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

Se trovi errori Gateway Timeout e onTimeoutRead per la richiesta proxy API specifica nel momento specifico, vuol dire che il processore 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, noterai che il server di backend è indicato con l'IP indirizzo XX.XX.XX.XX non ha risposto nemmeno dopo 55 secondi (lastIO=55000ms). Di conseguenza, il processore di messaggi ha raggiunto il timeout e ha inviato 504 Gateway Timeout errore.

Controlla quanto segue: Come viene controllato il timeout nel processore di messaggi?

Come viene controllato il timeout sul processore di messaggi? I processori di messaggi di solito impostato con un valore di timeout predefinito di 55 secondi) tramite la proprietà HTTPTransport.io.timeout.millis. Il 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 messaggio Il processore scade e invia 504 Gateway Timeout errore al client.
Il valore di timeout specificato nel processore di messaggi può essere sovrapposto dalla proprietà io.timeout.millis specificato nel proxy API. Questo valore di timeout è applicabile a un'API specifica Proxy in cui è specificata la proprietà sopra indicata. Ad esempio, se io.timeout.millis è impostato su 10 secondi nel proxy API, quindi per questo specifico proxy API verrà usato il valore di timeout di 10 secondi.
- Se il server di backend non risponde entro 10 secondi per l'errore il proxy API, poi il processore di messaggi scade e invia 504 Gateway Timeout al client.

Risoluzione

Verifica perché il server di backend impiega più di 55 secondi e verifica se può corretti/ottimizzati per una risposta più rapida.
Se non è possibile correggere/ottimizzare il server di backend o è noto che il server richiede più tempo del timeout configurato, quindi Aumenta il valore di timeout sul router e sul processore di messaggi impostando un valore appropriato.

Scenario N. 2 - Timeout del router prima che il processore di messaggi/il server di backend risponda

Potresti ricevere 504 Gateway Timeout di errori se il router scade prima del messaggio Il processore/server di backend risponde. Ciò può verificarsi in una delle seguenti circostanze:

Il valore di timeout impostato sul router è più breve del valore di timeout impostato sul messaggio Processore. Ad esempio, supponiamo che il timeout sul router sia 50 secondi e che Il processore dura 55 secondi.

Timeout sul router Timeout sul processore di messaggi

50 secondi 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 nella configurazione dell'endpoint di destinazione del proxy API:

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

Timeout sul router	Timeout sul 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>

Il processore di messaggi non si spegnerà dopo 55 secondi anche se è in timeout (55 secondi) è inferiore al valore di timeout sul router (57 secondi). Questo perché il valore di timeout di 55 secondi sul processore di messaggi viene sostituito dal valore di 120 secondi impostati all'interno del proxy API. Quindi il valore di timeout del processore di messaggi per questo specifico proxy API sarà di 120 secondi.

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

Diagnosi

Controlla il log di accesso a NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
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 il processore di messaggi verrà impostato su -. Questo perché il router non ha ricevuto 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
Nell'esempio precedente, nota lo stato di 504 su NGINX, l'ID del messaggio Il processore è - e il tempo totale trascorso è di 57,001 secondi. Questo perché il timeout del router dopo 57,001 secondi e non otteniamo alcuna risposta dal processore di messaggi.

In questo caso, vedrai Broken Pipe eccezioni nella sezione Log del processore (/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 che il router è in timeout, chiude la connessione con Processore di messaggi. Quando il processore di messaggi completa l'elaborazione, tenta di scrivere la risposta desiderata al router. Poiché la connessione al router è già chiusa, ricevi Broken Pipe exception su Message Processor.

Questa eccezione dovrebbe essere osservata nelle circostanze illustrate sopra. Quindi l'effettiva la causa dell'errore 504 Gateway Timeout è che il server di backend impiega ancora più tempo per rispondere e devi risolvere il problema.

Risoluzione

Se si tratta di un server di backend personalizzato,

Verifica perché il server di backend impiega molto tempo per rispondere e verifica se può essere corretti/ottimizzati per una risposta più rapida.

Se non è possibile correggere/ottimizzare il server di backend o è un fatto noto che richiede molto tempo, quindi Aumenta il valore di timeout router e processore di messaggi.

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

Timeout sul client > Timeout sul router > Timeout del messaggio Processore > Timeout nel proxy API

Se è un server di backend NodeJS, allora:
1. Verifica se il codice NodeJS effettua chiamate ad altri server di backend e se sta accettando molto tempo per restituire una risposta. Verifica perché i server di backend impiegano più tempo risolvere il problema nel modo opportuno.
2. Controlla se i processori di messaggi registrano un utilizzo elevato di CPU o memoria:
  1. Se un processore di messaggi riscontra un elevato utilizzo della CPU, genera tre thread dump ogni 30 secondi utilizzando il seguente comando:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Se un processore di messaggi riscontra un elevato utilizzo della memoria, genera un heap dump 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 seguente. Dovrebbe abbassare la CPU e 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 il dump dei thread, dump dell'heap e log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log)per aiutarti indaga sulla causa dell'utilizzo elevato di CPU/memoria.

Seleziona questa opzione: come viene controllato il timeout per i server di backend NodeJS sul messaggio Processore

Il server di backend NodeJS viene eseguito all'interno del processo JVM del processore di messaggi. La il valore di timeout per i server di backend NodeJS è controllato tramite la proprietà http.request.timeout.seconds in nodejs.properties file. Questo è impostato su 0 per impostazione predefinita, ovvero il timeout è disattivato per impostazione predefinita per tutte le 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 scade.
Tuttavia, se il server di backend NodeJS richiede molto tempo e se il tempo impiegato dall'API La richiesta è > 57 secondi, il router si spegnerà e invierà 504 Gateway Timeout al client.

Scenario 3: timeout dell'applicazione client prima del router/del processore di messaggi/del server di backend risponde

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

Il valore di timeout impostato per l'applicazione client è inferiore al valore di timeout impostato nella router e processore di messaggi:

Ad esempio, se vengono 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 ottenere una risposta a una richiesta API mediante Edge è <= 50 secondi. tra cui il tempo necessario per effettuare una richiesta API, in quanto la richiesta è elaborata da Edge (router, processore di messaggi), la richiesta inviata al server di backend (se applicabile), backend che elabora la richiesta e invio della risposta, Edge elabora il per poi inviarla nuovamente al client.

Se il router non risponde al client entro 50 secondi, quest'ultimo timeout e la connessione al router viene chiusa. 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 connessione.

Diagnosi

Se l'applicazione client scade prima di ricevere una risposta dal router, chiudi la connessione con il router. In questo caso, viene visualizzato il codice di stato 499 in i log di accesso NGINX per la richiesta API specifica.
Esempio di voce di log NGINX con il codice di stato 499
Nell'esempio precedente, tieni presente che lo stato di 499 in NGINX e il tempo totale trascorso sono 50,001 secondi. Questo indica che il client è scaduto dopo 50,001 secondi.

In questo caso, vedrai Broken Pipe di eccezioni nel messaggio Log del processore (/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>

Una volta che il router è in timeout, chiude la connessione con il processore di messaggi. Quando Il processore di messaggi completa l'elaborazione e tenta di scrivere la risposta sul router. Poiché la connessione al router è già chiusa, vedrai Broken Pipe exception sul processore di messaggi.
Questa eccezione è prevista nelle circostanze illustrate sopra. Quindi la causa effettiva per l'errore 504 Gateway Timeout è ancora che il server di backend impiega molto tempo per rispondere e devi risolvere il problema.

Risoluzione

Se si tratta del tuo server di backend personalizzato:

Controlla il server di backend per determinare perché impiega più di 57 secondi e vedi se può essere corretta/ottimizzata per rispondere più velocemente.

Se non è possibile correggere/ottimizzare il server di backend o se sai che richiede molto tempo, quindi aumenta il valore di timeout router e processore di messaggi.

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

Timeout sul client > Timeout sul router > Timeout del messaggio Processore > Timeout nel proxy API

Se è un backend NodeJS, allora:
1. Verifica se il codice NodeJS effettua chiamate ad altri server di backend e se si tratta impiegando molto tempo per tornare. Verifica perché i server di backend impiegano 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 elevato utilizzo della CPU, genera tre thread dump ogni 30 secondi utilizzando il seguente comando:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Se un processore di messaggi riscontra 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. Riavvia il processore di messaggi utilizzando il comando seguente. Questo dovrebbe ridurre CPU e 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 il dump dei thread, dump dell'heap e log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log)per aiutarli indaga sulla causa dell'utilizzo elevato 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 i tuoi requisiti. Non impostare valori di timeout arbitrariamente grandi. Se hai bisogno di assistenza, contatta Assistenza Apigee Edge.

Router

chown apigee:apigee /opt/apigee/customer/application/router.properties

Crea il file /opt/apigee/customer/application/router.properties nella Router, se non esiste già.

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 di timeout di 120 secondi, impostalo come che segue:

conf_load_balancing_load.balancing.driver.proxy.read.timeout=120

Assicurati che questo file sia di proprietà di apigee:

Riavvia il router:

/opt/apigee/apigee-service/bin/apigee-service edge-router restart

Se hai più di un router, ripeti i passaggi precedenti su tutti i router.

processore di messaggi

Crea file /opt/apigee/customer/application/message-processor.properties in data alla macchina del processore di messaggi, se non esiste già.
Aggiungi la seguente riga a questo file:
```
conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS
```
Ad esempio, se vuoi impostare il valore di timeout di 120 secondi, impostalo come che segue:
```
conf_http_HTTPTransport.io.timeout.millis=120000
```

Assicurati che questo file sia di proprietà di apigee:

chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

Riavvia il processore di messaggi:

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

Se utilizzi più di un processore di messaggi, ripeti i passaggi precedenti su tutte le Processori.

Idea: Imposta il valore di 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, riceverai 504 Gateway Timeout errore.

Diagnosi

Traccia l'API interessata nella UI perimetrale.
Attendi che si verifichi l'errore oppure, se ricevi la chiamata API, effettua alcune chiamate API e riproduci l'errore 504 Gateway Timeout.
Tieni presente che, in questo caso, potresti vedere una risposta corretta in Trace.
1. Timeout del router/client perché il processore di messaggi non risponde il periodo di timeout specificato sul router/client (a seconda del periodo con 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 nella Processore di messaggi si attiva solo se quest'ultimo comunica con un protocollo HTTP/HTTPS di backend. In altre parole, questo timeout non viene attivato quando viene attivato qualsiasi criterio (altri rispetto al criterio ServiceCallout) nel proxy API sta richiedendo molto tempo.
Dopo che si è verificato l'errore, esamina la richiesta specifica con l'attributo di Google Cloud.
Controlla il tempo trascorso in ogni fase e prendi nota della fase in cui la maggior parte del tempo è speso.
Se noti il tempo più lungo trascorso in uno qualsiasi dei criteri diversi dal Servizio del callout, questo indica che Edge sta impiegando molto tempo per elaborare richiesta.
Ecco un esempio di traccia dell'interfaccia utente che mostra un tempo trascorso molto elevato sul criterio JavaScript:
Nell'esempio precedente, noti che il criterio JavaScript accetta una quantità insolitamente lunga di circa 245 secondi.

Risoluzione

Controlla se il criterio ha impiegato molto tempo a rispondere e se è presente codice personalizzato l'elaborazione potrebbe richiedere molto tempo. Se il codice è presente, prova a vedere se riesci correggere/ottimizzare il codice identificato.
Se non è presente un codice personalizzato che potrebbe causare tempi di elaborazione lunghi, controlla se il campo L'utilizzo di CPU o memoria da parte dei processori è elevato:
1. Se un processore di messaggi riscontra un elevato utilizzo della CPU, genera tre thread dump ogni 30 secondi utilizzando il seguente comando:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
2. Se la memoria utilizzata da un processore di messaggi è elevata, genera un'istanza 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 seguente. Questo dovrebbe ridurre la CPU e 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 il thread dump, dump dell'heap e log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log)per aiutarli indaga sulla causa dell'utilizzo elevato di CPU/memoria.

Diagnosticare 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 loro origine. come app per sviluppatori, proxy API, target di backend o la piattaforma API.

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