502 Bad Gateway - TooBigBody

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 di 502 Bad Gateway con codice di errore protocol.http.TooBigBody in risposta alle chiamate API.

Messaggio di errore

L'applicazione client riceve il seguente codice di risposta: 

HTTP/1.1 502 Bad Gateway

Potresti inoltre visualizzare il seguente messaggio di errore: 

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

Possibili cause

Questo errore si verifica se la dimensione del payload inviata dal server di destinazione/backend ad Apigee Edge di risposta HTTP è superiore al limite consentito in Apigee Edge.

Di seguito sono riportate le possibili cause dell'errore:

Causa Descrizione Le istruzioni di risoluzione dei problemi applicabili a
La dimensione del payload di risposta è superiore al limite consentito La dimensione del payload inviata dal server di destinazione/backend come parte della risposta HTTP ad Apigee è rispetto al limite consentito in Apigee. Utenti perimetrali di cloud pubblici e privati
La dimensione del payload della risposta supera il limite consentito dopo decompressione La dimensione del payload inviato in formato compresso dal server di destinazione/backend come parte di HTTP la risposta ad Apigee supera il limite consentito quando decompresso da Apigee. Utenti perimetrali di cloud pubblici e privati

Passaggi diagnostici comuni

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

Monitoraggio delle API

Per diagnosticare l'errore utilizzando API Monitoring:

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

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

  3. Vai al menu Analizza > Monitoraggio delle API > Esamina.
  4. Seleziona il periodo di tempo specifico in cui hai osservato gli errori.
  5. Puoi selezionare il filtro Proxy per restringere il codice di errore.
  6. Traccia il codice di errore in base all'ora.

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

  8. Verranno visualizzate le informazioni sul 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 il campo Origine di errore ha il valore target e il Codice di errore ha il valore protocol.http.TooBigBody, questo indica che il comando HTTP la risposta dal server di destinazione/ backend ha una dimensione del payload di risposta maggiore di consentito limite in Apigee Edge.

Trace

Per diagnosticare l'errore utilizzando lo strumento Trace:

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

  4. Passa alla fase Errore subito dopo la Risposta ricevuta dall'obiettivo. server come mostrato di seguito:

    Prendi nota dei valori dell'errore della 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 limite.

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

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

  7. Passa 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 della traccia:

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

    Compresso

    Scenario 2: payload di richiesta inviato in formato compresso

    Prendi nota dei valori dell'errore della traccia:

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

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

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

  9. Vai alla fase AX (dati registrati di Analytics) della traccia e fai clic sulla fase. per visualizzarne i dettagli.

  10. In Dettagli fase, scorri verso il basso fino alla sezione Lettura variabili e determina la di target.received.content.length, che indica:
    • La dimensione effettiva del payload della risposta quando viene inviato in formato non compresso e
    • La dimensione del payload di risposta al momento della decompressione da parte di Apigee, quando il payload viene inviati in formato compresso. Sarà sempre uguale al valore del campo consentito (10 MB) in questo scenario.
    di Gemini Advanced.

    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 in i due scenari in base al valore di target.received.content.length:

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

    Limite di dimensioni superato al momento della decompressione

NGINX

Per diagnosticare l'errore utilizzando i log di accesso NGINX:

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

  2. Controlla i log di accesso NGINX:

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

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

  3. Cerca per vedere se ci sono stati 502 errori durante un periodo di tempo specifico (se il problema si è verificato in passato) o se sono presenti richieste che non hanno ancora avuto esito positivo 502.
  4. Se trovi errori 502 con la corrispondenza X-Apigee-fault-code il valore di protocol.http.TooBigBody, quindi determina il valore X-Apigee-fault-source.

    Esempio di errore 502 nel log di accesso NGINX:

    La voce di esempio riportata sopra dal log di accesso NGINX ha i seguenti valori per X-Apigee- codice di errore e fonte-fault-X-Apigee:

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

Causa: la dimensione del payload della risposta è superiore al limite consentito

Diagnosi

  1. Determina il codice errore, l'origine errore e la dimensione payload risposta per l'errore osservato utilizzando il monitoraggio delle API, lo strumento Trace o i log di accesso NGINX, come spiegato in Passaggi diagnostici comuni nello scenario n. 1.
  2. Se l'origine di errore ha il valore target, significa che la risposta la dimensione del payload inviato dal server di destinazione/backend ad Apigee è maggiore di limite consentito in Apigee Edge.
  3. Verifica la Dimensione payload di risposta come determinata nel passaggio 1.
  4. Verifica che la dimensione del payload della risposta sia effettivamente > Limite consentito di 10 MB controllando il la risposta effettiva seguendo questa procedura:
    1. Se non hai accesso alla richiesta effettiva fatta al server di destinazione/backend, quindi 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 un cloud pubblico/un cloud privato, effettua una richiesta direttamente a il server di backend dallo stesso server di backend o da qualsiasi altra macchina da cui per inviare la richiesta al server di backend.
      2. Se sei un utente del Private Cloud, puoi anche inviare la richiesta al di backend da uno dei processori di messaggi.
      3. Verifica la dimensione del payload passato nella risposta controllando le Intestazione Content-Length.
      4. Se scopri che la dimensione del payload è superiore alla limite consentito in Apigee Edge, è la causa problema.

    Esempio di risposta 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), che è la causa di questo errore, supera i limite consentito in Apigee Edge.

Risoluzione

Fai riferimento a Risoluzione.

Causa: la dimensione del payload della risposta supera il limite consentito dopo decompressione

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

Diagnosi

  1. Determina il codice di errore,l'origine di errore e la dimensione del payload di risposta per l'errore osservato utilizzando i log di monitoraggio delle API, strumento di tracciamento o accesso NGINX, come spiegato in Passaggi diagnostici comuni nello scenario n. 2.
  2. Se il campo Origine errore ha il valore target, significa che la dimensione del payload di risposta inviata dall'applicazione di destinazione/backend ad Apigee è maggiore di limite consentito in Apigee Edge.
  3. Verifica la Dimensione payload di risposta come determinata nel passaggio 1.
    • Se la dimensione del payload > Il limite consentito di 10 MB è la causa dell'errore.
    • Se la dimensione del payload è pari al limite consentito di ~ 10 MB, è possibile che il payload di risposta sia passati in formato compresso. In questo caso, controlla la dimensione non compressa del file payload della risposta.
  4. Puoi verificare se la risposta dal target/backend è stata inviata in formato compresso le dimensioni non compresse erano superiori al limite consentito utilizzando uno dei seguenti valori: metodo:

    Trace

    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 i Intestazione Content-Encoding: gzip
    2. Se il valore di target.received.content.length è intorno ai 10 MB consentiti e l'intestazione della risposta Content-Encoding: gzip , la causa di questo errore.

    Richiesta effettiva

    Con la richiesta effettiva:

    1. Se non hai accesso alla richiesta effettiva fatta al server di destinazione/backend, quindi 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 alla Intestazione Content-Encoding inviata nella risposta.
      2. Se noti che l'intestazione della risposta Content-Encoding è impostata su gzip e la dimensione non compressa del payload è superiore a limite consentito in Apigee Edge, 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, l'intestazione Content-Encoding: gzip viene inviata e la dimensione del file testzippedfile.gz nella risposta è minore di limite, tuttavia la dimensione del file non compresso testzippedfile era 15 MB circa

    di Gemini Advanced.

    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. Controllare i log del processore di messaggi

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

    3. Cerca per vedere se si sono verificati 502 errori durante un intervallo di tempo specifico (se il problema si è verificato in passato) o se ci sono ancora richieste che non vanno a buon fine 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 determina la il numero totale di byte letti è > 10 MB, si ferma e stampa la seguente riga:

      Message is too large. TotalRead 10489856 chunkCount 2571

      Ciò implica che la Dimensione payload di risposta è superiore a 10 MB e Apigee genera l'errore quando le dimensioni iniziano a superare il limite di 10 MB con codice di errore protocol.http.TooBigBody

Risoluzione

Correggi dimensioni

Opzione 1 [consigliata]: correggi l'applicazione server di destinazione per non inviare payload di dimensioni che superano il limite di Apigee

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

Pattern URL firmato

Opzione 2 [consigliata]: utilizza un pattern URL firmato in un callout Java Apigee

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

Streaming

Opzione 3: utilizza lo streaming

Se il proxy API deve gestire richieste e/o risposte molto grandi, puoi abilitare lo streaming in Apigee.

CwC

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

Questa opzione deve essere utilizzata solo se non puoi usare nessuna delle opzioni consigliate come potrebbero verificarsi problemi di prestazioni se la dimensione predefinita viene aumentata.

Apigee offre CwC, che consente di aumentare le dimensioni del payload di richieste e risposte limite. Per maggiori dettagli, consulta Imposta 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 payload di dimensioni superiori a il 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 richieste e risposte la dimensione del payload è quella documentata per Request/response size in Limiti periferici di Apigee.
  2. Se sei un utente Private Cloud , potresti aver modificato il valore massimo predefinito limite per le dimensioni del payload di richiesta e risposta (anche se non è una pratica consigliata). Per determinare la dimensione massima del payload di richiesta, segui le istruzioni riportate in Come controllare il limite attuale.

Come si controlla il limite attuale?

Questa sezione spiega come verificare che la proprietà HTTPResponse.body.buffer.limit è stato aggiornato con un nuovo valore nel messaggio Processori.

  1. Cerca la proprietà sul computer 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 dal comando precedente è il seguente:

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

  3. Nell'output di esempio precedente, nota che la proprietà HTTPResponse.body.buffer.limit è stato impostato con il valore 10m in http.properties.

    Ciò indica che il limite per la dimensione del payload della richiesta configurata in Apigee per La dimensione del cloud privato è di 10 MB.

Se hai ancora bisogno di aiuto dall'assistenza Apigee, vai a Raccogliere dati diagnostici.

Raccogliere dati diagnostici

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

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

  • Nome organizzazione
  • Nome ambiente
  • Nome proxy API
  • Completa il comando curl 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 di Private Cloud, fornisci le seguenti informazioni:

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

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

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

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