500 Erro interno do servidor - Servidor de back-end

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

Vídeos

Vídeo Descrição
500 Internal Server Error - caused by backend Demonstra um 500 Internal Server Error em tempo real causado pelo servidor de back-end, além das etapas para solucionar e resolver o erro.

Sintoma

O aplicativo cliente recebe um código de status HTTP de 500 com a mensagem Internal Server Error como resposta para chamadas de API.

O código de status HTTP 500 é uma resposta de erro genérica. Isso significa que o servidor encontrou uma condição inesperada que o impediu de atender à solicitação. Esse erro é geralmente é retornado 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, você pode observar uma mensagem de erro semelhante à mostrada abaixo:

Exemplo 1

Exemplo de resposta do servidor de back-end 1

{"errorMessage":"Sorry either your e-mail or password didn't match.",
"errorParameters":"{}",
"errorCode":"500",
"errorKey":"INVALID_EMAILPASSWORD"}

Exemplo 2

Exemplo de resposta do servidor de back-end 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 um número de causas. Este manual explica como solucionar problemas usando etapas comuns e resolver esse erro, independentemente da causa.

As possíveis causas desse problema são as seguintes:

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 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

Procedimento 1: usar o monitoramento de APIs

Para diagnosticar o erro usando o monitoramento de APIs:

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

  2. Alterne 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. Trace o código de falha em relação ao tempo.

  6. Selecione uma célula que tenha o código de falha messaging.adaptors.http.flow.ErrorResponseCode conforme mostrado abaixo:

    ( ampliar imagem)

  7. As informações sobre o código de falha messaging.adaptors.http.flow.ErrorResponseCode são mostradas abaixo:

    ( ampliar imagem)

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

    ( ampliar imagem)

  9. Na janela Registros, anote os seguintes detalhes:
    • ID da mensagem de solicitação
    • Código de status:500
    • Origem da falha:target
    • Código de falha:messaging.adaptors.http.flow.ErrorResponseCode

Trace

Procedimento 2: usar a ferramenta Trace

Para diagnosticar o erro usando a ferramenta Trace:

  1. Ative a sessão de trace e
    • Aguarde a ocorrência do erro 500 Internal Server Error com o código de erro messaging.adaptors.http.flow.ErrorResponseCode ou
    • Se você puder reproduzir o problema, faça a chamada de API para reproduzir o problema 500 Internal Server Error

  2. Verifique se a opção Mostrar todos os FlowInfos está ativada:

  3. Selecione uma das solicitações com falha e examine o trace.
  4. Navegue pelas diferentes fases do trace e localize onde a falha ocorreu.

  5. O erro geralmente é encontrado em um fluxo após a fase Resposta recebida do servidor de destino conforme mostrado abaixo:

    ( ampliar imagem)

  6. Navegue até a fase AX (dados de análise gravados) no trace e clique nela.

  7. Role para baixo até a seção Cabeçalhos de resposta de detalhes da fase e determine os valores de X-Apigee-fault-code e X-Apigee-fault-source, e X-Apigee-Message-ID , conforme mostrado abaixo:

    ( ampliar imagem)

  8. Anote os valores de X-Apigee-fault-code, X-Apigee-fault-source, e X-Apigee-Message-ID:
    9. 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 3: usar registros de acesso do 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 o erro HTTP 500 Internal Server Error.

  2. Verifique os registros de acesso do NGINX:

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

  3. Pesquise para ver se há erros 500 com o código de erro messaging.adaptors.http.flow.ErrorResponseCode durante um período específico (se o problema ocorreu no passado) ou se ainda há solicitações com falha com 500.

  4. Se você encontrar erros 500 com o X-Apigee-fault-code correspondente ao valor de messaging.adaptors.http.flow.ErrorResponseCode, então determine o valor de X-Apigee-fault-source.

    Exemplo de erro 500 do registro de acesso do NGINX:

    ( ampliar imagem)

    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 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 causado por vários motivos. É necessário diagnosticar cada situação de forma independente.

  1. Determine o código de falha, a origem da falha para o erro observado usando o monitoramento de APIs, a ferramenta Trace ou os registros de acesso do NGINX, conforme explicado em Etapas comuns do diagnóstico.
  2. Se a origem da falha for target e o código de falha for messaging.adaptors.http.flow.ErrorResponseCode, isso indica que o erro é retornado pelo servidor de back-end.
  3. Você pode usar uma das etapas a seguir para diagnosticar a causa do problema:

    Trace

    Como usar o Trace :

    Se você tiver uma sessão de trace para a falha, siga estas etapas:

    1. No trace, selecione a solicitação de API que falhou com 500 Internal Server Error.

    2. Selecione a fase Resposta recebida do servidor de destino na solicitação de API com falha, conforme mostrado na figura abaixo:

      ( ampliar imagem)

    3. Role para baixo até a seção Detalhes da fase e verifique o conteúdo da resposta, que contém a resposta do servidor de back-end.

      Exemplo de conteúdo da 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 transmitido credenciais inválidas e, por isso, está recebendo esse erro.

    Chamar servidor de back-end

    Como fazer uma chamada direta para o servidor de back-end :

    É possível fazer uma chamada direta para o servidor de back-end e:

    • Validar se você está recebendo a mesma 500 Internal Server Error 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 para o servidor de back-end:

    1. Verifique se você tem todos os cabeçalhos, parâmetros de consulta e quaisquer credenciais necessárias que precisam ser transmitidas ao servidor de back-end como parte da solicitação.
    2. Se o serviço de back-end for acessível publicamente, use o curl comando, o Postman ou qualquer outro cliente REST e invoque a API do servidor de back-end diretamente.

    3. Se o servidor de back-end só puder ser acessado pelos processadores de mensagens, então você pode usar o comando curl, o Postman ou qualquer outro cliente REST e invocar a API do servidor de back-end diretamente do processador de mensagens.

    4. 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 determine a causa desse erro.

    Registros do servidor de back-end

    Como usar registros do servidor de back-end

    1. Analise os registros do servidor de back-end e tente receber mais detalhes sobre o erro e a causa dele.
    2. Se possível, ative o modo de depuração no servidor de back-end para receber mais detalhes sobre o erro e a causa.

  4. Verifique se você está usando o encadeamento de proxy no endpoint de destino específico do proxy de API com falha. Ou seja, se o servidor/endpoint de destino está invocando outro proxy no Apigee Edge. Para determinar isso:

    1. Se você tiver o trace da solicitação com falha, navegue até a fase Solicitação enviada ao servidor de destino e clique em Mostrar Curl.

    2. A janela Curl para solicitação enviada ao servidor de destino é aberta. Nela, é possível determinar o alias do host do servidor de destino.
    3. Analise o endpoint de destino do proxy de API e verifique se o URL do servidor de back-end ou o nome do host no servidor de destino aponta para outro proxy ou para o seu próprio servidor de back-end.
    4. Se o alias do host do servidor de destino estiver apontando para um alias de host virtual, ele será encadeado por proxy. Nesse caso, repita 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 também pode ocorrer em outros proxies encadeados em outras etapas, que podem ser diagnosticados e resolvidos usando as instruções fornecidas neste manual ou no manual 500 Internal Server Error.
    5. Se o alias do host do servidor de destino apontar para o servidor de back-end, acesse Resolução.

Resolução

Se for constatado que o erro 500 está vindo do servidor de back-end, então trabalhe com a equipe do servidor de back-end para corrigir o problema adequadamente.

No exemplo discutido acima, talvez seja necessário solicitar que os usuários transmitam credenciais válidas para corrigir esse problema.

Pontos importantes a serem observados

  1. A mensagem de erro real retornada pelo servidor de back-end para 500 Internal Server Error só poderá ser visualizada se você tiver capturado a sessão de trace para as solicitações com falha.
  2. A resposta do servidor de back-end não será registrada no monitoramento de APIs, nos registros de acesso do NGINX ou nos registros do processador de mensagens por motivos de segurança.
  3. É possível analisar os registros do servidor de back-end ou ativar o modo de depuração no back-end para receber mais detalhes sobre o 500 Internal Server Error e/ou visualizar 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, 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 da API
  • Comando curl completo para reproduzir o erro 500
  • Arquivo de trace contendo as solicitações com 500 Internal Server Error
  • Se os erros 500 não estiverem ocorrendo no momento, forneça o período com as informações de fuso horário em que os erros 500 ocorreram no passado.

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, do ambiente e do proxy de API para o qual você está observando 500 erros
  • Pacote de proxy de API
  • Arquivo de trace 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

    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
  • O período com as informações de fuso horário em que os erros 500 ocorreram.