timeout del gateway (504)

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

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 indica che il client non ha ricevuto una risposta tempestiva dall'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 per una richiesta API tramite la piattaforma Edge sarà Client -> Router -> processore di messaggi -> Backend Server, 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 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 maggiori dettagli su quando possono verificarsi timeout in Edge:

Occorrenza del timeout Dettagli
Si verifica un timeout 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 processore di messaggi va in timeout e invia lo stato della 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 va in timeout e invia lo stato della risposta come 504 Gateway Timeout all'applicazione client.
Si verifica il timeout nell'applicazione client
  • Il router non risponde all'applicazione client entro il periodo di timeout specificato sul router.
  • L'applicazione client va in timeout 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 Passaggi forniti per
Server di backend lento Il server di backend che elabora la richiesta API è troppo lento a causa del carico elevato o delle 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 API a causa del carico elevato o delle prestazioni scarse.

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. Il processore di messaggi va in timeout prima che il server di backend risponda.
  2. Il router va in timeout prima che il processore di messaggi/server di backend risponda.
  3. L'applicazione client va in timeout 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 va in timeout prima che il server di backend risponda

Diagnosi

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

Procedura n. 1: utilizzo di Trace

Se il problema è ancora attivo (gli errori 504 si verificano ancora), segui i passaggi riportati di seguito:

  1. Traccia l'API interessata nell'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 verificatosi 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 trascorso più tempo.
  4. Se osservi l'errore con il tempo trascorso più lungo immediatamente 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
    • Criterio ServiceCallout

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 riportata sopra, il processore di messaggi va in timeout dopo 55002 ms perché il server di backend non risponde.

Procedura n. 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 specifica del proxy API in un momento specifico, significa che il processore di messaggi ha raggiunto il timeout.

    Esempio di log del processore di messaggi che mostra l'errore Gateway Timeout

    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 nemmeno dopo 55 secondi (lastIO=55000ms). Di conseguenza, il processore di messaggi ha raggiunto il timeout e ha inviato l'errore 504 Gateway Timeout.

    Controlla questo articolo: Come viene controllato il timeout in Message Processor?

    • Come viene controllato il timeout nel processore di messaggi. I Message Processor 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 appartenenti a un'organizzazione gestita da questo processore di messaggi.
      • Se il server di backend non risponde entro 55 secondi, il processore di messaggi va in timeout 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 all'interno del 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 all'interno del proxy API, il valore di timeout di 10 secondi verrà utilizzato per questo proxy API specifico.
      • Se il server di backend non risponde entro 10 secondi per il proxy API specifico, il processore di messaggi va in timeout 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 è possibile risolvere/ottimizzare il problema per rispondere più rapidamente.
  2. Se non è possibile correggere/ottimizzare il server di backend o è noto che il server di backend impiega più tempo del timeout configurato, aumenta il valore di timeout su Router e processore di messaggi a un valore appropriato.

Scenario n. 2: il router va in timeout prima che il processore di messaggi/server di backend risponda

Potresti ricevere errori 504 Gateway Timeout se il router va in timeout prima che il Message Processor/il server di backend risponda. Ciò può verificarsi in una delle seguenti situazioni:

  • Il valore di timeout impostato sul router è inferiore a quello impostato sul processore di messaggi. Ad esempio, supponiamo che il timeout sul router sia di 50 secondi, mentre quello del Message Processor sia di 55 secondi.
    Timeout sul router Timeout del processore di messaggi
    50 secondi 55 secondi
  • Il valore di timeout in Message Processor 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 sono impostati i seguenti valori di timeout:

    Timeout sul router Timeout del processore di messaggi Timeout all'interno del proxy API
    57 secondi 55 secondi 120 secondi

    ma 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>

    In questo modo, il processore di messaggi non andrà in timeout dopo 55 secondi anche se il valore di 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 impostato all'interno del proxy API. Pertanto, il valore di timeout del processore di messaggi 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 all'interno del proxy API, il router andrà in timeout se il server di backend non risponde dopo 57 secondi.

Diagnosi

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

  2. Se il router va in timeout prima del processore di messaggi, vedrai lo stato 504 nei log di accesso NGINX per la richiesta API specifica e message id dal processore di messaggi verrà impostato su -. Ciò è dovuto al fatto che 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 l'errore 504 dovuto al timeout del router

  3. Nell'esempio precedente, nota lo stato di 504 su NGINX, l'ID messaggio del processore di messaggi è - e il tempo totale trascorso è di 57,001 secondi. Ciò è dovuto al fatto che il router è andato in timeout dopo 57,001 secondi e non abbiamo ricevuto alcuna risposta dal processore di messaggi.
  4. In questo caso, vedrai eccezioni Broken Pipe 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 del router, la connessione con il processore di messaggi viene chiusa. Quando il processore di messaggi completa l'elaborazione, tenta di scrivere la risposta al router. Poiché la connessione al router è già chiusa, viene visualizzato Broken Pipe exception sul processore di messaggi.

Questa eccezione dovrebbe essere visualizzata nelle circostanze spiegate sopra. Pertanto, la causa effettiva dell'errore 504 Gateway Timeout è ancora il tempo più lungo impiegato dal server di backend per rispondere e devi risolvere il problema.

Risoluzione

  1. Se si tratta di un server di backend personalizzato, allora
    1. Controlla perché il server di backend impiega molto tempo per rispondere e verifica se può essere corretto/ottimizzato per rispondere più rapidamente.
    2. Se non è possibile correggere/ottimizzare il server di backend o è noto che il server di backend richiede molto tempo, aumenta il valore di timeout su Router e processore di messaggi.

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

      Timeout sul client > Timeout sul router > Timeout sul processore di messaggi > 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 modo appropriato.
    2. Controlla se i Message Processor stanno riscontrando un utilizzo elevato di CPU o memoria utilizzata:
      1. Se un processore di messaggi sta riscontrando un elevato utilizzo della CPU, genera tre dump dei 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. 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 dump dei thread, il dump dell'heap e i log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log)per contribuire a indagare sulla causa dell'elevato utilizzo di CPU/memoria utilizzata.

Controlla questo articolo: Come viene controllato il timeout per i server di backend NodeJS in 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 è disabilitato per impostazione predefinita per tutti i proxy API appartenenti a un'organizzazione gestita da questo processore di messaggi. Quindi, anche se un server di backend NodeJS impiega molto tempo, il processore di messaggi non andrà in 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 andrà in timeout e invierà l'errore 504 Gateway Timeout al client.

Scenario 3: l'applicazione client va in timeout prima che il router, il processore di messaggi o 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 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 del 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. Ciò include il tempo impiegato per effettuare una richiesta API, l'elaborazione della richiesta da parte di Edge (router, processore di messaggi), l'invio della richiesta al server di backend (se applicabile), l'elaborazione della richiesta da parte del backend e l'invio della risposta, l'elaborazione della risposta da parte di Edge e infine l'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, chiuderà la connessione con il router. In questa situazione, vedrai un codice di stato 499 nei log di accesso 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 è 50,001 secondi. Ciò indica che il client ha raggiunto il timeout dopo 50.001 secondi.
  3. In questo caso, vedrai eccezioni Broken Pipe 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. Quando il router raggiunge il timeout, chiude la connessione con il processore di messaggi. Quando il processore di messaggi completa l'elaborazione, tenta di scrivere la risposta al router. Poiché la connessione al router è già chiusa, viene visualizzato Broken Pipe exception nel processore 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 perché impiega più di 57 secondi e verifica se può essere corretto/ottimizzato per rispondere più rapidamente.
    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.

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

      Timeout sul client > Timeout sul router > Timeout sul processore di messaggi > 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 il tempo di risposta è lungo. Controlla perché questi server di backend richiedono più tempo.
    2. Controlla se i Message Processor stanno riscontrando un utilizzo elevato di CPU o memoria:
      1. Se un processore di messaggi sta riscontrando un elevato utilizzo 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 sta riscontrando memoria utilizzata elevata, 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. In questo modo, l'utilizzo di CPU e memoria dovrebbe diminuire: 
        /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 dei thread, il dump dell'heap e i log 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 utilizzata.

Aumenta il valore di timeout su Router e processore di messaggi

Scegli con attenzione i valori di timeout da impostare sul router e sul processore di messaggi in base ai tuoi requisiti. Non impostare valori di timeout arbitrariamente elevati. Se hai bisogno di assistenza, 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 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 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 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 hai più di un processore 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 sul client > Timeout sul router > Timeout sul processore di messaggi > Timeout all'interno del 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 un errore 504 Gateway Timeout.

Diagnosi

  1. Traccia l'API interessata nell'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 riuscita nella traccia.
    1. Il router/client va in timeout perché il processore di messaggi non risponde entro il periodo di timeout specificato sul router/client (quello con il periodo di timeout più breve). 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 viene attivato solo se il processore di messaggi comunica con un server di backend HTTP/HTTPS. In altre parole, questo timeout non viene attivato quando una qualsiasi norma (diversa dalla norma ServiceCallout) all'interno del proxy API 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 trascorso più tempo.
  6. Se osservi il tempo trascorso più lungo in uno qualsiasi dei criteri diversi da quelli del callout del servizio, significa che Edge impiega molto tempo per elaborare la richiesta.
  7. Ecco una traccia dell'interfaccia utente di esempio che mostra un tempo trascorso molto elevato per i criteri JavaScript:

  8. Nell'esempio precedente, noterai che la policy 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 codice personalizzato che potrebbe richiedere molto tempo per l'elaborazione. Se è presente un codice di questo tipo, verifica se puoi correggere/ottimizzare il codice identificato.
  2. Se non è presente codice personalizzato che potrebbe causare un tempo di elaborazione elevato, controlla se i Message Processor stanno riscontrando un utilizzo elevato di CPU o memoria:
    1. Se un processore di messaggi sta riscontrando un elevato utilizzo 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 ha un utilizzo elevato della memoria utilizzata, 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. In questo modo, l'utilizzo di CPU e memoria dovrebbe 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 dei thread, il dump dell'heap e i log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log)) per aiutarli a esaminare la causa dell'elevato utilizzo di CPU/memoria utilizzata.

Diagnostica i problemi utilizzando API Monitoring

API Monitoring ti consente di isolare rapidamente le aree problematiche per diagnosticare errori, problemi di prestazioni e latenza e la loro origine, ad esempio app per sviluppatori, proxy API, target di backend o la piattaforma API.

Segui uno scenario di esempio che mostra come risolvere i problemi 5xx con le API utilizzando API Monitoring. Ad esempio, potresti voler configurare un avviso per ricevere una notifica quando il numero di codici di stato 504 supera una determinata soglia.