Questa pagina è stata tradotta dall'API Cloud Translation.

504 Timeout del gateway - Timeout del router

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 in risposta alle chiamate API.

Questa risposta di errore indica che il client non ha ricevuto una risposta tempestiva da Apigee Edge o dal server di backend durante l'esecuzione di una chiamata API.

Messaggio di errore

L'applicazione client riceve il seguente codice di risposta:

HTTP/1.1 504 Gateway Time-out

Quando chiami questo proxy utilizzando cURL o un browser web, potresti ricevere il seguente errore:

<!DOCTYPE html>
<html>
<head>
<title>Error</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>An error occurred.</h1>
<p>Sorry, the page you are looking for is currently unavailable.<br/>
Please try again later.</p>
</body>
</html>

Quali sono le cause dei timeout?

Il percorso tipico per una richiesta API tramite la piattaforma Edge è Cliente > Router > Processore di messaggi > Server di backend, come mostrato nella figura seguente:

Tutti i componenti del flusso di runtime Apigee Edge, tra cui client, router, processori di messaggi e server di backend, sono configurati con valori di timeout predefiniti adatti per garantire che il completamento delle richieste API non richieda troppo tempo. Se uno dei componenti del flusso non riceve la risposta dal componente upstream entro il periodo di tempo specificato nella configurazione di timeout, il componente specifico andrà in timeout e in genere restituirà un errore 504 Gateway Timeout.

Questo playbook descrive come risolvere un errore 504 causato dal timeout del router.

Timeout sul router

Il timeout predefinito configurato sui router in Apigee Edge è di 57 secondi. Si tratta della quantità massima di tempo in cui un proxy API può essere eseguito dal momento in cui la richiesta API viene ricevuta su Edge fino al reinvio della risposta, inclusi la risposta del backend e tutti i criteri eseguiti. Il timeout predefinito può essere ignorato sui router/host virtuali, come spiegato in Configurare il timeout di I/O sui router.

Possibili cause

In Edge, le cause tipiche dell'errore 504 Gateway Timeout causato dal timeout del router sono:

Causa	Descrizione	Istruzioni per la risoluzione dei problemi applicabili a
Configurazione del timeout non corretta sul router	Questo accade se il router è configurato con un periodo di timeout I/O non corretto.	Utenti di cloud pubblico e privato perimetrale

Passaggi di diagnosi più comuni

Utilizza uno dei seguenti strumenti/tecniche per diagnosticare questo errore:

Monitoraggio delle API
Log degli accessi NGINX

Monitoraggio delle API

Per diagnosticare l'errore utilizzando il monitoraggio delle API:

Vai alla pagina Analizza > Monitoraggio API > Esamina.
Filtra per 5xx errori e seleziona il periodo di tempo.
Traccia Codice di stato in base a Ora.
Fai clic sulla cella specifica che mostra 504 errori per visualizzare ulteriori dettagli e visualizzare i log relativi a questi errori, come mostrato di seguito:

Esempio di errori 504
Nel riquadro a destra, fai clic su Visualizza log.

Nella finestra Log di traffico, tieni presente i seguenti dettagli relativi ad alcuni errori 504:
- Request:fornisce il metodo di richiesta e l'URI utilizzati per effettuare le chiamate.
- Tempo di risposta:indica il tempo totale trascorso per la richiesta.
Nell'esempio precedente,
- La richiesta rimanda a GET /test-timeout.
- Il tempo di risposta è di 57.001 secondi. Questo indica che il timeout del router è scaduto prima che il processore di messaggi possa rispondere poiché il valore è molto vicino al timeout di I/O predefinito impostato sul router, ovvero 57 secondi.
Puoi ottenere tutti i log anche utilizzando l'API GET logs di API Monitoring. Ad esempio, eseguendo una query sui log per org, env, timeRange e status, potresti scaricare tutti i log per le transazioni in cui il client è scaduto.

Poiché API Monitoring imposta il proxy su - (non impostato) per questi 504 errori, puoi utilizzare l'API (API Log) per ottenere il proxy associato per l'host virtuale e il percorso.

For example :
```
curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https
```
Nota:il valore di questo errore 504 verrà visualizzato nei seguenti campi:
- Origine errore
- Codice di errore
- Flusso di guasti
- Criterio di colpa
- Proxy di errore
Questi campi vengono compilati dal processore di messaggi e verranno impostati con valori appropriati solo se il router riceve una risposta dal processore di messaggi. In questo caso, il router ha superato il timeout del processore di messaggi perché non ha risposto in modo tempestivo. In questo modo il router forza l'impostazione del codice di stato su 504 e, di conseguenza, tutti i campi sopra menzionati vengono visualizzati come -.
Esamina il tempo di risposta per verificare la presenza di ulteriori errori 504 e controlla se il tempo di risposta è coerente (il valore di timeout I/O impostato sul router è 57 secondi) per tutti gli errori 504.

Log degli accessi NGINX

Per diagnosticare l'errore utilizzando i log degli accessi di NGINX:

Controlla i log degli accessi di NGINX:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
Cerca per vedere se si sono verificati errori 504 durante una durata specifica (se il problema si è verificato in passato) o se ci sono ancora richieste che continuano a non riuscire a utilizzare 504.
Tieni presente le seguenti informazioni per alcuni errori 504:
- Tempo di risposta
- URI della richiesta
In questo esempio, vediamo le seguenti informazioni:
- Tempo richiesta: 57.001 secondi. Questo indica che il router è scaduto dopo 57.001 secondi.
  
  Nota: rappresenta il campo request_time nei log NGINX. Indica il tempo di elaborazione delle richieste in secondi; il tempo trascorso tra i primi byte letti dal client e la scrittura del log dopo l'invio degli ultimi byte al client.
- Richiesta: GET /test-timeout
- Alias host: myorg-test.apigee.net
Nota: nei seguenti campi verrà visualizzato il valore - per questo errore 504:
- Origine errore
- Codice di errore
- Flusso di guasti
- Criterio di colpa
- Proxy di errore
Questi campi vengono compilati dal processore di messaggi e verranno impostati con valori appropriati solo se il router riceve una risposta dal processore di messaggi. In questo caso, il router ha superato il timeout del processore di messaggi perché non ha risposto in modo tempestivo. In questo modo il router forza l'impostazione del codice di stato su 504 e, di conseguenza, tutti i campi sopra menzionati vengono visualizzati come -.
Verifica che l'orario della richiesta corrisponda al timeout I/O configurato sul router/host virtuale. Se sì, significa che il timeout del router è stato eseguito prima che il processore di messaggi non rispondesse entro questo periodo.

Nell'esempio di voce del log degli accessi NGINX mostrato sopra, il valore Request Time di 57.001 secondi è molto vicino al timeout di I/O predefinito impostato sul router. Questo indica chiaramente che il router è scaduto prima che il processore di messaggi possa rispondere.
Determina il proxy API per il quale è stata effettuata la richiesta utilizzando il percorso di base nel campo Richiesta .

Causa: configurazione del timeout errata sul router

Diagnostica

Determina se gli errori 504 sono causati dal timeout del router prima che il processore di messaggi possa rispondere. Puoi farlo controllando se il Tempo di risposta in Monitoraggio API/Tempo richiesta nel router (entrambi i campi rappresentano le stesse informazioni,ma sono chiamati con nomi diversi) è lo stesso del timeout I/O configurato sul router/host virtuale e i campi Origine errore, Proxy di errore e Codice di errore sono impostati su - utilizzando i passaggi della diagnostica degli accessi NGINX come spiegato nei log comuni della diagnosi degli accessi.
Verifica se il valore di timeout di I/O configurato sul router o sull'host virtuale specifico è inferiore rispetto a quello configurato sul processore di messaggi o sul proxy API specifico.

A tale scopo, segui i passaggi descritti in questa sezione.

Verifica del timeout I/O sugli host virtuali

UI perimetrale

Per verificare il timeout dell'host virtuale utilizzando la UI Edge, segui questi passaggi:

Accedi all'interfaccia utente Edge.
Vai ad Admin > Virtual Hosts (Amministrazione > Host virtuali).
Seleziona un ambiente specifico in cui riscontri il problema di timeout.
Seleziona l'host virtuale specifico per il quale vuoi verificare il valore di timeout I/O.
In Proprietà, visualizza il valore Timeout lettura proxy in secondi.

Nell'esempio precedente, il Timeout lettura proxy è configurato con il valore 120. Ciò significa che il timeout di I/O configurato su questo host virtuale è di 120 secondi.

Nota: se non è presente alcun valore per Timeout lettura proxy, verrà utilizzato il valore predefinito di 57 secondi configurato sul router (a meno che il timeout I/O non venga sostituito sulle istanze del router).

API di gestione

Puoi anche verificare il Timeout lettura proxy utilizzando le seguenti API di gestione:

Esegui l'API Get virtual host per ottenere la configurazione virtualhost come mostrato di seguito:

Utente del cloud pubblico

curl -v -X GET https://api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/virtualhosts/VIRTUALHOST_NAME -u USERNAME

Utente Private Cloud

curl -v -X GET http://MANAGEMENT_SERVER_HOST:PORT#/v1/organizations/ORGANIZATION_NAME/environments/v/virtualhosts/VIRTUALHOST_NAME -u USERNAME

Dove:

ORGANIZATION_NAME è il nome dell'organizzazione

ENVIRONMENT_NAME è il nome dell'ambiente

VIRTUALHOST_NAME è il nome dell'host virtuale

Verifica il valore configurato per la proprietà proxy_read_timeout

Esempio di definizione di host virtuale

{
  "hostAliases": [
    "api.myCompany,com",
  ],
  "interfaces": [],
  "listenOptions": [],
  "name": "secure",
  "port": "443",
  "retryOptions": [],
  "properties": {
    "property": [
      {
        "name": "proxy_read_timeout",
        "value": "120"
      }
    ]
  },
  "sSLInfo": {
    "ciphers": [],
    "clientAuthEnabled": "false",
    "enabled": "true",
    "ignoreValidationErrors": false,
    "keyAlias": "myCompanyKeyAlias",
    "keyStore": "ref://myCompanyKeystoreref",
    "protocols": []
  },
  "useBuiltInFreeTrialCert": false
}

Nell'esempio precedente, proxy_read_timeout è configurato con un valore di 120. Ciò significa che il timeout di I/O configurato su questo host virtuale è di 120 secondi.

Nota: se la proprietà proxy_read_timeout non esiste nell'output dell'API di gestione, il valore predefinito sarà di 57 secondi (a meno che il timeout I/O non venga sostituito nelle istanze del router).

Verifica del timeout I/O nel file router.properties

Accedi a un router.
Cerca la proprietà proxy_read_timeout nella directory /opt/nginx/conf.d e controlla se è stata impostata con il nuovo valore come segue:
```
grep -ri "proxy_read_timeout" /opt/nginx/conf.d
```
Controlla il valore impostato per la proprietà proxy_read_timeout nello specifico file di configurazione dell'host virtuale.

Risultato di esempio del comando grep
```
/opt/nginx/conf.d/0-default.conf:proxy_read_timeout 57;
/opt/nginx/conf.d/0-edge-health.conf:proxy_read_timeout 1s;
```
Nell'output di esempio riportato sopra, puoi notare che la proprietà proxy_read_timeout è stata impostata con il nuovo valore 57 in 0-default.conf, che è il file di configurazione per l'host virtuale predefinito. Ciò indica che il timeout I/O è configurato su 57 secondi sul router per l'host virtuale predefinito. Se disponi di più host virtuali, vedrai queste informazioni per ciascuno di essi. Ottieni il valore di proxy_read_timeout per l'host virtuale specifico che hai utilizzato per effettuare le chiamate API non riuscite con errori 504.

Verifica del timeout I/O nel proxy API

Puoi visualizzare il timeout I/O in:

Endpoint di destinazione del proxy API
Norme ServiceCallout del proxy API

Visualizza il timeout I/O nell'endpoint di destinazione del proxy API

Nella UI Edge, seleziona il proxy API specifico in cui vuoi visualizzare il valore di timeout I/O.
Seleziona l'endpoint di destinazione specifico che vuoi controllare.
Visualizza la proprietà io.timeout.millis con un valore appropriato sotto l'elemento <HTTPTargetConnection> nella configurazione TargetEndpoint.
Ad esempio, il timeout I/O nel codice seguente è impostato su 120 secondi:
```
<Properties>
  <Property name="io.timeout.millis">120000</Property>
</Properties>
```

Visualizza il timeout I/O nel criterio ServiceCallout del proxy API

Nella UI di Edge, seleziona il proxy API specifico in cui vuoi visualizzare il nuovo valore di timeout I/O per il criterio ServiceCallout.
Seleziona le norme specifiche di ServiceCallout che vuoi controllare.
Visualizza l'elemento <Timeout> con un valore appropriato nella configurazione <ServiceCallout>.

Ad esempio, il timeout I/O del seguente codice sarà di 120 secondi:
```
<Timeout>120000</Timeout>
```

Verifica del timeout I/O sui processori di messaggi

Accedi al computer dell'elaboratore di messaggi.

Cerca la proprietà HTTPTransport.io.timeout.millis nella directory /opt/apigee/edge-message-processor/conf utilizzando il seguente comando:

grep -ri "HTTPTransport.io.timeout.millis" /opt/apigee/edge-message-processor/conf

Esempio di output

/opt/apigee/edge-message-processor/conf/http.properties:HTTPTransport.io.timeout.millis=55000

Nell'output di esempio riportato sopra, nota che la proprietà HTTPTransport.io.timeout.millis è stata impostata con il valore 55000 in http.properties. Questo indica che il timeout I/O è stato configurato correttamente su 55 secondi sul processore di messaggi.

Una volta determinato il timeout configurato sul router e sul processore di messaggi, verifica che il router/l'host virtuale sia stato configurato con un valore di timeout inferiore rispetto a quello del proxy API/router dei messaggi.

Prendi nota dei valori impostati su tutti i livelli, come mostrato nella tabella di seguito:

Timeout sul router (secondi)	Timeout sull'host virtuale (secondi)	Timeout sul processore di messaggi (secondi)	Timeout sul proxy API (secondi)
57	-	55	120

In questo esempio,

Sul router è configurato il valore predefinito di 57 secondi.
Il valore di timeout non è impostato sull'host virtuale specifico. Ciò significa che verrà utilizzato il valore predefinito di 57 secondi configurato sul router stesso.
Sul processore di messaggi è configurato un valore predefinito di 55 secondi.
Tuttavia, sul proxy API specifico, viene configurato un valore di 120 secondi.

Tieni presente che il valore di timeout più elevato viene configurato solo sul proxy API, ma il router è ancora configurato con 57 secondi. Di conseguenza, il timeout del router avviene a 57 secondi mentre il processore di messaggi/backend è ancora in fase di elaborazione della richiesta. In questo modo il router risponde con l'errore 504 Gateway Timeout all'applicazione client.

Risoluzione

Completa i seguenti passaggi per configurare il timeout I/O corretto sul router e sul processore di messaggi al fine di risolvere il problema.

Consulta le Best practice per la configurazione del timeout I/O per capire quali valori di timeout devono essere impostati sui diversi componenti coinvolti nel flusso di richieste API attraverso Apigee Edge.
Nell'esempio precedente, se verifichi che è necessario impostare un valore di timeout più elevato perché il server di backend richiede un tempo più lungo e hai aumentato il valore di timeout del processore di messaggi a 120 secondi, imposta un valore di timeout più alto. Ad esempio: 123 seconds sul router. Per evitare un impatto su tutti i proxy API a causa del nuovo valore di timeout, imposta il valore di 123 seconds solo sull'host virtuale specifico che viene utilizzato nel proxy API specifico.
Segui le istruzioni in Configurare il timeout I/O sui router per impostare il timeout sull'host virtuale.