Você está vendo a documentação do Apigee Edge.
Acesse a
documentação da Apigee X. informações
Sintoma
O aplicativo cliente recebe um código de status HTTP de 502
com a mensagem Bad Gateway
como uma resposta para chamadas de API.
O código de status HTTP 502
significa que o cliente não está recebendo uma resposta válida dos servidores de back-end que deveriam realmente atender a solicitação.
Mensagens de erro
O aplicativo cliente recebe este código de resposta:
HTTP/1.1 502 Bad Gateway
Além disso, talvez você veja a seguinte mensagem de erro:
{ "fault": { "faultstring": "Unexpected EOF at target", "detail": { "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget" } } }
Causas possíveis
Uma das causas típicas de 502 Bad Gateway Error
é o erro Unexpected EOF
, que pode ser causado pelos seguintes motivos:
Causa | Detalhes | Etapas dadas para |
---|---|---|
Servidor de destino configurado incorretamente | O servidor de destino não está configurado corretamente para aceitar conexões TLS/SSL. | Usuários de nuvens públicas e privadas de borda |
EOFException do servidor de back-end | O servidor de back-end pode enviar o EOF abruptamente. | Apenas usuários da nuvem privada do Edge |
Tempo limite de sinal de atividade configurado incorretamente | Tempos limite de manutenção de atividade configurados incorretamente na Apigee e no servidor de back-end. | Usuários de nuvens públicas e privadas de borda |
Etapas comuns do diagnóstico
Para diagnosticar o erro, você pode usar um dos seguintes métodos:
Monitoramento de APIs
Para diagnosticar o erro usando o monitoramento de APIs:
Com a API Monitoring, é possível investigar
os erros 502
, seguindo as etapas explicadas em
Investigar problemas. Ou seja:
- Acesse o painel Investigar.
- Selecione o Código de status no menu suspenso e verifique se o período certo
foi selecionado quando os erros
502
ocorreram. - Clique na caixa na matriz quando um grande número de erros
502
for exibido. - No lado direito, clique em Ver registros para os erros
502
, que têm esta aparência: - Origem da falha é
target
- O código de falha é
messaging.adaptors.http.UnexpectedEOFAtTarget
Aqui podemos ver as seguintes informações:
Isso indica que o erro 502
é causado pelo destino devido a um EOF inesperado.
Além disso, anote o Request Message ID
do erro 502
para uma investigação mais detalhada.
Ferramenta de rastreamento
Para diagnosticar o erro usando a ferramenta Trace:
- Ative a
sessão de rastreamento e faça a chamada de API para reproduzir o problema
502 Bad Gateway
. - Selecione uma das solicitações com falha e examine o rastro.
- Navegue pelas várias fases do rastro e localize onde a falha ocorreu.
-
Você verá a falha depois que a solicitação for enviada ao servidor de destino, conforme mostrado abaixo:
-
Determine o valor de X-Apigee.fault-source e X-Apigee.fault-code na Fase AX (Dados do Analytics gravados) no trace.
Se os valores de X-Apigee.fault-source e X-Apigee.fault-code corresponderem aos valores mostrados na tabela a seguir, será possível confirmar que o erro
502
vem do servidor de destino:Cabeçalhos de resposta Valor X-Apigee.fault-source target
X-Apigee.fault-code messaging.adaptors.http.flow.UnexpectedEOFAtTarget
Além disso, anote o
X-Apigee.Message-ID
do erro502
para uma investigação mais detalhada.
Registros de acesso do NGINX
Para diagnosticar o erro usando o NGINX:
Também é possível consultar os registros de acesso do NGINX para determinar a causa do código de status 502
. Isso é particularmente útil se o problema tiver ocorrido no passado ou se ele for intermitente e você não conseguir capturar o rastro na IU. Use as etapas a seguir para
determinar essas informações dos registros de acesso do NGINX:
- Verifique os registros de acesso do NGINX.
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
- Procure erros
502
para o proxy de API específico durante um período específico (se o problema tiver acontecido anteriormente) ou por qualquer solicitação que ainda falhe com502
. - Se houver algum erro
502
, verifique se ele é causado pelo destino que envia umUnexpected EOF
. Se os valores de X-Apigee.fault-source e X- Apigee.fault-code corresponderem aos valores mostrados na tabela abaixo, o erro502
será causado pelo destino que fecha inesperadamente a conexão:Cabeçalhos de resposta Valor X-Apigee.fault-source target
X-Apigee.fault-code messaging.adaptors.http.flow.UnexpectedEOFAtTarget
Este é um exemplo de entrada que mostra o erro
502
causado pelo servidor de destino:
Além disso, anote os IDs das mensagens dos erros 502
para uma investigação mais detalhada.
Causa: servidor de destino configurado incorretamente
O servidor de destino não está configurado corretamente para aceitar conexões TLS/SSL.
Diagnóstico
- Use o Monitoramento de APIs, a ferramenta de rastreamento ou os registros de acesso do NGINX para determinar o ID da mensagem, o código da falha e a origem da falha do erro
502
. - Ativar o rastro na interface da API afetada.
- Se o trace da solicitação de API com falha mostrar o seguinte:
- O erro
502 Bad Gateway
aparece assim que a solicitação de fluxo de destino é iniciada. - O
error.class
exibemessaging.adaptors.http.UnexpectedEOF.
.Então, é muito provável que esse problema seja causado por uma configuração incorreta do servidor de destino.
- O erro
- Confira a definição do servidor de destino usando a chamada da API de gerenciamento de borda:
- Se você for um usuário de nuvem pública, use esta API:
curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
- Se você for um usuário de nuvem privada, use esta API:
curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
Exemplo de definição de
TargetServer
com falha:<TargetServer name="target1"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> </TargetServer >
- Se você for um usuário de nuvem pública, use esta API:
-
A definição de
TargetServer
ilustrada é um exemplo de uma das configurações incorretas típicas, que é explicada da seguinte maneira:Vamos supor que o servidor de destino
mocktarget.apigee.net
esteja configurado para aceitar conexões seguras (HTTPS) na porta443
. No entanto, se você observar a definição do servidor de destino, não há outros atributos/sinalizações que indicam que ele se destina a conexões seguras. Isso faz com que o Edge trate as solicitações de API que vão para o servidor de destino específico como solicitações HTTP (não seguras). Portanto, o Edge não iniciará o processo de handshake de SSL com esse servidor de destino.Como o servidor de destino está configurado para aceitar apenas solicitações HTTPS (SSL) em
443
, ele rejeitará a solicitação do Edge ou encerrará a conexão. Como resultado, você recebe um erroUnexpectedEOFAtTarget
no processador de mensagens. O processador de mensagens enviará502 Bad Gateway
como uma resposta ao cliente.
Resolução
Sempre verifique se o servidor de destino está configurado corretamente de acordo com seus requisitos.
No exemplo ilustrado acima, se você quiser fazer solicitações para um servidor de destino seguro (HTTPS/SSL), precisará incluir os atributos SSLInfo
com a sinalização enabled
definida como true
. Embora seja permitido adicionar os atributos SSLInfo
para um servidor de destino na própria definição do endpoint de destino, é recomendável adicionar os atributos SSLInfo
como parte da definição do servidor de destino para evitar qualquer confusão.
- Se o serviço de back-end exigir comunicação SSL unidirecional, faça o seguinte:
- Para ativar o TLS/SSL na definição de
TargetServer
, inclua os atributosSSLInfo
em que a sinalizaçãoenabled
está definida como verdadeira, conforme mostrado abaixo:<TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> </TargetServer>
- Se você quiser validar o certificado do servidor de destino no Edge, também será necessário
incluir o truststore (que contém o certificado do servidor de destino), conforme mostrado abaixo:
<TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Ciphers/> <ClientAuthEnabled>false</ClientAuthEnabled> <Enabled>true</Enabled> <IgnoreValidationErrors>false</IgnoreValidationErrors> <Protocols/> <TrustStore>mocktarget-truststore</TrustStore> </SSLInfo> </TargetServer>
- Para ativar o TLS/SSL na definição de
- Se o serviço de back-end exigir comunicação SSL bidirecional, faça o seguinte:
- É preciso ter atributos
SSLInfo
com as sinalizaçõesClientAuthEnabled
,Keystore
,KeyAlias
eTruststore
definidas corretamente, conforme mostrado abaixo:<TargetServer name="mocktarget"> <IsEnabled>true</IsEnabled> <Host>www.example.com</Host> <Port>443</Port> <SSLInfo> <Ciphers/> <ClientAuthEnabled>true</ClientAuthEnabled> <Enabled>true</Enabled> <IgnoreValidationErrors>false</IgnoreValidationErrors> <KeyAlias>keystore-alias</KeyAlias> <KeyStore>keystore-name</KeyStore> <Protocols/> <TrustStore>truststore-name</TrustStore> </SSLInfo> </TargetServer >
- É preciso ter atributos
Referências
Balanceamento de carga entre servidores de back-end
Causa: EOFException do servidor de back-end
O servidor de back-end pode enviar o fim do arquivo (EOF, na sigla em inglês) de maneira abrupta.
Diagnóstico
- Use o Monitoramento de APIs, a ferramenta de rastreamento ou os registros de acesso do NGINX para determinar o ID da mensagem, o código da falha e a origem da falha do erro
502
. - Verifique os registros do processador de mensagens (
/opt/apigee/var/log/edge-message-processor/logs/system.log
) e pesquise se você temeof unexpected
para a API específica ou se tem omessageid
exclusivo para a solicitação de API, então você pode procurá-la.Exemplo de stack trace de exceção no registro do processador de mensagens
"message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {} java.io.EOFException: eof unexpected at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na] at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na] at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na] at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na] at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"
No exemplo acima, é possível ver que o erro
java.io.EOFException: eof unexpected
ocorreu enquanto o processador de mensagens está tentando ler uma resposta do servidor de back-end. Essa exceção indica que o fim do arquivo (EOF, na sigla em inglês) ou o fim do stream foi atingido inesperadamente.Ou seja, o processador de mensagens enviou a solicitação de API para o servidor de back-end e estava aguardando ou lendo a resposta. No entanto, o servidor de back-end encerrou a conexão abruptamente antes de o processador de mensagens receber a resposta ou ler a resposta completa.
- Verifique os registros do servidor de back-end e veja se há erros ou informações que possam ter levado o servidor de back-end a encerrar a conexão abruptamente. Se você encontrar erros/informações, acesse Resolução e corrija o problema corretamente no servidor de back-end.
- Se você não encontrar erros ou informações no servidor de back-end, colete a saída
tcpdump
nos processadores de mensagens:- Se o host do servidor de back-end tiver um único endereço IP, use o seguinte comando:
tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME
- Se o host do servidor de back-end tiver vários endereços IP, use o seguinte comando:
tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME
Normalmente, esse erro é causado porque o servidor de back-end responde com
[FIN,ACK]
assim que o processador de mensagens envia a solicitação ao servidor de back-end.
- Se o host do servidor de back-end tiver um único endereço IP, use o seguinte comando:
-
Considere o exemplo de
tcpdump
abaixo.Amostra de
tcpdump
feita quando502 Bad Gateway Error
(UnexpectedEOFAtTarget
) ocorreu - Na saída TCPDump, você vê a seguinte sequência de eventos:
- No pacote
985
, o processador de mensagens envia a solicitação de API para o servidor de back-end. - No pacote
986
, o servidor de back-end responde imediatamente com[FIN,ACK]
. - No pacote
987
, o processador de mensagens responde com[FIN,ACK]
ao servidor de back-end. - Por fim, as conexões serão fechadas com
[ACK]
e[RST]
dos dois lados. - Como o servidor de back-end envia
[FIN,ACK]
, você recebe a exceçãojava.io.EOFException: eof unexpected
de exceção no processador de mensagens.
- No pacote
- Isso pode acontecer se houver um problema de rede no servidor de back-end. Fale com sua equipe de operações de rede para investigar esse problema mais a fundo.
Resolução
Corrija o problema no servidor de back-end adequadamente.
Se o problema persistir e você precisar de ajuda para solucionar problemas de 502 Bad Gateway Error
ou
suspeitar que é um problema no Edge, entre em contato com o suporte do Apigee Edge.
Causa: tempo limite de sinal de atividade configurado incorretamente
Antes de diagnosticar se essa é a causa dos erros 502
, leia
os conceitos a seguir.
Conexões permanentes na Apigee
Por padrão, a Apigee (e a seguir com o padrão HTTP/1.1) usa conexões persistentes
ao se comunicar com o servidor de back-end de destino. Conexões permanentes podem aumentar o desempenho,
permitindo que uma conexão TCP e (se aplicável) TLS/SSL já estabelecida seja reutilizada, o que
reduz as sobrecargas de latência. A duração de uma conexão que precisa ser mantida é controlada por meio de um tempo limite de sinal de atividade (keepalive.timeout.millis
) da propriedade.
O servidor de back-end e o processador de mensagens da Apigee usam tempos limite de sinal de atividade para manter as conexões abertas entre si. Quando nenhum dado é recebido dentro do tempo limite do sinal de atividade, o servidor de back-end ou o processador de mensagens pode encerrar a conexão com o outro.
Por padrão, os proxies de API implantados em um processador de mensagens na Apigee têm um tempo limite de sinal de atividade definido como
60s
, a menos que sejam substituídos. Quando nenhum dado for recebido para 60s
, a Apigee vai
encerrar a conexão com o servidor de back-end. O servidor de back-end também manterá um tempo limite de sinal de atividade e, quando ele expirar, o servidor de back-end fechará a conexão com o processador de mensagens.
Implicação da configuração incorreta do tempo limite de sinal de atividade
Se a Apigee ou o servidor de back-end estiverem configurados com tempos limite incorretos de sinal de atividade, isso vai resultar em uma disputa que fará com que o servidor de back-end envie um End Of File
(FIN)
inesperado em resposta a uma solicitação de recurso.
Por exemplo, se o tempo limite de sinal de atividade for configurado no proxy da API ou no processador de mensagens com um valor maior ou igual ao tempo limite do servidor de back-end upstream, a seguinte disputa poderá ocorrer. Ou seja, se o processador de mensagens não receber nenhum dado até perto do limite do tempo limite de manutenção do servidor de back-end, uma solicitação será enviada ao servidor de back-end usando a conexão existente. Isso pode levar a 502 Bad Gateway
devido a um erro inesperado de EOF, conforme explicado abaixo:
- Digamos que o tempo limite de sinal de atividade definido no processador de mensagens e no servidor de back-end seja de 60 segundos, e nenhuma nova solicitação tenha sido enviada até 59 segundos após a solicitação anterior ter sido atendida pelo processador de mensagens específico.
- O processador de mensagens processa a solicitação que chegou ao 59o segundo usando a conexão existente (já que o tempo limite de sinal de atividade ainda não passou) e envia a solicitação ao servidor de back-end.
- No entanto, antes que a solicitação chegue ao servidor de back-end, o limite de tempo limite de sinal de atividade foi excedido no servidor de back-end.
- A solicitação do processador de mensagens para um recurso está em andamento, mas o servidor de back-end
tenta encerrar a conexão enviando um pacote
FIN
para o processador de mensagens. - Enquanto o processador de mensagens aguarda o recebimento dos dados, ele recebe o
FIN
inesperado, e a conexão é encerrada. - Isso resulta em um
Unexpected EOF
e, em seguida, um502
é retornado ao cliente pelo processador de mensagens.
Nesse caso, observamos a ocorrência do erro 502
porque o mesmo valor de tempo limite de sinal de atividade de 60 segundos foi configurado no processador de mensagens e no servidor de back-end. Da mesma forma,
esse problema também pode acontecer se um valor mais alto estiver configurado para manter o tempo limite ativo no processador de mensagens
do que no servidor de back-end.
Diagnóstico
- Se você for um usuário de nuvem pública:
- Use a ferramenta de monitoramento de API ou trace, conforme explicado em
Etapas comuns de diagnóstico, e verifique se você tem estas duas
configurações:
- Código de falha:
messaging.adaptors.http.flow.UnexpectedEOFAtTarget
- Origem da falha:
target
- Código de falha:
- Acesse Como usar o tcpdump para uma investigação mais detalhada.
- Use a ferramenta de monitoramento de API ou trace, conforme explicado em
Etapas comuns de diagnóstico, e verifique se você tem estas duas
configurações:
- Se você for um usuário da nuvem privada:
- Use a ferramenta de rastreamento ou os registros de acesso do NGINX para determinar o ID da mensagem, o código e a origem da falha do erro
502
. - Procure o ID da mensagem no registro do processador de mensagens
(/opt/apigee/var/log/edge-message-processor/logs/system.log
). - Você verá o
java.io.EOFEXception: eof unexpected
como mostrado abaixo:2020-11-22 14:42:39,917 org:myorg env:prod api:myproxy rev:1 messageid:myorg-opdk-dc1-node2-17812-56001-1 NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : ClientChannel[Connected: Remote:51.254.225.9:80 Local:10.154.0.61:35326]@12972 useCount=7 bytesRead=0 bytesWritten=159 age=7872ms lastIO=479ms isOpen=true.onExceptionRead exception: {} java.io.EOFException: eof unexpected at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:80) at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:220)
- O erro
java.io.EOFException: eof unexpected
indica que o processador de mensagens recebeu umEOF
enquanto ainda estava aguardando a leitura de uma resposta do servidor de back-end. - O atributo
useCount=7
na mensagem de erro acima indica que o processador de mensagens reutilizou essa conexão cerca de sete vezes, e o atributobytesWritten=159
indica que o payload da solicitação de159
bytes foi enviado ao servidor de back-end. No entanto, ele não recebeu nenhum bytes de volta quando ocorreu oEOF
inesperado. -
Isso mostra que o processador de mensagens reutilizou a mesma conexão várias vezes e, nessa ocasião, enviou dados, mas recebeu um
EOF
pouco depois antes de receber os dados. Isso significa que há uma alta probabilidade de que o tempo limite de sinal de atividade do servidor de back-end seja menor ou igual ao definido no proxy da API.Você pode investigar mais com a ajuda de
tcpdump
, conforme explicado abaixo.
- Use a ferramenta de rastreamento ou os registros de acesso do NGINX para determinar o ID da mensagem, o código e a origem da falha do erro
Como usar o tcpdump
- Capture um
tcpdump
no servidor de back-end com o seguinte comando:tcpdump -i any -s 0 host MP_IP_Address -w File_Name
- Analise as
tcpdump
capturadas:Veja um exemplo de saída do tcpdump:
No exemplo de
tcpdump
acima, você pode conferir o seguinte:- No pacote
5992,
, o servidor de back-end recebeu uma solicitaçãoGET
. - No pacote
6064
, ele responde com200 OK.
. - No pacote
6084
, o servidor de back-end recebeu outra solicitaçãoGET
. - No pacote
6154
, ele responde com200 OK
. - No pacote
6228
, o servidor de back-end recebeu uma terceira solicitaçãoGET
. - Desta vez, o servidor de back-end retorna um
FIN, ACK
ao processador de mensagens (pacote6285
) iniciando o encerramento da conexão.
A mesma conexão foi reutilizada duas vezes neste exemplo, mas, na terceira solicitação, o servidor de back-end inicia um fechamento da conexão, enquanto o processador de mensagens aguarda os dados do servidor de back-end. Isso sugere que o tempo limite de sinal de atividade do servidor de back-end é provavelmente menor ou igual ao valor definido no proxy de API. Para validar isso, consulte Comparar o tempo limite de sinal de atividade na Apigee e no servidor de back-end.
- No pacote
Comparar o tempo limite de sinal de atividade na Apigee e no servidor de back-end
- Por padrão, a Apigee usa o valor de 60 segundos para a propriedade de tempo limite do sinal de atividade.
-
No entanto, é possível que você tenha substituído o valor padrão no proxy da API. É possível verificar isso conferindo a definição
TargetEndpoint
específica no proxy da API com falha que está gerando erros502
.Exemplo de configuração do TargetEndpoint:
<TargetEndpoint name="default"> <HTTPTargetConnection> <URL>https://mocktarget.apigee.net/json</URL> <Properties> <Property name="keepalive.timeout.millis">30000</Property> </Properties> </HTTPTargetConnection> </TargetEndpoint>
No exemplo acima, a propriedade de tempo limite de sinal de atividade é substituída por um valor de 30 segundos (
30000
milissegundos). - Em seguida, verifique a propriedade de tempo limite de sinal de atividade configurada no seu servidor de back-end. Digamos que seu servidor de back-end esteja configurado com um valor
25 seconds
. - Se você determinar que o valor da propriedade de tempo limite do sinal de atividade na Apigee é maior
que o valor da propriedade de tempo limite do sinal de atividade no servidor de back-end, como no exemplo
acima, essa será a causa dos erros
502
.
Resolução
Garanta que a propriedade de tempo limite de sinal de atividade seja sempre menor na Apigee (no componente de proxy de API e no processador de mensagens) em comparação com o servidor de back-end.
- Determine o valor definido para o tempo limite de sinal de atividade no servidor de back-end.
- Configure um valor apropriado para a propriedade de tempo limite do sinal de atividade no proxy de API ou no processador de mensagens, de modo que essa propriedade seja menor que o valor definido no servidor de back-end, usando as etapas descritas em Como configurar o tempo limite do sinal de atividade nos processadores de mensagens.
Se o problema persistir, acesse Precisa de informações de diagnóstico.
Prática recomendada
É altamente recomendável que os componentes downstream sempre tenham um limite de tempo limite de sinal de atividade menor do que o configurado nos servidores upstream para evitar esses tipos de disputas e erros de 502
. Cada salto downstream precisa ser menor que cada salto upstream. No Apigee Edge, é recomendável usar as seguintes diretrizes:
- O tempo limite de sinal de atividade do cliente deve ser menor que o tempo limite de sinal de atividade do roteador de borda.
- O tempo limite de sinal de atividade do roteador de borda deve ser menor que o tempo limite de manutenção do processador de mensagens.
- O tempo limite de sinal de atividade do processador de mensagens deve ser menor que o tempo limite de sinal de atividade do servidor de destino.
- Se você tiver qualquer outro salto na frente ou atrás da Apigee, a mesma regra deverá ser aplicada. Sempre deixe que o cliente downstream seja responsável pelo encerramento da conexão com o upstream.
É necessário coletar informações de diagnóstico
Se o problema persistir mesmo depois de seguir as instruções acima, 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 de API
- Conclua o comando
curl
para reproduzir o erro502
. - Arquivo de rastreamento contendo as solicitações com erro
502 Bad Gateway - Unexpected EOF
- Se os erros
502
não estiverem ocorrendo no momento, forneça o período com as informações de fuso horário em que os erros502
ocorreram no passado.
Se você for um usuário da nuvem privada, forneça as seguintes informações:
- Concluir a mensagem de erro observada para as solicitações com falha
- Organização, nome do ambiente e nome do proxy de API em que você está observando
erros
502
- Pacote de proxy de API
- Arquivo de rastreamento contendo as solicitações com erro
502 Bad Gateway - Unexpected EOF
- Registros de acesso do NGINX
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
- Registros do processador de mensagens
/opt/apigee/var/log/edge-message-processor/logs/system.log
- O período com as informações de fuso horário em que ocorreram os erros
502
Tcpdumps
coletado nos processadores de mensagens ou no servidor de back-end, ou ambos quando o erro ocorreu