500 Erro interno do servidor - Servidor de back-end

Você está vendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. informações

Vídeos

Video Descrição
500 Erro interno do servidor causado por back-end Demonstra um 500 Internal Server Error em tempo real causado pelo servidor de back-end, bem como as 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. 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 este código de resposta: 

HTTP/1.1 500 Internal Server Error

Além disso, talvez você veja uma mensagem de erro semelhante à mostrada abaixo:

Amostra 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"}

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 várias causas. Neste manual, explicamos como solucionar problemas usando etapas comuns e resolver esse erro, seja qual for a 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 de nuvem privada e pública 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 do Apigee Edge como usuário com um papel apropriado.

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

  3. Navegue até a página Analisar > Monitoramento de API > Investigar.
  4. Selecione o período específico em que você observou os erros.

  5. Trace o Código de falha em relação a Time.

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

    ( ver imagem ampliada)

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

    ( ver imagem ampliada)

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

    ( ver imagem ampliada)

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

Trace

Procedimento 2: uso da ferramenta Trace

Para diagnosticar o erro usando a ferramenta Trace:

  1. Ative a sessão de rastreamento e:
    • Aguarde a ocorrência do erro 500 Internal Server Error com o código de erro messaging.adaptors.http.flow.ErrorResponseCode ou
    • Se for possível reproduzir o problema, faça a chamada de API para reproduzi-lo 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 rastro.
  4. Navegue pelas diferentes fases do rastro e localize onde a falha ocorreu.

  5. Você encontrará o erro normalmente em um fluxo após a fase Resposta recebida do servidor de destino, conforme mostrado abaixo:

    ( ver imagem ampliada)

  6. Navegue até a fase AX (Dados do Analytics registrados) no rastreamento e clique nela.

  7. Role para baixo até a seção Stage Details Response Headers e determine os valores de X-Apigee-fault-code, X-Apigee-fault-source e X-Apigee-Message-ID, conforme mostrado abaixo:

    ( ver imagem ampliada)

  8. Observe 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 no 3: uso de registros de acesso do NGINX

Para diagnosticar o erro usando os registros de acesso do NGINX:

  1. Se você for um usuário de nuvem privada, poderá usar os registros de acesso do NGINX para determinar as principais informações sobre o 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 se há algum erro 500 com o código messaging.adaptors.http.flow.ErrorResponseCode durante um período específico (se o problema tiver acontecido anteriormente) ou se ainda há alguma solicitação 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, determine o valor de X-Apigee-fault-source.

    Exemplo de erro 500 do registro de acesso do NGINX:

    ( ver imagem ampliada)

    A entrada de amostra acima do registro de acesso do NGINX 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 causado por vários motivos. Você precisará diagnosticar cada situação de forma independente.

  1. Determine o código de falha, a origem da falha do erro observado usando o monitoramento de APIs, a ferramenta de rastreamento ou os registros de acesso do NGINX, conforme explicado em Etapas comuns de 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 foi retornado pelo servidor de back-end.
  3. 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:

    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:

      ( ver imagem ampliada)

    3. Role para baixo até a seção Stage Details e verifique Response Content,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 é Not Autorizado. Isso indica que o usuário pode ter passado credenciais inválidas, e é por isso que ele está recebendo esse erro.

    Chamar o servidor de back-end

    Fazer uma chamada direta para o servidor de back-end:

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

    • Valide se você está recebendo a mesma resposta 500 Internal Server Error que foi 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:

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

    3. Se o servidor de back-end só puder ser acessado pelos processadores de mensagens, você poderá 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 realmente está retornando 500 Internal Server Error, 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. Revise os registros do servidor de back-end e tente conseguir 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 saber mais 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 para o servidor de destino e clique em Mostrar curl.

    2. A janela Curl for Request Sent to Target Server será aberta. Nela, é possível determinar o alias do host do servidor de destino.
    3. Revise 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 seu próprio servidor de back-end.
    4. Se o alias de host do servidor de destino estiver apontando para um alias de host virtual, ele estará encadeado por proxy. Nesse caso, você precisa repetir todas as etapas acima para o proxy encadeado até determinar o que está realmente causando o 500 Internal Server Error. Nesses casos, 500 Internal Server Error pode acontecer em outros proxies encadeados em outros estágios, que podem ser diagnosticados e resolvidos usando as instruções fornecidas neste manual ou no manual 500 Erro interno do servidor.
    5. Se o alias do host do servidor de destino apontar para o servidor de back-end, acesse Resolução.

Resolução

Se for confirmado que o erro 500 está vindo do servidor de back-end, entre em contato com a equipe do servidor de back-end para corrigir o problema.

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

Pontos principais

  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 rastreamento 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 saber mais 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, 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 erro 500.
  • Arquivo de rastreamento que contém 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:

  • Concluir a mensagem de erro observada para as solicitações com falha
  • Organização, nomes do ambiente e do proxy de API em que você está observando erros 500
  • Pacote de proxy de API
  • Arquivo de rastreamento que contém 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 ocorreram os erros 500.