502 Gateway inválido - TooBigBody

Esta é a documentação do Apigee Edge.
Acesse Documentação da Apigee X. informações

Sintoma

O aplicativo cliente recebe um código de status HTTP de 502 Bad Gateway com código de erro protocol.http.TooBigBody como resposta para chamadas de API.

Mensagem de erro

O aplicativo cliente recebe o seguinte código de resposta: 

HTTP/1.1 502 Bad Gateway

Além disso, você poderá encontrar a seguinte mensagem de erro: 

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

Causas possíveis

Esse erro ocorrerá se o tamanho do payload enviado pelo servidor de destino/back-end para o Apigee Edge como parte de resposta HTTP é maior que o limite permitido no Apigee Edge.

Estas são as possíveis causas do erro:

Causa Descrição Instruções de solução de problemas aplicáveis para
O tamanho do payload da resposta é maior que o limite permitido O tamanho do payload enviado pelo servidor de destino/back-end como parte da resposta HTTP para a Apigee é além do limite permitido na Apigee. Usuários de nuvem pública e privada de borda
O tamanho do payload da resposta excede o limite permitido após descompressão O tamanho do payload enviado em formato compactado pelo servidor de destino/back-end como parte do HTTP resposta à Apigee é maior que o limite permitido quando descompactada pela Apigee. Usuários de nuvem pública e privada de borda

Etapas comuns do diagnóstico

Use uma das seguintes ferramentas/técnicas para diagnosticar esse erro:

Monitoramento de APIs

Para diagnosticar o erro usando a API Monitoring:

  1. Faça login na interface do Apigee Edge como usuário com um para o papel apropriado.

  2. Alterne para a organização na qual você deseja investigar o problema.

  3. Navegue até o menu Analisar > Monitoramento de APIs > Investigar.
  4. Selecione o período específico em que você observou os erros.
  5. Selecione o filtro Proxy para restringir o código de falha.
  6. Compare Código de falha com Time.

  7. Selecione uma célula que tenha o código de falha protocol.http.TooBigBody como mostrados abaixo:

  8. As informações sobre o código de falha serão exibidas protocol.http.TooBigBody, conforme mostrado abaixo:

  9. Clique em Ver registros e expanda a linha da solicitação com falha.

  10. Na janela "Registros", observe os seguintes detalhes:
    • Código de status: 502
    • Origem da falha: target
    • Código da falha:protocol.http.TooBigBody.
  11. Se a Origem da falha tiver o valor target e o Código da falha tiver o valor protocol.http.TooBigBody, isso indica que o HTTP resposta do servidor de destino/ back-end tem um tamanho de carga útil de resposta maior que o limite permitido no Apigee Edge.

Trace

Para diagnosticar o erro usando a ferramenta Trace:

  1. Ative a sessão de trace e:
    • Aguarde a ocorrência do erro 502 Bad Gateway ou
    • Se você puder reproduzir o problema, faça a chamada de API e reproduza-o 502 Bad Gateway erro.
  2. Selecione uma das solicitações com falha e examine o trace.
  3. Navegar pelas diferentes fases do trace e localizar onde a falha ocorreu.

  4. Navegue até a fase Error logo após a ResponseReceived from target servidor, conforme mostrado abaixo:

    Observe os valores do erro no trace:

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

    Isso indica que o Apigee Edge (componente processador de mensagens) gera o erro assim que recebe a resposta do servidor de back-end porque o tamanho do payload excede o ou ao atingir um limite estabelecido.

  5. A falha será exibida na fase Response Sent to Client, conforme mostrado abaixo:

  6. Anote os valores do erro do trace. O trace de amostra acima mostra:
    • erro: 502 Bad Gateway
    • Conteúdo do erro: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}

  7. Navegue até a fase Resposta recebida do servidor de destino, conforme mostrado abaixo, em diferentes cenários:

    Não compactado

    Cenário 1: payload da resposta enviado em formulário descompactado

    Observe os valores do erro no trace:

    • Resposta recebida do servidor de destino: 200 OK
    • Content-Length (da seção Response Headers): ~11 MB

    Compactado

    Cenário 2: payload da solicitação enviado em formato compactado

    Observe os valores do erro no trace:

    • Resposta recebida do servidor de destino: 200 OK
    • Content-Encoding: se esse cabeçalho aparecer na seção Response Headers anote o valor. Por exemplo, neste exemplo, o valor é gzip:

  8. Observe o Corpo na seção Conteúdo da resposta:

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

  9. Navegue até a fase AX (Analytics Data Recorded) no trace e clique nela. para conferir os detalhes relacionados.

  10. Role para baixo em Detalhes da fase até a seção Leitura de variáveis e determine as valores de target.received.content.length, o que indica:
    • O tamanho real do payload da resposta quando ele é enviado no formato descompactado e
    • O tamanho do payload de resposta após a descompactação pela Apigee, quando o payload é enviados em formato compactado. Ele será sempre o mesmo que o valor limite de 10 MB nesse caso.
    .

    Não compactado

    Cenário 1: payload da resposta enviado em formulário descompactado

    Observe o valor de target.received.content.length:

    Cabeçalhos de solicitação Valor
    target.received.content.length Aprox. 11 MB

    Compactado

    Cenário 2: payload da solicitação enviado em formato compactado

    Observe o valor de target.received.content.length:

    Cabeçalhos de solicitação Valor
    target.received.content.length Aprox. 10 MB

  11. A tabela a seguir explica por que o erro 502 é retornado pela Apigee em os dois cenários com base no valor de target.received.content.length:

    Cenário Valor de target.received.content.length Motivo da falha
    Payload da resposta em formato descompactado Aprox. 11 MB Tamanho > o limite permitido de 10 MB
    Payload da resposta em formato compactado Aprox. 10 MB

    Limite de tamanho excedido na descompactação

NGINX

Para diagnosticar o erro usando registros de acesso do NGINX:

  1. Se você for um usuário da nuvem privada, poderá usar os registros de acesso do NGINX para determinar as principais informações sobre erros HTTP 502.

  2. Verifique os registros de acesso do NGINX:

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

    Onde:ORG, ENV e PORT# são substituídos por valores reais.

  3. Pesquise se há erros 502 durante um período específico (se (o problema já aconteceu) ou se ainda há solicitações com falha 502:
  4. Se você encontrar erros 502 com a correspondência X-Apigee-fault-code o valor de protocol.http.TooBigBody, depois determine o valor do X-Apigee-fault-source.

    Exemplo de erro 502 do registro de acesso do NGINX:

    O exemplo de entrada do registro de acesso do NGINX acima tem os seguintes valores para X-Apigee- código de falha e X-Apigee-fault-source:

    Cabeçalhos de resposta Valor
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-source target

Causa: o tamanho do payload da resposta é maior que o limite permitido

Diagnóstico

  1. Determine o Código da falha, a Fonte da falha e o Tamanho do payload da resposta para o erro observado ao usar a API Monitoring, a ferramenta Trace ou os registros de acesso do NGINX, conforme explicado em Etapas de diagnóstico comuns com o cenário 1.
  2. Se a origem da falha tiver o valor target, isso indica que a resposta o tamanho do payload enviado pelo servidor de destino/back-end para a Apigee é maior que limite permitido no Apigee Edge.
  3. Verifique o Response Payload Tamanho conforme determinado na etapa 1.
  4. Valide se o tamanho da carga útil da resposta é de fato > Limite permitido de 10 MB, basta verificar o a resposta real usando as seguintes etapas:
    1. Se você não tiver acesso à solicitação real feita ao servidor de destino/back-end, e acesse Resolução.
    2. Se você tem acesso à solicitação real feita ao servidor de destino/back-end, siga estas etapas:
      1. Se você for um usuário da nuvem pública/privada, faça uma solicitação diretamente para o servidor de back-end a partir do próprio servidor de back-end ou de qualquer outra máquina em que você têm permissão para fazer a solicitação ao servidor de back-end.
      2. Se você for um usuário da nuvem privada, também poderá fazer a solicitação para o o servidor de back-end de um dos processadores de mensagens.
      3. Para verificar o tamanho do payload transmitido na resposta, confira o Cabeçalho Content-Length.
      4. Se você achar que o tamanho da carga é maior do que limite permitido no Apigee Edge, essa será a causa do problema.

    Exemplo de resposta do servidor de back-end:

    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>

    No exemplo acima, é possível ver que Content-Length: 11534336 (which is ~11 MB), que é a causa desse erro, porque excede o limite permitido no Apigee Edge.

Resolução

Consulte Resolução.

Causa: O tamanho do payload da resposta excede o limite permitido após descompactação

Se o payload da resposta for enviado no formato compactado e o cabeçalho da resposta Content-Encoding está definido como gzip, A Apigee descompacta a resposta payload. Durante o processo de descompactação, se a Apigee achar que o tamanho do payload é maior do que o limite permitido no Apigee Edge, ele será interrompido ainda mais. descompactação e responde imediatamente com 502 Bad Gateway e o código de erro protocol.http.TooBigBody.

Diagnóstico

  1. Determine o código da falha,a origem da falha e o tamanho do payload da resposta dos o erro observado ao usar o API Monitoring, a ferramenta Trace ou os registros de acesso do NGINX, conforme explicado em Etapas de diagnóstico comuns com o cenário 2.
  2. Se a Origem da falha tiver o valor target, isso indica que o o tamanho do payload de resposta enviado pelo aplicativo de destino/back-end à Apigee é maior que limite permitido no Apigee Edge.
  3. Verifique o Response Payload Tamanho conforme determinado na etapa 1.
    • Se o tamanho do payload > O limite permitido de 10 MB é esse.
    • Se o tamanho de payload aproximadamente 10 MB for permitido, é possível que a carga de resposta seja transmitidos em formato compactado. Nesse caso, verifique o tamanho descompactado do Payload de resposta da solicitação.
  4. É possível validar se a resposta do destino/back-end foi enviada em formato compactado e o tamanho descompactado era maior que o limite permitido usando um dos itens a seguir métodos:

    Trace

    Como usar a ferramenta Trace:

    1. Se você capturou um trace da solicitação com falha, consulte as etapas detalhadas em Trace e
      1. Determine o valor de target.received.content.length
      2. Verifique se a solicitação do cliente continha o Cabeçalho Content-Encoding: gzip
    2. Se o valor de target.received.content.length estiver próximo aos 10 MB permitidos, limit e o cabeçalho de resposta Content-Encoding: gzip , a causa desse erro.

    Solicitação real

    Usando a solicitação real:

    1. Se você não tiver acesso à solicitação real feita ao servidor de destino/back-end, e acesse Resolução.
    2. Se você tem acesso à solicitação real feita ao servidor de destino/back-end, siga estas etapas:
      1. Verifique o tamanho do payload transmitido na resposta junto com os Cabeçalho Content-Encoding enviado na resposta.
      2. Se você achar que o cabeçalho de resposta Content-Encoding está definido como gzip e o tamanho descompactado do payload for maior que o limite permitido no Apigee Edge, essa é a causa da esse erro.

        Exemplo de resposta recebida do servidor de back-end:

        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>

        No caso acima, o cabeçalho Content-Encoding: gzip é enviado e o tamanho do arquivo testzippedfile.gz na resposta é menor que o limite, mas o tamanho do arquivo descompactado testzippedfile foi Aprox. 15 MB.

    .

    Registros do processador de mensagens

    Como usar os registros do processador de mensagens:

    1. Se você for um usuário da nuvem privada, poderá usar os registros do processador de mensagens para: determinar as principais informações sobre erros HTTP 502.

    2. Verificar os registros do processador de mensagens

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

    3. Pesquise se há erros 502 durante um período específico (se o problema tiver acontecido no passado) ou se houver alguma solicitação que ainda esteja falhando com 502: Você pode usar as seguintes strings de pesquisa:

      grep -ri "chunkCount"

      grep -ri "BadGateway: Body buffer overflow"
    4. Você encontrará linhas de system.log semelhantes às mostradas abaixo (TotalRead e chunkCount podem variar no seu 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 o processo de descompactação, assim que o processador de mensagens determinar o total de bytes de leitura é > 10 MB, ele para e mostra a seguinte linha:

      Message is too large. TotalRead 10489856 chunkCount 2571

      Significa que o Tamanho do payload da resposta é superior a 10 MB e a Apigee gera o erro quando o tamanho começa a exceder o limite de 10 MB com o código de falha como protocol.http.TooBigBody

Resolução

Corrigir tamanho

Opção 1 [recomendada]: corrija o aplicativo do servidor de destino para não enviar o tamanho do payload acima do limite da Apigee

  1. Analisar o motivo pelo qual o servidor de destino específico enviou a resposta / tamanho do payload acima do limite permitido, conforme definido em Limites.
  2. Se não for desejável, modifique seu aplicativo de servidor de destino para que ele envie resposta / payload menor que o limite permitido.
  3. Se for desejável e você quiser enviar uma resposta/payload maior que o permitido , vá para as próximas opções.

Padrão do URL assinado

Opção 2 [recomendada]: usar o padrão de URLs assinados em uma chamada Java da Apigee

Para payloads maiores que 10 MB, a Apigee recomenda usar um padrão de URLs assinados em uma Apigee JavaCall, ilustrada pela Exemplo de Edge Frase de destaque: Gerador de URL assinado (em inglês) no GitHub.

Streaming

Opção 3: usar streaming

Se o proxy de API precisar lidar com solicitações e/ou respostas muito grandes, será possível ativar o streaming na Apigee.

CwC

Opção 4: usar a propriedade CwC para aumentar o limite do buffer

Essa opção deve ser usada apenas quando não for possível usar nenhuma das opções recomendadas poderá haver problemas de desempenho se o tamanho padrão for aumentado.

A Apigee oferece CwC que permite aumentar o tamanho do payload de solicitação e resposta ou ao atingir um limite estabelecido. Para mais detalhes, consulte Defina o limite de tamanho de mensagens no roteador ou processador de mensagens.

Limites

A Apigee espera que o aplicativo cliente e o servidor de back-end não enviem tamanhos de payload maiores que o limite permitido conforme documentado para Request/response size em Limites do Apigee Edge.

  1. Se você for um usuário da nuvem pública, o limite máximo de solicitações e respostas tamanho do payload está conforme documentado para Request/response size em Limites do Apigee Edge.
  2. Se você for um usuário da nuvem privada , talvez tenha modificado o valor máximo padrão limite para o tamanho da carga da solicitação e da resposta (mesmo que não seja uma prática recomendada). É possível determinar o limite máximo de tamanho de payload de solicitação seguindo as instruções em Como verificar o limite atual

Como verificar o limite atual?

Nesta seção, explicamos como verificar se a propriedade O campo HTTPResponse.body.buffer.limit foi atualizado com um novo valor na mensagem Processadores.

  1. Na máquina do processador de mensagens, pesquise a propriedade HTTPResponse.body.buffer.limit no diretório /opt/apigee/edge-message- processor/conf e verifique qual valor foi definido, conforme mostrado abaixo:

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

  2. O resultado de amostra do comando acima é o seguinte:

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

  3. No exemplo de saída acima, observe que a propriedade HTTPResponse.body.buffer.limit foi definido com o valor 10m em http.properties

    Isso indica que o limite para o tamanho do payload de solicitação configurado na Apigee para nuvem privada tem 10 MB.

Se você ainda precisar de ajuda do suporte da Apigee, acesse É necessário coletar informações de diagnóstico.

É necessário coletar informações de diagnóstico

Colete as informações de diagnóstico a seguir e entre em contato com o suporte do Apigee Edge:

Se você for um usuário da nuvem pública, forneça as seguintes informações:

  • Nome da organização
  • Nome do ambiente
  • Nome do proxy da API
  • Comando curl completo usado para reproduzir o erro 502
  • Arquivo de rastreamento para as solicitações de API
  • Saída completa da resposta do servidor de destino/back-end junto com o tamanho do payload

Se você for um usuário da nuvem privada, forneça estas informações:

  • Mensagem de erro completa observada para as solicitações com falha
  • Nome da organização
  • Nome do ambiente
  • Pacote de proxy de API
  • Arquivo de rastreamento das solicitações de API com falha
  • Comando curl completo usado para reproduzir o erro 502
  • Saída completa da resposta do servidor de destino/back-end junto com o tamanho do payload

  • Registros de acesso do NGINX /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    Onde:ORG, ENV e PORT# são substituídos por valores reais.

  • Registros do sistema do processador de mensagens /opt/apigee/var/log/edge-message-processor/logs/system.log