Esta é a documentação do Apigee Edge.
Acesse
Documentação da Apigee X. informações
Vídeos
Vídeo | Descrição |
---|---|
500 Erro interno do servidor - causado pelo back-end | Demonstra um 500 Internal Server Error em tempo real causado pelo servidor de back-end, além de etapas para solucionar o erro. |
Sintoma
O aplicativo cliente recebe um código de status HTTP de 500
com a mensagem
Internal Server Error
como uma resposta para chamadas de API.
O código de status HTTP 500
é uma resposta de erro genérica. Significa que o servidor
encontrou uma condição inesperada que a impedia de atender à solicitação. Esse erro é
geralmente retornados pelo servidor quando nenhum outro código de erro é adequado.
Mensagens de erro
O aplicativo cliente recebe o seguinte código de resposta:
HTTP/1.1 500 Internal Server Error
Além disso, uma mensagem de erro semelhante a esta pode aparecer:
Amostra 1
Exemplo de resposta do servidor de back-end no 1
{"errorMessage":"Sorry either your e-mail or password didn't match.", "errorParameters":"{}", "errorCode":"500", "errorKey":"INVALID_EMAILPASSWORD"}
Amostra 2
Exemplo de resposta do servidor de back-end no 2
<Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> <Body> <Error> <code>500</code> <message xml:lang="en-US">Not Authorised(e4138fa0-ec57).</message> </Error> </Body> </Envelope>
Causas possíveis
O 500 Internal Server Error
pode ser retornado pelo servidor de back-end devido a uma
várias causas. Este manual explica como resolver problemas usando etapas comuns
independentemente da causa.
Estas são as possíveis causas desse problema:
Causa | Descrição | Instruções de solução de problemas aplicáveis para |
---|---|---|
Erro no servidor de back-end | O servidor de back-end pode falhar por algum motivo. | 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
Procedimento no 1: como usar o monitoramento de APIs
Para diagnosticar o erro usando a API Monitoring:
- Faça login na interface do Apigee Edge como usuário com um para o papel apropriado.
Alterne para a organização na qual você deseja investigar o problema.
- Navegue até o menu Analisar > Monitoramento de APIs > Investigar.
- Selecione o período específico em que você observou os erros.
Compare Código de falha com Time.
Selecione uma célula que contenha o código de falha
messaging.adaptors.http.flow.ErrorResponseCode
conforme mostrado abaixo:Informações sobre o código de falha
messaging.adaptors.http.flow.ErrorResponseCode
aparece como mostrados abaixo:Clique em Ver registros e expanda a linha da solicitação com falha.
- Na janela Registros, observe os seguintes detalhes:
- ID da mensagem da solicitação
- Código de status:
500
- Origem da falha:
target
- Código da falha:
messaging.adaptors.http.flow.ErrorResponseCode
Trace
Procedimento no 2: como usar a ferramenta Trace
Para diagnosticar o erro usando a ferramenta Trace:
- Ative a sessão de rastreamento e
- Aguarde o erro
500 Internal Server Error
com o código do erro.messaging.adaptors.http.flow.ErrorResponseCode
ocorrer ou - Se você puder reproduzir o problema, faça a chamada de API para reproduzir o problema
500 Internal Server Error
- Aguarde o erro
Verifique se Mostrar todos os FlowInfos está ativado:
- Selecione uma das solicitações com falha e examine o trace.
- Navegar pelas diferentes fases do trace e localizar onde a falha ocorreu.
Você encontrará o erro normalmente em um fluxo após a Resposta recebida do servidor de destino. fase, conforme mostrado abaixo:
- Navegue até a fase AX (dados do Analytics registrados) no trace e clique nela.
Role para baixo até a seção Cabeçalhos de resposta de detalhes da fase e determine os de X-Apigee-fault-code e X-Apigee-fault-source, e X-Apigee-Message-ID, conforme mostrado abaixo:
- Anote os valores de X-Apigee-fault-code, X-Apigee-fault-source, e X-Apigee-Message-ID:
Cabeçalhos de resposta | Valor |
---|---|
X-Apigee-fault-code | messaging.adaptors.http.flow.ErrorResponseCode |
X-Apigee-fault-source | target |
X-Apigee-Message-ID | MESSAGE_ID |
NGINX
Procedimento no 3: como usar registros de acesso do NGINX
Para diagnosticar o erro usando registros de acesso do NGINX:
- Se você for um usuário da nuvem privada, poderá usar os registros de acesso do NGINX para determinar
as principais informações sobre o
500 Internal Server Error
do HTTP. Verifique os registros de acesso do NGINX:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
- Pesquise se há algum erro
500
com o código de erro.messaging.adaptors.http.flow.ErrorResponseCode
durante um período específico (se o problema tiver acontecido anterior) ou se ainda há solicitações falhando com500
. Se você encontrar erros
500
com a correspondência X-Apigee-fault-code o valor demessaging.adaptors.http.flow.ErrorResponseCode
, então determinar o valor de X-Apigee-fault-source.Exemplo de erro 500 do registro de acesso do NGINX:
O exemplo de entrada do registro de acesso do NGINX acima tem os seguintes valores para X-Apigee-fault-code e X-Apigee-fault-code
Cabeçalhos Valor X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
X-Apigee-fault-source target
Causa: erro no servidor de back-end
Diagnóstico
O 500 Internal Server Error
respondido pelo servidor de back-end pode ser
por vários motivos. Você precisará diagnosticar cada situação de forma independente.
- determine o código e a origem da falha do erro observado usando a API Monitoring; da ferramenta Trace ou dos registros de acesso do NGINX, conforme explicado nas Etapas comuns de diagnóstico.
- Se a Origem da falha for
target
e o Código da falha formessaging.adaptors.http.flow.ErrorResponseCode
, isso indica que o erro é retornado pelo servidor de back-end. - Você pode usar uma das seguintes etapas para diagnosticar a causa do problema:
Trace
Como usar o Trace:
Se você tiver uma sessão do Trace para a falha, execute as seguintes etapas:
- No Trace, selecione a solicitação de API que falhou com
500 Internal Server Error
: Selecione a fase Resposta recebida do servidor de destino no solicitação de API com falha, conforme mostrado na figura abaixo:
Role para baixo até a seção Detalhes da fase e verifique Conteúdo de resposta,que contém a resposta do servidor de back-end.
Exemplo de conteúdo de resposta:
<Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> <Body> <Error> <code>500</code> <message xml:lang="en-US">Not Authorised(e4138fa0-ec57).</message> </Error> </Body> </Envelope>
Na resposta acima, observe que a mensagem de erro do servidor de back-end é Não autorizado. Isso indica que o usuário pode ter passado mensagens inválidas credenciais e, por isso, estão recebendo esse erro.
Servidor de back-end de chamada
Fazendo chamada direta para o servidor de back-end:
É possível fazer uma chamada direta para o servidor de back-end e:
- Confira se você está recebendo o mesmo
500 Internal Server Error
a resposta recebida quando a solicitação foi feita pelo Apigee Edge - Verificar a mensagem de erro (resposta) recebida do servidor de back-end
Siga estas etapas para fazer a chamada direta ao servidor de back-end:
- Verifique se você tem todos os cabeçalhos, parâmetros de consulta e quaisquer credenciais que precisam ser transmitidas ao servidor de back-end como parte da solicitação.
- Se o serviço de back-end for acessível publicamente, você pode usar o
curl
, Postman ou qualquer outro cliente REST e invocar a a API do servidor de back-end diretamente. Se o servidor de back-end só puder ser acessado pelos processadores de mensagens, você poderá use o comando
curl
, Postman ou qualquer outro cliente REST e invoque a do servidor de back-end da API diretamente do processador de mensagens.- Valide se o serviço de back-end está realmente retornando
500 Internal Server Error
e verifique a mensagem de erro (resposta) retornada pelo servidor de back-end e determinar a causa desse erro.
Registros do servidor de back-end
Como usar registros do servidor de back-end
- Revise os registros do servidor de back-end e tente conseguir mais detalhes sobre o erro. sua causa.
- Se possível, ative o modo de depuração no servidor de back-end para conferir mais detalhes sobre o erro e a causa.
- No Trace, selecione a solicitação de API que falhou com
Verifique se você está usando encadeamento de proxy no endpoint de destino específico do proxy de API com falha; ou seja, se o servidor de destino/ponto de extremidade de destino está invocando outro proxy Apigee Edge. Para determinar isso:
Se você tiver o trace da solicitação com falha, acesse a página Solicitação enviada para o servidor de destino e clique em Show Curl.
- A janela Curl for Request Sent to Target Server será aberta, e nela você o alias de host do servidor de destino.
- Revise o endpoint de destino do seu proxy de API e verifique se o servidor de back-end O URL ou o nome do host no servidor de destino aponta para outro proxy ou seu próprio proxy servidor de back-end.
- Se o alias de host do servidor de destino apontar para um alias de host virtual, então ele
é o encadeamento de proxy. Nesse caso, você precisa repetir todas as etapas acima para o
proxy encadeado até determinar o que realmente está causando o
500 Internal Server Error
. Nesses casos,500 Internal Server Error
pode acontecerão em outros proxies encadeados em outras etapas, o que pode ser diagnosticado e resolvidos usando as instruções fornecidas neste manual ou na seção 500 Erro interno do servidor. - Se o alias de host do servidor de destino apontar para seu servidor de back-end, vá para Resolução.
Resolução
Se for determinado que o erro 500
está vindo do servidor de back-end,
trabalhar com a equipe de servidores de back-end para corrigir o problema da maneira adequada.
No exemplo discutido acima, pode ser necessário solicitar que os usuários transmitam credenciais válidas para corrigirem esse problema.
Pontos principais a observar
- A mensagem de erro real retornada pelo servidor de back-end para
500 Internal Server Error
só poderá ser visualizada se você capturar a sessão de rastreamento da falha solicitações. - A resposta do servidor de back-end não será registrada no API Monitoring, nos registros de acesso do NGINX ou Registros do processador de mensagens por motivos de segurança.
- Você pode revisar os registros do servidor de back-end ou ativar o modo de depuração no back-end para ter mais
detalhes sobre a
500 Internal Server Error
e/ou acessar a mensagem de erro retornada pelo servidor de back-end.
É necessário coletar informações de diagnóstico
Se o problema persistir mesmo depois de seguir as instruções acima, colete as seguintes informações: 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 da API
- Conclua o comando
curl
para reproduzir o erro500
. - Arquivo de rastreamento contendo as solicitações com
500 Internal Server Error
- Se os erros
500
não estiverem ocorrendo no momento, forneça a hora período com as informações de fuso horário quando erros500
ocorreram no passado.
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
- Organização, nome do ambiente e nome do proxy de API que você está observando
500
erro - Pacote de proxy de API
- Arquivo de rastreamento contendo as solicitações com
500 Internal Server Error
- 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
- O período com as informações de fuso horário em que os erros
500
ocorreram.