Você está vendo a documentação do Apigee Edge.
Veja a documentação da
Apigee X.
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 precisam atender à solicitação.
Mensagens de erro
O aplicativo cliente recebe o seguinte código de resposta:
HTTP/1.1 502 Bad Gateway
Além disso, você poderá ver a seguinte mensagem de erro:
{ "fault": { "faultstring": "Unexpected EOF at target", "detail": { "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget" } } }
Causas possíveis
Uma das causas comuns de 502 Bad Gateway Error
é o erro Unexpected EOF
, que pode ser causado pelos seguintes motivos:
Causa | Detalhes | Etapas indicadas para |
---|---|---|
Servidor de destino configurado incorretamente | O servidor de destino não está configurado corretamente para aceitar conexões TLS/SSL. | Usuários de nuvem pública e privada do Edge |
EOFException do servidor de back-end | O servidor de back-end pode enviar EOF abruptamente. | Somente usuários da nuvem privada do Edge |
Tempo limite do sinal de atividade configurado incorretamente | Mantenha os tempos limite configurados incorretamente na Apigee e no servidor de back-end. | Usuários de nuvem pública e privada do Edge |
Etapas comuns do diagnóstico
Para diagnosticar o erro, use um dos seguintes métodos:
Monitoramento de APIs
Para diagnosticar o erro usando o API Monitoring:
Usando o Monitoramento de API, é possível investigar
os erros 502
seguindo as etapas conforme explicado em
Investigar problemas. Ou seja:
- Acesse o painel Investigar.
- Selecione o Código de status no menu suspenso e verifique se o período correto está selecionado quando os erros
502
ocorreram. - Clique na caixa na matriz quando você vir um grande número de erros
502
. - No lado direito, clique em Ver registros para ver os erros
502
que seriam semelhantes aos seguintes: - Origem da falha é
target
- 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 EOF inesperado.
Além disso, anote o Request Message ID
do erro 502
para uma investigação mais detalhada.
Ferramenta Trace
Para diagnosticar o erro usando a ferramenta Trace:
- Ative a
sessão de rastreamento e faça a chamada da API para reproduzir o problema
502 Bad Gateway
. - Selecione uma das solicitações com falha e examine o trace.
- Navegue pelas diversas fases do trace e localize onde a falha ocorreu.
-
Você verá a falha após o envio da solicitação ao servidor de destino, conforme mostrado abaixo:
-
Determine o valor de X-Apigee.fault-source e X-Apigee.fault-code na Fase AX (Analytics Data Recorded) 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
está vindo do servidor de destino:Cabeçalhos de resposta Valor X-Apigee.fault-source target
X-Apigee.Código da falha messaging.adaptors.http.flow.UnexpectedEOFAtTarget
Além disso, anote o
X-Apigee.Message-ID
do erro502
para uma investigação mais aprofundada.
Registros de acesso do NGINX
Para diagnosticar o erro usando o NGINX:
Você também pode 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 for intermitente e você não conseguir capturar o trace na IU. Use as etapas a seguir para determinar essas informações nos 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
do proxy de API específico durante um período específico (se o problema tiver ocorrido anteriormente) ou procure solicitações que ainda falham 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.Código da falha messaging.adaptors.http.flow.UnexpectedEOFAtTarget
Veja um exemplo de entrada que mostra o erro
502
causado pelo servidor de destino:
Além disso, anote os IDs de mensagem 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 API, a ferramenta Trace ou os registros de acesso do NGINX para determinar o ID da mensagem, o código e a origem da falha para o erro
502
. - Ative o rastreamento na IU da API afetada.
- Se o trace da solicitação de API com falha mostrar o seguinte:
- O erro
502 Bad Gateway
é exibido 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
- Veja a definição do servidor de destino usando a chamada da API Edge Management:
- Se você é 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ê é 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ê é um usuário de nuvem pública, use esta API:
-
A definição ilustrada de
TargetServer
é um exemplo para 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 haverá outros atributos/sinalizações que indiquem que ele se destina a conexões seguras. Isso faz com que o Edge trate as solicitações de API direcionadas 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 fechará 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
Verifique se o servidor de destino está configurado corretamente de acordo com seus requisitos.
Para o exemplo ilustrado acima, se você quiser fazer solicitações para um servidor de destino seguro (HTTPS/SSL), será necessário incluir os atributos SSLInfo
com a sinalização enabled
definida como true
. Embora seja possível adicionar os atributos SSLInfo
para um servidor de destino na definição do endpoint de destino, é recomendável adicionar os atributos SSLInfo
como parte da definição do servidor de destino para evitar confusão.
- Se o serviço de back-end exigir comunicação SSL unidirecional, faça o seguinte:
- É necessário ativar o TLS/SSL na definição de
TargetServer
incluindo os atributosSSLInfo
, em que a sinalizaçãoenabled
está definida como verdadeira, como 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 precisaremos 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>
- É necessário ativar o TLS/SSL na definição de
- Se o serviço de back-end exigir comunicação SSL bidirecional:
- Você precisa ter atributos
SSLInfo
com as sinalizaçõesClientAuthEnabled
,Keystore
,KeyAlias
eTruststore
definidas corretamente, como 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 >
- Você precisa 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 EOF (End of File) abruptamente.
Diagnóstico
- Use o Monitoramento de API, a ferramenta Trace ou os registros de acesso do NGINX para determinar o ID da mensagem, o código e a origem da falha para o 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 da API.Exemplo de rastreamento de pilha de exceção do 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, você pode 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) ou que 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 do Processador de mensagens receber a resposta ou podia 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 a encerrar a conexão abruptamente. Se você encontrar erros/informações, acesse a Resolução e corrija o problema no servidor de back-end.
- Se você não encontrar erros ou informações no seu servidor de back-end, colete a saída do
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
tcpdump
a seguir.Exemplo de
tcpdump
usado quando502 Bad Gateway Error
(UnexpectedEOFAtTarget
) ocorreu - Na saída TCPDump, você percebe 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 sã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
no processador de mensagens.
- No pacote
- Isso pode acontecer se houver um problema de rede no servidor de back-end. Envolva sua equipe de operações de rede para investigar o problema mais a fundo.
Resolução
Corrija o problema no servidor de back-end.
Se o problema persistir e você precisar de ajuda para solucionar 502 Bad Gateway Error
ou
suspeitar que é um problema no Edge, entre em contato com o suporte do Apigee Edge.
Causa: tempo limite do 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 após o padrão HTTP/1.1) usa conexões permanentes ao se comunicar com o servidor de back-end de destino. As conexões permanentes podem melhorar o desempenho, permitindo que uma conexão TCP/SSL já estabelecida e, se aplicável, seja reutilizada, o que reduz as sobrecargas de latência. O período em que uma conexão precisa ser mantida é controlado por uma propriedade keep alive timeout (keepalive.timeout.millis
).
Tanto o servidor de back-end quanto o Processador de mensagens da Apigee usam tempos limite ativos 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 podem fechar a conexão com o outro.
Os proxies de API implantados em um processador de mensagens na Apigee, por padrão, têm um tempo limite de sinal de atividade definido como 60s
, a menos que sejam modificados. Depois que nenhum dado for recebido para 60s
, a Apigee fechará 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 isso expirar, o servidor de back-end fechará a conexão com o processador de mensagens.
Implicação da configuração incorreta do tempo limite do sinal de atividade
Se a Apigee ou o servidor de back-end estiver configurado com tempos limite de sinal de atividade incorretos, isso 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 um recurso.
Por exemplo, se o tempo limite de sinal de atividade estiver configurado no proxy de API ou no processador de mensagens com um valor maior ou igual ao tempo limite do servidor de back-end upstream, a seguinte condição de corrida pode ocorrer. Ou seja, se o processador de mensagens não receber nenhum dado até que esteja muito próximo do limite do servidor de back-end, ele atingirá o tempo limite, então uma solicitação será enviada e enviada ao servidor de back-end usando a conexão atual. 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 chegado até 59 segundos depois que a solicitação anterior foi veiculada pelo processador de mensagens específico.
- O Processador de mensagens avança e processa a solicitação que chegou no 59o segundo usando a conexão existente (porque o tempo limite do sinal de atividade ainda não expirou) e envia a solicitação para o 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 de um recurso está em andamento, mas o servidor de back-end tenta fechar a conexão enviando um pacote
FIN
ao processador de mensagens. - Enquanto o processador de mensagens aguarda os dados serem recebidos, ele recebe o
FIN
inesperado, e a conexão é encerrada. - Isso resulta em um
Unexpected EOF
e, posteriormente, um502
é retornado ao cliente pelo processador de mensagens.
Nesse caso, observamos que o erro 502
ocorreu porque o mesmo valor de tempo limite do 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 o tempo limite de sinal de atividade no processador de mensagens do que no servidor de back-end.
Diagnóstico
- Se você é um usuário de nuvem pública:
- Use a ferramenta API Monitoring ou Trace (conforme explicado em Etapas de diagnóstico comuns) e verifique se você tem as duas configurações a seguir:
- 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 API Monitoring ou Trace (conforme explicado em Etapas de diagnóstico comuns) e verifique se você tem as duas configurações a seguir:
- Se você é um usuário de nuvem privada:
- Use a ferramenta Trace ou os registros de acesso NGINX para determinar o ID da mensagem, o código e a origem da falha para o erro
502
. - Pesquise 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
conforme 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 aguardava 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 processador de mensagens enviou o payload da solicitação de159
bytes para o servidor de back-end. No entanto, ele recebeu zero bytes quando oEOF
inesperado ocorreu. -
Isso mostra que o Processador de mensagens reutilizou a mesma conexão várias vezes e, nessa ocasião, enviou dados, mas logo depois recebeu um
EOF
antes de receber qualquer dado. Isso significa que há uma grande probabilidade de que o tempo limite de sinal de atividade do servidor de back-end seja menor ou igual ao definido no proxy de API.Você pode investigar mais com a ajuda de
tcpdump
, conforme explicado abaixo.
- Use a ferramenta Trace ou os registros de acesso NGINX para determinar o ID da mensagem, o código e a origem da falha para o 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 o
tcpdump
capturado:Este é um exemplo de saída do tcpdump:
Na amostra
tcpdump
acima, é possível ver 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ção deGET
. - 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
para o Processador de mensagens (pacote6285
) iniciando o fechamento da conexão.
A mesma conexão foi reutilizada com sucesso neste exemplo, mas, na terceira solicitação, o servidor de back-end inicia um encerramento da conexão, enquanto o Processador de mensagens está aguardando 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 o servidor de back-end.
- No pacote
Comparar o tempo limite do sinal de atividade na Apigee e no servidor de back-end
- Por padrão, a Apigee usa um 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 de API. Para isso, verifique a definição
TargetEndpoint
específica no proxy de API com falha que está apresentando 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 está substituída por um valor de 30 segundos (
30000
milissegundos). - Em seguida, verifique a propriedade do tempo limite do sinal de atividade configurada no servidor de back-end. Digamos que seu servidor de back-end esteja configurado com o valor
25 seconds
. - Se você determinar que o valor da propriedade de tempo limite de sinal de atividade na Apigee é maior
que o valor da propriedade de tempo limite de sinal de atividade no servidor de back-end, como no exemplo
acima, isso é a causa dos erros
502
.
Resolução
Certifique-se de que a propriedade de tempo limite de sinal de atividade esteja sempre menor na Apigee (no componente Proxy de API e Processador de mensagens) em comparação à propriedade no servidor de back-end.
- Determine o valor definido para o tempo limite do sinal de atividade no servidor de back-end.
- Configure um valor apropriado para a propriedade de tempo limite do sinal de atividade no proxy da API ou no processador de mensagens, de modo que a propriedade do tempo limite do sinal de atividade 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 coletar informações de diagnóstico.
Prática recomendada
É altamente recomendável que os componentes downstream tenham sempre um limite de tempo limite de sinal de atividade menor do que o configurado nos servidores upstream para evitar esses tipos de condições de corrida e erros 502
. Cada salto downstream deve ser menor que cada salto ascendente. 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.
- O tempo limite de sinal de atividade do roteador de borda precisa ser menor que o tempo limite de sinal de atividade do processador de mensagens.
- O tempo limite de sinal de atividade do processador de mensagens precisa ser menor que o tempo limite de sinal de atividade do servidor de destino.
- Se você tiver outros saltos na frente ou atrás da Apigee, a mesma regra deverá ser aplicada. Deixe sempre como responsabilidade do cliente downstream fechar a 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, reúna as seguintes informações de diagnóstico e entre em contato com o Suporte da Apigee Edge.
Se você é um usuário de nuvem pública, forneça as seguintes informações:
- Nome da organização
- Nome do ambiente
- Nome do proxy da 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 as informações de fuso horário ao período em que os erros502
ocorreram no passado.
Se você é um usuário de nuvem privada, forneça as seguintes informações:
- Mensagem de erro completa observada para as solicitações com falha
- Organização, nome do ambiente e nome do proxy de API para os quais 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 os
502
erros ocorreram Tcpdumps
reunidos nos processadores de mensagens ou no servidor de back-end, ou ambos, quando o erro tiver ocorrido.