502 Bad Gateway - TooBigBody

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

Sintomo

L'applicazione client riceve un codice di stato HTTP 502 Bad Gateway con codice di errore protocol.http.TooBigBody come risposta per le chiamate API.

Messaggio di errore

L'applicazione client riceve il seguente codice di risposta: 

HTTP/1.1 502 Bad Gateway

Inoltre, potresti visualizzare il seguente messaggio di errore: 

{
   "fault":{
      "faultstring":"Body buffer overflow",
      "detail":{
         "errorcode":"protocol.http.TooBigBody"
      }
   }
}

Possibili cause

Questo errore si verifica se le dimensioni del payload inviate dal server di destinazione/backend ad Apigee Edge come parte della risposta HTTP superano il limite consentito in Apigee Edge.

Di seguito sono riportate le possibili cause dell'errore:

Causa Descrizione Istruzioni per la risoluzione dei problemi applicabili a
La dimensione del payload della risposta è superiore al limite consentito La dimensione del payload inviata dal server di destinazione/backend come parte della risposta HTTP ad Apigee è superiore al limite consentito in Apigee. Utenti di cloud pubblico e privato perimetrale
Le dimensioni del payload della risposta superano il limite consentito dopo la decompressione Le dimensioni del payload inviate in formato compresso dal server di destinazione/backend come parte della risposta HTTP ad Apigee superano il limite consentito quando vengono decompresse da Apigee. 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

Per diagnosticare l'errore utilizzando il monitoraggio delle API:

  1. Accedi alla UI di Apigee Edge come utente con un ruolo appropriato.

  2. Passa all'organizzazione in cui vuoi esaminare il problema.

  3. Vai alla pagina Analizza > Monitoraggio API > Esamina.
  4. Seleziona il periodo di tempo specifico in cui hai riscontrato gli errori.
  5. Puoi selezionare il filtro Proxy per restringere il codice di errore.
  6. Traccia Codice di errore su Ora.

  7. Seleziona una cella con il codice di errore protocol.http.TooBigBody come mostrato di seguito:

  8. Vedrai le informazioni relative al codice di errore protocol.http.TooBigBody, come mostrato di seguito:

  9. Fai clic su Visualizza log ed espandi la riga della richiesta non riuscita.

  10. Nella finestra Log, prendi nota dei seguenti dettagli:
    • Codice di stato: 502
    • Origine errore: target
    • Codice di errore: protocol.http.TooBigBody.
  11. Se l'Origine dell'errore ha il valore target e il Codice di errore ha il valore protocol.http.TooBigBody, ciò indica che la risposta HTTP dal server di destinazione/ di backend ha una dimensione del payload della risposta superiore al limite consentito in Apigee Edge.

Traccia

Per diagnosticare l'errore utilizzando lo strumento Trace:

  1. Abilita la sessione di traccia e:
    • Attendi che si verifichi l'errore 502 Bad Gateway oppure
    • Se riesci a riprodurre il problema, effettua la chiamata API e riproduci l'errore 502 Bad Gateway.
  2. Seleziona una delle richieste non riuscite ed esamina la traccia.
  3. Naviga tra le diverse fasi della traccia e individua il punto in cui si è verificato l'errore.

  4. Vai alla fase Errore subito dopo la fase Risposta ricevuta dal server di destinazione, come mostrato di seguito:

    Prendi nota dei valori dell'errore dalla traccia:

    • errore: Body buffer overflow
    • error.class: com.apigee.errors.http.server.BadGateway

    Questo indica che Apigee Edge (componente Processore di messaggi) genera l'errore non appena riceve la risposta dal server di backend perché le dimensioni del payload superano il limite consentito.

  5. Visualizzerai l'errore nella fase Risposta inviata al client, come illustrato di seguito:

  6. Prendi nota dei valori dell'errore della traccia. La traccia di esempio riportata sopra mostra:
    • errore: 502 Bad Gateway
    • Contenuto dell'errore: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}

  7. Vai alla fase Risposta ricevuta dal server di destinazione come mostrato di seguito per scenari diversi:

    Non compresso

    Scenario 1: payload di risposta inviato in formato non compresso

    Prendi nota dei valori dell'errore dalla traccia:

    • Risposta ricevuta dal server di destinazione: 200 OK
    • Content-Length (dalla sezione Intestazioni delle risposte): ~11 MB

    Compresso

    Scenario 2: payload di richiesta inviato in formato compresso

    Prendi nota dei valori dell'errore dalla traccia:

    • Risposta ricevuta dal server di destinazione: 200 OK
    • Content-Encoding: se vedi questa intestazione nella sezione Intestazioni delle risposte, prendi nota del valore. Ad esempio, in questo esempio il valore è gzip.

  8. Prendi nota del Corpo nella sezione Contenuti della risposta:

    {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}

  9. Vai alla fase AX (Analytics Data Recorded) della traccia e fai clic per visualizzare i dettagli correlati.

  10. Scorri verso il basso in Dettagli fase fino alla sezione Lettura variabili e determina i valori di target.received.content.length che indica:
    • La dimensione effettiva del payload della risposta quando viene inviato in formato non compresso e
    • Le dimensioni del payload della risposta al momento della decompressione da parte di Apigee, quando il payload viene inviato in formato compresso. In questo scenario, il valore sarà sempre uguale al valore del limite consentito (10 MB).

    Non compresso

    Scenario 1: payload di risposta inviato in formato non compresso

    Prendi nota del valore di target.received.content.length:

    Intestazioni delle richieste Valore
    target.received.content.length ~11 MB

    Compresso

    Scenario 2: payload di richiesta inviato in formato compresso

    Prendi nota del valore di target.received.content.length:

    Intestazioni richiesta Valore
    target.received.content.length ~10 MB

  11. La tabella seguente spiega perché l'errore 502 viene restituito da Apigee nei due scenari in base al valore di target.received.content.length:

    Scenario Valore di target.received.content.length Motivo dell'errore
    Payload risposta in formato non compresso ~11 MB Dimensioni > limite consentito di 10 MB
    Payload risposta in formato compresso ~10 MB

    Limite di dimensioni superato al momento della decompressione

NGINX

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

  1. Se sei un utente Private Cloud, puoi utilizzare i log degli accessi di NGINX per determinare le informazioni chiave sugli errori HTTP 502.

  2. Controlla i log degli accessi di NGINX:

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    Dove: ORG, ENV e PORT# vengono sostituiti con i valori effettivi.

  3. Cerca per vedere se si sono verificati errori 502 durante un periodo di tempo specifico (se il problema si è verificato in passato) o se ci sono ancora richieste che continuano a non funzionare con 502.
  4. Se riscontri errori 502 con X-Apigee-fault-code corrispondente al valore di protocol.http.TooBigBody, determina il valore di X-Apigee-fault-code

    Esempio di errore 502 dal log degli accessi di NGINX:

    La voce di esempio sopra riportata dal log degli accessi di NGINX ha i seguenti valori per X-Apigee- fault-code e X-Apigee-fault-source:

    Intestazioni della risposta Valore
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-source target

Causa: le dimensioni del payload della risposta superano il limite consentito

Diagnostica

  1. Determina il codice di errore, l'origine del errore e la dimensione payload della risposta per l'errore osservato utilizzando lo strumento di monitoraggio dell'API, lo strumento Trace o i log degli accessi NGINX, come spiegato nella sezione Passaggi di diagnostica comuni dello scenario n. 1.
  2. Se l'origine dell'errore ha il valore target, significa che la dimensione del payload della risposta inviata dal server di destinazione/backend ad Apigee è superiore al limite consentito in Apigee Edge.
  3. Verifica le Dimensioni payload della risposta come stabilito nel passaggio 1.
  4. Verifica che le dimensioni del payload della risposta siano effettivamente superiori al limite consentito di 10 MB controllando la risposta effettiva seguendo questi passaggi:
    1. Se non hai accesso alla richiesta effettiva inviata al server di destinazione/backend, vai a Risoluzione.
    2. Se hai accesso alla richiesta effettiva fatta al server di destinazione/backend, segui questi passaggi:
      1. Se sei un utente di cloud pubblico/private cloud, effettua una richiesta direttamente al server di backend dal server di backend stesso o da qualsiasi altra macchina da cui ti è consentito effettuare la richiesta al server di backend.
      2. Se sei un utente Private Cloud, puoi anche effettuare la richiesta al server di backend da uno dei processori di messaggi.
      3. Verifica le dimensioni del payload passato nella risposta controllando l'intestazione Content-Length.
      4. Se ritieni che le dimensioni del payload siano superiori al limite consentito in Apigee Edge, allora questa è la causa del problema.

    Risposta di esempio dal server di backend:

    curl -v https://BACKENDSERVER-HOSTNAME/testfile

    * About to connect() to 10.14.0.10 port 9000 (#0)
*   Trying 10.14.0.10...
* Connected to 10.14.0.10 (10.148.0.10) port 9000 (#0)
> GET /testfile HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 10.14.0.10:9000
> Accept: */*
>
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Content-Length: 11534336
< Content-Type: application/octet-stream
< Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
< Date: Wed, 30 Jun 2021 09:22:41 GMT
<
----snipped----
<Response Body>

    Nell'esempio precedente, puoi vedere che Content-Length: 11534336 (which is ~11 MB) è la causa di questo errore poiché supera il limite consentito in Apigee Edge.

Risoluzione

Fai riferimento a Risoluzione.

Causa: le dimensioni del payload della risposta superano il limite consentito dopo la decompressione

Se il payload della risposta viene inviato in formato compresso e l'intestazione della risposta Content-Encoding è impostata su gzip, Apigee decomprime il payload della risposta. Durante il processo di decompressione, se Apigee rileva che le dimensioni del payload sono superiori al limite consentito in Apigee Edge, interrompe ulteriormente la decompressione e risponde immediatamente con 502 Bad Gateway e il codice di errore protocol.http.TooBigBody.

Diagnostica

  1. Determina il codice di errore, l'origine dell'errore e la dimensione payload della risposta per l'errore osservato mediante i log di accesso dell'API Monitoring, Trace Tool o NGINX, come spiegato nella procedura di diagnostica comune per lo scenario n. 2.
  2. Se l'Origine dell'errore ha il valore target, significa che la dimensione del payload della risposta inviata dall'applicazione di destinazione/backend ad Apigee è superiore al limite consentito in Apigee Edge.
  3. Verifica le Dimensioni payload della risposta come stabilito nel passaggio 1.
    • Se le dimensioni del payload superano il limite consentito di 10 MB, questa è la causa dell'errore.
    • Se le dimensioni del payload di ~ 10 MB sono limitate, è possibile che il payload di risposta venga trasmesso in formato compresso. In questo caso, controlla le dimensioni non compresse del payload di risposta compresso.
  4. Puoi utilizzare uno dei seguenti metodi per verificare se la risposta dal target/backend è stata inviata in formato compresso e le dimensioni non compresse sono maggiori del limite consentito:

    Traccia

    Utilizzo dello strumento Trace:

    1. Se hai acquisito una traccia per la richiesta non riuscita, fai riferimento ai passaggi descritti in Trace e
      1. Determina il valore di target.received.content.length.
      2. Verifica se la richiesta del client conteneva l'intestazione Content-Encoding: gzip
    2. Se il valore di target.received.content.length si avvicina al limite consentito di 10 MB e l'intestazione della risposta Content-Encoding: gzip, allora questa è la causa di questo errore.

    Richiesta effettiva

    Utilizzo della richiesta effettiva:

    1. Se non hai accesso alla richiesta effettiva inviata al server di destinazione/backend, vai a Risoluzione.
    2. Se hai accesso alla richiesta effettiva fatta al server di destinazione/backend, segui questi passaggi:
      1. Verifica la dimensione del payload passato nella risposta insieme all'intestazione Content-Encoding inviata nella risposta.
      2. Se scopri che l'intestazione della risposta Content-Encoding è impostata su gzip e che le dimensioni non compresse del payload sono superiori al limite consentito in Apigee Edge, questa è la causa di questo errore.

        Esempio di risposta ricevuta dal server di backend:

        curl -v https://BACKENDSERVER-HOSTNAME/testzippedfile.gz

        * About to connect() to 10.1.0.10 port 9000 (#0)
*   Trying 10.1.0.10...
* Connected to 10.1.0.10 (10.1.0.10) port 9000 (#0)
> GET /testzippedfile.gz HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 10.1.0.10:9000
> Accept: */*
>
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Content-Encoding: gzip
< Content-Type: application/x-gzip
< Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
< Testheader: test
< Date: Wed, 07 Jul 2021 10:14:16 GMT
< Transfer-Encoding: chunked
<
----snipped----
<Response Body>

        Nel caso precedente, viene inviata l'intestazione Content-Encoding: gzip e la dimensione del file testzippedfile.gz nella risposta è inferiore al limite, tuttavia la dimensione del file non compresso testzippedfile era di circa 15 MB.

    Log del processore di messaggi

    Utilizzo dei log del processore di messaggi:

    1. Se sei un utente Private Cloud, puoi utilizzare i log del processore di messaggi per determinare le informazioni chiave sugli errori HTTP 502.

    2. Controlla i log del processore di messaggi

      /opt/apigee/var/log/edge-message-processor/logs/system.log

    3. Cerca per vedere se si sono verificati errori 502 durante un periodo di tempo specifico (se il problema si è verificato in passato) o se ci sono ancora richieste che continuano a non riuscire con 502. Puoi utilizzare le seguenti stringhe di ricerca:

      grep -ri "chunkCount"

      grep -ri "BadGateway: Body buffer overflow"
    4. Troverai righe da system.log simili a quelle mostrate di seguito (TotalRead e chunkCount potrebbero variare nel tuo caso): 
      2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.SERVICE -
TrackingInputChannel.checkMessageBodyTooLarge() : Message is too large.
TotalRead 10489856 chunkCount 2571

2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.CLIENT -
HTTPClient$Context.onInputException() :
ClientInputChannel(ClientChannel[Connected:
Remote:10.148.0.10:9000 Local:10.148.0.9:42240]@9155
useCount=1 bytesRead=0 bytesWritten=182 age=23ms  lastIO=0ms
isOpen=true).onExceptionRead exception: {}
com.apigee.errors.http.server.BadGateway: Body buffer overflow

2021-07-07 09:40:47,012  NIOThread@7 ERROR
ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
AbstractResponseListener.onError(HTTPResponse@77cbd7c4,
Body buffer overflow)

    5. Durante il processo di decompressione, non appena il processore di messaggi stabilisce che i byte totali letti sono > 10 MB, si interrompe e stampa la riga seguente:

      Message is too large. TotalRead 10489856 chunkCount 2571

      Ciò implica che la dimensione payload della risposta è superiore a 10 MB e Apigee genera l'errore quando la dimensione inizia a superare il limite di 10 MB con codice di errore come protocol.http.TooBigBody

Risoluzione

Correggi dimensione

Opzione 1 [consigliata]: correggi l'applicazione server di destinazione in modo che non invii una dimensione del payload superiore al limite di Apigee

  1. Analizza il motivo per cui il server di destinazione specifico deve inviare le dimensioni della risposta / del payload oltre il limite consentito in base a quanto definito in Limiti.
  2. Se non è opportuno, modifica l'applicazione server di destinazione in modo che invii le dimensioni della risposta / del payload inferiori al limite consentito.
  3. Se è opportuno e vuoi inviare una risposta/payload superiore al limite consentito, vai alle opzioni successive.

Pattern URL firmato

Opzione 2 [consigliata]: utilizza il pattern di URL firmati all'interno di un JavaCallout Apigee

Per payload superiori a 10 MB, Apigee consiglia di utilizzare un pattern URL firmato all'interno di un JavaCallout di Apigee, illustrato dall'esempio Edge Callout: Signed URL Generator su GitHub.

live streaming

Opzione 3: utilizza lo streaming

Se il proxy API deve gestire richieste e/o risposte molto grandi, puoi abilitare i flussi di dati in Apigee.

CwC

Opzione 4: utilizza la proprietà CwC per aumentare il limite del buffer

Questa opzione deve essere utilizzata solo quando non è possibile utilizzare nessuna delle opzioni consigliate, poiché potrebbero verificarsi problemi di prestazioni se viene aumentata la dimensione predefinita.

Apigee fornisce una proprietà CwC che consente di aumentare il limite di dimensione del payload di richieste e risposte. Per maggiori dettagli, consulta Impostare il limite per le dimensioni dei messaggi sul router o sul processore di messaggi.

Limiti

Apigee si aspetta che l'applicazione client e il server di backend non inviino dimensioni dei payload superiori al limite consentito come documentato per Request/response size in Limiti di Apigee Edge.

  1. Se sei un utente del cloud pubblico, il limite massimo per le dimensioni del payload di richiesta e risposta è come documentato per Request/response size in Limiti di Apigee Edge.
  2. Se sei un utente Private Cloud , potresti aver modificato il limite massimo predefinito per le dimensioni del payload delle richieste e delle risposte (anche se non è una pratica consigliata). Puoi determinare il limite massimo della dimensione del payload delle richieste seguendo le istruzioni in Come verificare il limite attuale.

Come si controlla il limite attuale?

Questa sezione spiega come verificare che la proprietà HTTPResponse.body.buffer.limit sia stata aggiornata con un nuovo valore nei processori di messaggi.

  1. Sul computer del processore di messaggi, cerca la proprietà HTTPResponse.body.buffer.limit nella directory /opt/apigee/edge-message- processor/conf e controlla quale valore è stato impostato come mostrato di seguito:

    grep -ri "HTTPResponse.body.buffer.limit" /opt/apigee/edge-message-processor/conf

  2. Il risultato di esempio del comando riportato sopra è il seguente:

    /opt/apigee/edge-message-processor/conf/http.properties:HTTPResponse.body.buffer.limit=10m

  3. Nell'output di esempio riportato sopra, nota che la proprietà HTTPResponse.body.buffer.limit è stata impostata con il valore 10m in http.properties.

    Questo indica che il limite per le dimensioni del payload delle richieste configurate in Apigee per il cloud privato è di 10 MB.

Se hai ancora bisogno di aiuto dall'Assistenza Apigee, vai a È necessario raccogliere dati diagnostici.

Devi raccogliere dati diagnostici

Raccogli le seguenti informazioni diagnostiche e poi contatta l'assistenza Apigee Edge:

Se sei un utente del cloud pubblico, fornisci le seguenti informazioni:

  • Nome dell'organizzazione.
  • Nome ambiente
  • Nome proxy API
  • Comando curl completo utilizzato per riprodurre l'errore 502
  • File di traccia per le richieste API
  • Output completo della risposta dal server di destinazione/backend insieme alle dimensioni del payload

Se sei un utente Private Cloud, fornisci le seguenti informazioni:

  • Messaggio di errore completo osservato per le richieste non riuscite
  • Nome dell'organizzazione.
  • Nome ambiente
  • Bundle del proxy API
  • File di traccia per le richieste API non riuscite
  • Comando curl completo utilizzato per riprodurre l'errore 502
  • Output completo della risposta dal server di destinazione/backend insieme alle dimensioni del payload

  • Log degli accessi NGINX /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    Dove: ORG, ENV e PORT# vengono sostituiti con i valori effettivi.

  • Log di sistema del processore di messaggi /opt/apigee/var/log/edge-message-processor/logs/system.log