500 Internal Server Error

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

Vídeos

Assista aos vídeos a seguir para saber mais sobre como resolver 500 erros internos do servidor.

Video Descrição
Introdução Apresenta uma introdução a 500 erros internos do servidor e possíveis causas. Também demonstra um erro 500 do servidor interno em tempo real com as etapas para solucionar o erro.
Como lidar com erros de frase de destaque de serviço e extração de variável Demonstra dois 500 erros internos do servidor causados pelas políticas "Frase de destaque de serviço" e "Extrair variável" e como solucionar esses erros.
Solucionar erros de política do JavaScript Mostra um Erro interno do servidor 500 causado por uma política de JavaScript e as etapas para solucionar esse erro.
Solucionar falhas de servidores de back-end Mostra o exemplo 500 erros internos do servidor causados por uma falha no servidor de back-end e mostra as etapas para resolver os erros.

Sintoma

O aplicativo cliente recebe um código de status HTTP 500 com a mensagem "Internal Server Error" como uma resposta para chamadas de API. O erro "500 Servidor interno" pode ser causado por um erro durante a execução de qualquer política no Edge ou por um erro no servidor de destino/back-end.

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

Você pode receber a seguinte mensagem de erro:

HTTP/1.1 500 Internal Server Error

Em alguns casos, talvez você veja outra mensagem de erro com mais detalhes. Veja um exemplo de mensagem de erro:

{
   "fault":{
      "detail":{
         "errorcode":"steps.servicecallout.ExecutionFailed"
      },
      "faultstring":"Execution of ServiceCallout callWCSAuthServiceCallout failed. Reason: ResponseCode 400 is treated as error"
   }
}

Causas possíveis

O erro 500 interno do servidor pode ser gerado por várias causas diferentes. No Edge, as causas podem ser classificadas em duas categorias principais com base no local onde o erro ocorreu:

Causa Detalhes Etapas detalhadas da solução de problemas são fornecidas
Erro de execução em uma política de borda Uma Policy no proxy da API pode falhar por algum motivo. Usuários de nuvem privada e pública do Edge
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

Erro de execução em uma política de borda

Uma Policy no proxy da API pode falhar por algum motivo. Nesta seção, explicamos como solucionar o problema se o erro 500 interno do servidor ocorrer durante a execução de uma política.

Diagnóstico

Etapas de diagnóstico para usuários de nuvem privada e pública

Se você tiver a sessão de interface de rastreamento do erro, faça o seguinte:

  1. Verifique se o erro foi causado pela execução de uma política. Consulte Como determinar a origem do problema para ver mais detalhes.
  2. Se o erro ocorreu durante a execução da política, continue. Se o erro foi causado pelo servidor de back-end, acesse Erro no servidor de back-end.
  3. Selecione a solicitação de API que está falhando com 500 Erro interno do servidor no trace.
  4. Examine a solicitação e selecione a política específica que falhou ou o fluxo chamado "Error" (Erro) que segue imediatamente a política com falha no rastreamento.
  5. Para saber mais detalhes, verifique o campo "erro" na seção "Propriedades" ou o conteúdo do erro.
  6. Usando os detalhes que você coletou sobre o erro, tente determinar a causa dele.

Etapas de diagnóstico somente para usuários da nuvem privada

Se você não tiver a sessão de interface de rastreamento:

  1. Verifique se o erro ocorreu durante a execução de uma política. Consulte Como determinar a origem do problema para ver mais detalhes.
  2. Se o erro foi causado pela execução da política, continue. Se o erro ocorreu durante a execução da política, continue. Se o erro foi causado pelo servidor de back-end, acesse Erro no servidor de back-end.
  3. Usar os registros de acesso do NGINX, conforme explicado em Como determinar a origem do problema, para determinar a política com falha no proxy de API e também o ID exclusivo da mensagem de solicitação
  4. Verifique os registros do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log) e procure o ID exclusivo da mensagem de solicitação.
  5. Se você encontrar o ID exclusivo da mensagem de solicitação, tente conseguir mais informações sobre a causa da falha.

Resolução

Se você determinou a causa do problema com a política, corrija a política e reimplante o proxy para corrigir o problema.

Os exemplos a seguir ilustram como determinar a causa e a resolução de diferentes tipos de problemas.

Se você precisar de mais assistência para solucionar o erro 500 Internal Server Error ou suspeitar que é um problema no Edge, entre em contato com o suporte da Apigee.

Exemplo 1: falha na política de chamada de serviço devido a um erro no servidor de back-end

Se a chamada para o servidor de back-end falhar dentro da política de chamada de serviço com qualquer erro como 4XX ou 5XX, ela será tratada como 500 Erro interno do servidor.

  1. Confira um exemplo em que o serviço de back-end falha com um erro 404 na política de chamada de serviço. A seguinte mensagem de erro é enviada ao usuário final: 
    {
"fault":
     { "detail":
           { "errorcode":"steps.servicecallout.ExecutionFailed"
           },"faultstring":"Execution of ServiceCallout service_callout_v3_store_by_lat_lon
 failed. Reason: ResponseCode 404 is treated as error"
          }
     }
}
  2. A seguinte sessão da interface de trace mostra o código de status 500 causado devido a um erro na política de chamada de serviço:

  3. Neste exemplo, a propriedade "error" lista o motivo da falha na política da frase de destaque de serviço como "ResponseCode 404 istreatment as error". Esse erro pode ocorrer se o recurso acessado pelo URL do servidor de back-end na política de chamada de serviço não estiver disponível.
  4. Verifique a disponibilidade do recurso no servidor de back-end. Talvez ele não esteja disponível de forma temporária/permanente ou tenha sido movido para um local diferente.

Exemplo 1 de resolução

  1. Verifique a disponibilidade do recurso no servidor de back-end. Talvez ele não esteja disponível de forma temporária/permanente ou tenha sido movido para um local diferente.
  2. Corrija o URL do servidor de back-end na política de frase de destaque de serviço para apontar para um recurso válido e atual.
  3. Se o recurso estiver indisponível apenas temporariamente, tente fazer a solicitação de API quando ele estiver disponível.

Exemplo 2: falha na política de extração de variáveis

Agora, vamos analisar outro exemplo, em que 500 Erro interno do servidor é causado devido a um erro na política de extração de variáveis e ver como solucionar o problema.

  1. O trace a seguir na sessão da interface mostra o código de status 500 devido a um erro na política de extração de variáveis:

  2. Selecione a política com falha para extrair variáveis, role para baixo e confira a seção Conteúdo do erro para saber mais:

  3. O conteúdo do erro indica que a variável "service callout.oamCookieValidationResponse" não está disponível na política de extração de variáveis. Como o nome da variável indica, ela precisa conter a resposta da política de chamadas de serviço anterior.
  4. Selecione a política de frase de destaque de serviço no trace. Talvez você descubra que a variável "serviceCallout.oamCookieValidationResponse" não foi definida. Isso indica que a chamada para o serviço de back-end falhou, resultando em uma variável de resposta vazia.
  5. Embora a política da frase de destaque de serviço tenha falhado, a execução das políticas depois da política de chamada de serviço continua porque a sinalização "continueOnError" nela está definida como verdadeira, conforme mostrado abaixo:

    <ServiceCallout async="false" continueOnError="true" enabled="true" name="Callout.OamCookieValidation">
  <DisplayName>Callout.OamCookieValidation</DisplayName>
  <Properties />
  <Request clearPayload="true" variable="serviceCallout.oamCookieValidationRequest">
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  </Request>
  <Response>serviceCallout.oamCookieValidationResponse</Response>
  <HTTPTargetConnection>
    <Properties />
    <URL>http://{Url}</URL>
  </HTTPTargetConnection>
</ServiceCallout>
  6. Anote o ID de mensagem exclusivo "X-Apigee.Message-ID" para essa solicitação de API específica do trace, da seguinte maneira:
    1. Selecione a fase "Dados do Analytics registrados" na solicitação.
    2. Role para baixo e anote o valor de X-Apigee.Message-ID.

  7. Visualize o registro do processador de mensagens (/opt/apigee/var/log/edge-message-processor/system.log) e procure o ID da mensagem exclusivo anotado na etapa 6. A seguinte mensagem de erro foi observada para a solicitação de API específica: 
    2017-05-05 07:48:18,653 org:myorg env:prod api:myapi rev:834 messageid:rrt-04984fed9e5ad3551-c-wo-32168-77563  NIOThread@5 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@149081 useCount=1 bytesRead=0 bytesWritten=0 age=3002ms lastIO=3002ms .onConnectTimeout connectAddress=mybackend.domain.com/XX.XX.XX.XX:443 resolvedAddress=mybackend.domain.com/XX.XX.XX.XX

    O erro acima indica que a política de chamada de serviço falhou devido a um erro de tempo limite de conexão ao se conectar ao servidor de back-end.

  8. Para determinar a causa do erro de tempo limite de conexão, execute o comando telnet para o servidor de back-end a partir do(s) processador(es) de mensagens. O comando telnet apresentou o erro "O tempo limite de conexão foi atingido", conforme mostrado abaixo: 
    telnet mybackend.domain.com 443
Trying XX.XX.XX.XX...
telnet: connect to address XX.XX.XX.XX: Connection timed out

    Normalmente, esse erro é observado nas seguintes circunstâncias:

    • Quando o servidor de back-end não está configurado para permitir o tráfego dos processadores de mensagens de borda.
    • Se o servidor de back-end não estiver detectando na porta específica.

    No exemplo ilustrado acima, embora a política "Extract Variables" tenha falhado, a causa real foi que o Edge não conseguiu se conectar ao servidor de back-end na política de chamada de serviço. Essa falha foi causada porque o servidor final de back-end não foi configurado para permitir o tráfego dos processadores de mensagens de borda.

    Sua própria política de extração de variáveis vai se comportar de maneira diferente e pode falhar por um motivo diferente. Você pode solucionar o problema adequadamente, dependendo da causa da falha da política de extração de variáveis, verificando a mensagem na propriedade error.

Exemplo 2 de resolução

  1. Corrija a causa do erro ou da falha na política "Extrair variáveis" corretamente.
  2. No exemplo ilustrado acima, a solução foi corrigir a configuração de rede para permitir o tráfego dos processadores de mensagens de borda para seu servidor de back-end. Isso era feito colocando os endereços IP dos processadores de mensagens na lista de permissões no servidor de back-end específico. Por exemplo, no Linux, você pode usar iptables para permitir o tráfego dos endereços IP do processador de mensagens no servidor de back-end.

Exemplo 3: falha na política Java callout

Agora, vamos analisar mais um exemplo, em que 500 Erro interno do servidor é causado devido a um erro na política de chamadas do Java e como solucionar o problema.

  1. O trace de interface a seguir mostra o código de status 500 devido a um erro na política de chamadas do Java:

  2. Selecione o fluxo chamado "Error" seguido pela política de frases de destaque Java com falha para ver os detalhes do erro, conforme mostrado na figura abaixo:

  3. Neste exemplo, a propriedade "error" na seção "Properties" mostra que a falha se deve à senha expirada que está sendo usada ao se conectar ao Oracle Database usando a política Java callout. Sua própria frase de destaque em Java vai se comportar de maneira diferente e preencher uma mensagem diferente na propriedade error.
  4. Verifique o código da política Java callout e confirme a configuração correta que precisa ser usada.

Exemplo 3 de resolução

Corrija o código ou a configuração de frase de destaque Java adequadamente para evitar a exceção de tempo de execução. No exemplo ilustrado de falha de chamada de Java acima, é preciso usar a senha correta para se conectar ao banco de dados Oracle e resolver o problema.

Erro no servidor de back-end

Um erro 500 interno do servidor também pode se originar no servidor de back-end. Nesta seção, explicamos como solucionar o problema se o erro vier do servidor de back-end.

Diagnóstico

Etapas de diagnóstico para todos os usuários

A causa de outros erros de back-end pode variar muito. Você precisará diagnosticar cada situação de forma independente.

  1. Verifique se o erro foi causado pelo servidor de back-end. Consulte Como determinar a origem do problema para ver mais detalhes.
  2. Se o erro foi causado pelo servidor de back-end, continue. Se o erro tiver ocorrido durante a execução da política, acesse Erro de execução na política do Edge.
  3. Siga as etapas abaixo dependendo se você tem ou não acesso a uma sessão do Trace para a API com falha ou se o back-end é um servidor Node.js:

Se você não tiver uma sessão do Trace para a chamada de API com falha:

  1. Se o trace de interface não estiver disponível para a solicitação com falha, verifique os registros do servidor de back-end para mais detalhes sobre o erro.
  2. Se possível, ative o modo de depuração no servidor de back-end para saber mais sobre o erro e a causa dele.

Se você tiver uma sessão do Trace para a chamada de API com falha:

Se você tem uma sessão do Trace, as etapas a seguir ajudarão a diagnosticar o problema.

  1. Na ferramenta Trace, selecione a solicitação de API que falhou com "500 Erro interno do servidor".
  2. Selecione a fase "Resposta recebida do servidor de destino" na solicitação de API com falha, conforme mostrado na figura abaixo:

  3. Verifique a seção Conteúdo da resposta para saber mais detalhes sobre o erro.

  4. Neste exemplo, o conteúdo de resposta, que é um envelope de SSO, mostra a string com falha como uma mensagem "Não autorizado". A causa mais provável desse problema é que as credenciais adequadas (nome de usuário/senha, token de acesso etc.) não são transmitidas para o servidor de back-end pelo usuário. Para corrigir esse problema, passe as credenciais corretas para o servidor de back-end.

Se o back-end for um servidor Node.js:

  1. Se o back-end for um servidor de back-end Node.js, verifique os registros do Node.js para o proxy de API específico na interface do usuário do Edge. Os usuários de nuvem pública e privada podem verificar os registros do Node.js. Se você for um usuário da nuvem privada do Edge, também poderá verificar os registros do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log) para mais detalhes sobre o erro.

    Opção "Registros do NodeJS" na interface do Edge: guia "Visão geral" do proxy de API

Resolução

  1. Depois de identificar a causa do erro, corrija-o no servidor de back-end.
  2. Se for um servidor de back-end do Node.js:
    1. Verifique se o erro é gerado no código personalizado e corrija o problema, se possível.
    2. Se o erro não for gerado pelo código personalizado ou se você precisar de ajuda, entre em contato com o suporte da Apigee.

Se você precisar de mais assistência para solucionar o erro 500 Internal Server Error ou suspeitar que é um problema no Edge, entre em contato com o suporte da Apigee.

Como determinar a origem do problema

Use um dos procedimentos a seguir para determinar se o erro 500 interno do servidor foi gerado durante a execução de uma política no proxy da API ou no servidor de back-end.

Como usar o Trace na IU

Observação: as etapas nesta seção podem ser realizadas por usuários de nuvens públicas e privadas.

  1. Se o problema continuar ativo, ative o rastreamento na interface da API afetada.
  2. Depois de capturar o rastro, selecione a solicitação de API que mostra o código de resposta como 500.
  3. Navegue por todas as fases da solicitação de API com falha e verifique qual fase retorna o erro 500 interno do servidor:
    1. Se o erro for gerado durante a execução de uma política, acesse Erro de execução em uma política de borda.
    2. Se o servidor de back-end tiver respondido "500 Servidor interno", prossiga para Erro no servidor de back-end.

Como usar o monitoramento de APIs

Observação:as etapas desta seção só podem ser realizadas por usuários da nuvem pública.

O Monitoramento de APIs permite isolar áreas problemáticas para diagnosticar erros, desempenho e latência rapidamente, além da origem, como apps de desenvolvedores, proxies de API, destinos de back-end ou a plataforma da API.

Consulte um exemplo de cenário que demonstra como resolver problemas de 5xx com suas APIs usando o monitoramento de APIs. Por exemplo, você pode configurar um alerta para receber uma notificação quando o número de 500 códigos de status ou de falhas steps.servicecallout.ExecutionFailed exceder um determinado limite.

Como usar os registros de acesso do NGINX

Observação: as etapas nesta seção são apenas para usuários da nuvem privada do Edge.

Também é possível consultar os registros de acesso do NGINX para determinar se o código de status 500 foi gerado durante a execução de uma política no proxy de API ou no servidor de back-end. Isso será particularmente útil se o problema tiver ocorrido no passado ou se o problema for intermitente e você não conseguir capturar o rastro na interface. Use as etapas a seguir para determinar essas informações dos registros de acesso do NGINX:

  1. Verifique os registros de acesso do NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log).
  2. Pesquise se há erros 500 para o proxy de API específico com a duração determinada.
  3. Se houver erros 500, verifique se é um erro de política ou de servidor de destino, conforme mostrado abaixo:

    Exemplo de entrada que mostra um erro de política

    Exemplo de entrada mostrando um erro do servidor de destino

  4. Depois de identificar se é um erro de servidor de destino ou política, faça o seguinte:
    1. Prossiga para Erro de execução em uma política de borda se for um erro de política.
    2. Prossiga para Erro no servidor de back-end se for um erro de servidor de destino.