500 Erro interno do servidor - Servidor de back-end

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:

  1. Faça login na interface do Apigee Edge como usuário com um para o papel apropriado.
  2. Alterne para a organização na qual você deseja investigar o problema.

  3. Navegue até o menu Analisar > Monitoramento de APIs > Investigar.
  4. Selecione o período específico em que você observou os erros.
  5. Compare Código de falha com Time.

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

    ( ver imagem maior)

  7. Informações sobre o código de falha messaging.adaptors.http.flow.ErrorResponseCode aparece como mostrados abaixo:

    ( ver imagem maior)

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

    ( ver imagem maior)

  9. 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:

  1. 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
  2. Verifique se Mostrar todos os FlowInfos está ativado:

  3. Selecione uma das solicitações com falha e examine o trace.
  4. Navegar pelas diferentes fases do trace e localizar onde a falha ocorreu.
  5. Você encontrará o erro normalmente em um fluxo após a Resposta recebida do servidor de destino. fase, conforme mostrado abaixo:

    ( ver imagem maior)

  6. Navegue até a fase AX (dados do Analytics registrados) no trace e clique nela.
  7. 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:

    ( ver imagem maior)

  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 no 3: como 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 500 Internal Server Error do HTTP.
  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 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 com 500.
  4. Se você encontrar erros 500 com a correspondência X-Apigee-fault-code o valor de messaging.adaptors.http.flow.ErrorResponseCode, então determinar o valor de X-Apigee-fault-source.

    Exemplo de erro 500 do registro de acesso do NGINX:

    ( ver imagem maior)

    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.

  1. 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.
  2. Se a Origem da falha for target e o Código da falha for messaging.adaptors.http.flow.ErrorResponseCode, isso indica que o erro é 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 no solicitação de API com falha, conforme mostrado na figura abaixo:

      ( ver imagem maior)

    3. 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:

    1. 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.
    2. 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.
    3. 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.

    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 determinar 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. sua causa.
    2. Se possível, ative o modo de depuração no servidor de back-end para conferir mais detalhes sobre o erro e a causa.
  4. 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:

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

    2. A janela Curl for Request Sent to Target Server será aberta, e nela você o alias de host do servidor de destino.
    3. 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.
    4. 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.
    5. 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

  1. 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.
  2. 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.
  3. 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 erro 500.
  • 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 erros 500 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.