502 Gateway inválido - TooBigBody

Você está lendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. info

Sintoma

O aplicativo cliente recebe um código de status HTTP 502 Bad Gateway com o 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ê pode receber a seguinte mensagem de erro: 

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

Causas possíveis

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

Confira 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 é maior que o limite permitido na Apigee. Usuários da nuvem pública e privada do Edge
O tamanho do payload da resposta excede o limite permitido após a descompactação O tamanho do payload enviado em formato compactado pelo servidor de destino/back-end como parte da resposta HTTP para a Apigee é maior que o limite permitido quando descompactado pela Apigee. Usuários da nuvem pública e privada do Edge

Etapas comuns do diagnóstico

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

Monitoramento de APIs

Para diagnosticar o erro usando o API Monitoring:

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

  2. Mude para a organização em que você quer investigar o problema.

  3. Acesse a página 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. Crie um gráfico com Código de falha e Tempo.

  7. Selecione uma célula com o código de falha protocol.http.TooBigBody, conforme mostrado abaixo:

  8. As informações sobre o código de falha protocol.http.TooBigBody vão aparecer, 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 de 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 a resposta HTTP do servidor de destino/ back-end tem um tamanho de payload maior que o limite permitido no Apigee Edge.

Trace

Para diagnosticar o erro usando a ferramenta Trace:

  1. Ative a sessão de rastreamento e faça uma destas ações:
    • Aguarde o erro 502 Bad Gateway ocorrer ou
    • Se for possível reproduzir o problema, faça a chamada de API e reproduza o erro 502 Bad Gateway.
  2. Selecione uma das solicitações com falha e examine o rastreamento.
  3. Navegue pelas diferentes fases do rastreamento e localize onde a falha ocorreu.

  4. Navegue até a fase Erro logo após a fase Resposta recebida do servidor de destino, conforme mostrado abaixo:

    Observe os valores do erro no rastreamento:

    • 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 limite permitido.

  5. Você vai encontrar a falha na fase Resposta enviada ao cliente, conforme mostrado abaixo:

  6. Anote os valores do erro no rastreamento. O trace de exemplo 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 para diferentes cenários:

    Não compactado

    Cenário 1: payload de resposta enviado sem compactação

    Observe os valores do erro no rastreamento:

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

    Compactado

    Cenário 2: payload da solicitação enviado de forma compactada

    Observe os valores do erro no rastreamento:

    • Resposta recebida do servidor de destino: 200 OK
    • Content-Encoding: se você encontrar esse cabeçalho na seção Cabeçalhos de resposta, anote o valor. Por exemplo, neste caso, 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 (dados do Analytics registrados) no rastreamento e clique nela para ver os detalhes relacionados.

  10. Role a tela para baixo em Detalhes da fase até a seção Variáveis lidas e determine os valores de target.received.content.length, que indicam:
    • O tamanho real do payload da resposta quando ele é enviado em formato não compactado e
    • O tamanho do payload de resposta após a descompactação pela Apigee, quando o payload é enviado em formato compactado. Ele sempre será o mesmo que o valor do limite permitido (10 MB) neste cenário.

    Não compactado

    Cenário 1: payload de resposta enviado sem compactação

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

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

    Compactado

    Cenário 2: payload da solicitação enviado de forma compactada

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

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

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

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

    O limite de tamanho foi excedido após a descompactação

NGINX

Para diagnosticar o erro usando registros de acesso do NGINX:

  1. Se você for um usuário do Cloud privado, use 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

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

  3. Pesquise para ver se há erros de 502 durante um período específico (se o problema ocorreu no passado) ou se ainda há solicitações com falha em 502.
  4. Se você encontrar erros de 502 com o X-Apigee-fault-code correspondente ao valor de protocol.http.TooBigBody, determine o valor de X-Apigee-fault-source.

    Exemplo de erro 502 do registro de acesso do NGINX:

    A entrada de exemplo acima do registro de acesso do NGINX tem os seguintes valores para X-Apigee- fault-code 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 de falha, a origem da falha e o tamanho do payload da resposta para o erro observado usando o API Monitoring, a ferramenta Trace ou os registros de acesso do NGINX, conforme explicado em Etapas comuns de diagnóstico com o cenário 1.
  2. Se a origem da falha tiver o valor target, isso indica que o tamanho do payload da resposta enviado pelo servidor de destino/back-end para a Apigee é maior que o limite permitido no Apigee Edge.
  3. Verifique o Tamanho do payload da resposta, conforme determinado na etapa 1.
  4. Valide se o tamanho do payload da resposta é realmente maior que o limite permitido de 10 MB verificando a resposta real seguindo estas etapas:
    1. Se você não tiver acesso à solicitação real feita ao servidor de destino/backend, acesse Resolução.
    2. Se você tiver acesso à solicitação real feita ao servidor de destino/backend, siga estas etapas:
      1. Se você for um usuário da nuvem pública/privada, faça uma solicitação diretamente ao servidor de back-end no próprio servidor ou em qualquer outra máquina em que você tenha permissão para fazer a solicitação.
      2. Se você for um usuário da nuvem privada, também poderá fazer a solicitação ao servidor de back-end de um dos processadores de mensagens.
      3. Verifique o tamanho do payload transmitido na resposta conferindo o cabeçalho Content-Length.
      4. Se você descobrir que o tamanho do payload é maior que o limite permitido no Apigee Edge, essa é 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) é a causa desse erro, já que 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 a descompactação

Se o payload da resposta for enviado em formato compactado e o cabeçalho de resposta Content-Encoding estiver definido como gzip, , a Apigee vai descompactar o payload da resposta. Durante o processo de descompactação, se a Apigee detectar que o tamanho do payload é maior que o limite permitido no Apigee Edge, ela interromperá a descompactação e responderá imediatamente com 502 Bad Gateway e o código de erro protocol.http.TooBigBody.

Diagnóstico

  1. Determine o código de falha, a origem da falha e o tamanho do payload de resposta do erro observado usando o API Monitoring, a ferramenta Trace ou os registros de acesso do NGINX, conforme explicado em Etapas comuns de diagnóstico com o cenário 2.
  2. Se a Origem da falha tiver o valor target, isso indica que o tamanho do payload de resposta enviado pelo aplicativo de destino/back-end para a Apigee é maior que o limite permitido no Apigee Edge.
  3. Verifique o Tamanho do payload da resposta, conforme determinado na etapa 1.
    • Se o tamanho do payload for maior que o limite permitido de 10 MB, essa é a causa do erro.
    • Se o tamanho do payload estiver próximo do limite permitido de 10 MB, é possível que o payload de resposta seja transmitido em formato compactado. Nesse caso, verifique o tamanho descompactado do payload de resposta compactado.
  4. Você pode validar se a resposta do destino/backend foi enviada em formato compactado e se o tamanho não compactado era maior que o limite permitido usando um dos seguintes métodos:

    Trace

    Como usar a ferramenta Trace:

    1. Se você capturou um trace para a 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 do limite permitido de 10 MB e o cabeçalho de resposta for Content-Encoding: gzip, , essa é a causa do erro.

    Solicitação real

    Usando a solicitação real:

    1. Se você não tiver acesso à solicitação real feita ao servidor de destino/backend, acesse Resolução.
    2. Se você tiver acesso à solicitação real feita ao servidor de destino/backend, siga estas etapas:
      1. Verifique o tamanho do payload transmitido na resposta junto com o cabeçalho Content-Encoding enviado na resposta.
      2. Se você descobrir que o cabeçalho de resposta Content-Encoding está definido como gzip e o tamanho não compactado do payload é maior que o limite permitido no Apigee Edge, essa é a causa do 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. No entanto, o tamanho do arquivo descompactado testzippedfile era de aproximadamente 15 MB.

    Registros do processador de mensagens

    Como usar 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 de HTTP 502.

    2. Verificar os registros do processador de mensagens

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

    3. Pesquise para ver se há erros de 502 durante um período específico (se o problema aconteceu no passado) ou se ainda há solicitações com falha em 502. Você pode usar as seguintes strings de pesquisa:

      grep -ri "chunkCount"

      grep -ri "BadGateway: Body buffer overflow"
    4. Você vai 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 determina que o total de bytes lidos é > 10 MB, ele para e imprime a seguinte linha:

      Message is too large. TotalRead 10489856 chunkCount 2571

      Isso significa que o tamanho do payload da resposta é maior que 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 protocol.http.TooBigBody

Resolução

Tamanho fixo

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

  1. Analise o motivo de o servidor de destino específico enviar um tamanho de resposta / payload maior do que o limite permitido, conforme definido em Limites.
  2. Se não for desejável, modifique o aplicativo do servidor de destino para que ele envie tamanho da resposta / payload menor que o limite permitido.
  3. Se for desejável e você quiser enviar uma resposta/carga útil maior que o limite permitido, acesse as próximas opções.

Padrão do URL assinado

Opção 2 [recomendada]: use o padrão de URLs assinados em um JavaCallout da Apigee

Para payloads maiores que 10 MB, a Apigee recomenda o uso de um padrão de URLs assinados em um Apigee JavaCallout, ilustrado pelo exemplo Edge Callout: Signed URL Generator no GitHub.

Streaming

Opção 3: usar streaming

Se o proxy de API precisar processar solicitações e/ou respostas muito grandes, você poderá ativar o streaming na Apigee.

CwC

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

Essa opção só deve ser usada quando não for possível usar nenhuma das opções recomendadas, já que pode haver problemas de desempenho se o tamanho padrão for aumentado.

O Apigee fornece uma propriedade CwC que permite aumentar o limite de tamanho do payload de solicitação e resposta. Para mais detalhes, consulte Definir o limite de tamanho da mensagem no roteador ou no 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 para o tamanho do payload de solicitação e resposta será o documentado para Request/response size em Limites do Apigee Edge.
  2. Se você for um usuário da nuvem privada , talvez tenha modificado o limite máximo padrão para o tamanho do payload de solicitação e resposta, embora não seja uma prática recomendada. Para determinar o limite máximo de tamanho do payload da solicitação, siga as instruções em Como verificar o limite atual.

Como verificar o limite atual?

Nesta seção, explicamos como verificar se a propriedade HTTPResponse.body.buffer.limit foi atualizada com um novo valor nos processadores de mensagens.

  1. Na máquina do processador de mensagens, procure 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. Confira um exemplo de resultado do comando acima:

    /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 definida com o valor 10m em http.properties.

    Isso indica que o limite para o tamanho do payload da solicitação configurado no Apigee para Private Cloud é de 10 MB.

Se você ainda precisar de ajuda do suporte da Apigee, acesse Precisa de informações de diagnóstico.

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

Reúna as seguintes informações de diagnóstico 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 de 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/backend, além do tamanho do payload.

Se você for um usuário da nuvem privada, forneça as seguintes 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 para as solicitações de API com falha
  • Comando curl completo usado para reproduzir o erro 502
  • Saída completa da resposta do servidor de destino/backend, além do tamanho do payload.

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

    Em que: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