500 Internal Server Error

Esta é a documentação do Apigee Edge.
Acesse 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.

Vídeo Descrição
Introdução Fornece uma introdução aos 500 erros internos do servidor e às possíveis causas. Também demonstra um erro 500 Servidor Interno em tempo real junto com as etapas para solucionar o erro.
Solucionar erros de chamada de serviço e extração de variável Demonstra dois 500 erros internos do servidor causados pelas políticas de chamada de serviço e variável de extração e mostra como resolver esses erros.
Solucionar erros de política do JavaScript Mostra um erro 500 interno do servidor causado por uma política do JavaScript e as etapas para solucionar o problema e resolver esse erro.
Solucionar falhas de servidores de back-end Mostra o exemplo 500 de 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 "Erro interno do servidor" como resposta para chamadas de API. O Servidor Interno 500 erro 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. Significa que o servidor encontrou uma uma condição inesperada que a impedia de atender à solicitação. Esse erro geralmente ocorre retornados 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, você pode observar outra mensagem de erro com mais detalhes. Aqui está um exemplo 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 devido a várias causas diferentes. No Edge, as causas podem ser classificadas em duas categorias principais com base no local em que o erro ocorreu:

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

Erro de execução em uma política do Edge

Uma Policy no o proxy da API pode falhar por algum motivo. Esta seção explica como resolver o problema se o Erro 500 Interno do Servidor ocorre 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 para o 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 mais detalhes.
  2. Se o erro ocorreu durante a execução da política, continue. Se o erro tiver sido causado pelo servidor de back-end, acesse Erro no servidor de back-end.
  3. Selecione a solicitação de API que está falhando e apresentando o erro 500 Internal Server Error no trace.
  4. Examine a solicitação e selecione a política específica que falhou ou o fluxo nomeado "Erro" que está imediatamente após a política com falha no trace.
  5. Para saber mais detalhes sobre o erro, verifique o "erro" em Propriedades ou o conteúdo de Erro.
  6. Use os detalhes que você coletou sobre o erro para tentar determinar a causa.

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

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

  1. Verifique se o erro ocorreu durante a execução de uma política. Consulte Como determinar a origem do problema para mais detalhes.
  2. Se o erro foi causado pela execução da política, continue. Se o erro ocorreu durante a política a execução, continue. Se o erro tiver sido causado pelo servidor de back-end, acesse Erro no servidor de back-end.
  3. Use 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, bem como ID da mensagem de solicitação exclusiva
  4. Verificar os registros do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log) e pesquise o o ID exclusivo da mensagem de solicitação.
  5. Se você encontrar o ID da mensagem de solicitação exclusiva, veja se consegue mais informações sobre a a causa da falha.

Resolução

Se você determinou a causa do problema com a política, tente corrigir o problema corrigir a política e reimplantar o proxy.

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

Se você precisar de mais ajuda para solucionar problemas do 500 Erro interno do servidor ou se suspeitar se for um problema no Edge, entre em contato com a Apigee Suporte.

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

Se a chamada para o servidor de back-end falhar na política de chamada de serviço com algum erro, como como 4XX ou 5XX, ele será tratado como 500 Erro interno do servidor.

  1. Este é um exemplo em que o serviço de back-end falha com um erro 404 no Service Política de frase de destaque. 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 rastreamento mostra o código de status 500 causado devido a um erro no Serviço Política de frase de destaque:

  3. Neste exemplo, o valor "error" lista o motivo da política da chamada de serviço falha como "ResponseCode 404 isTreat as error". Esse erro pode ocorrer se o recurso que está sendo acessado pelo URL do servidor de back-end na política da chamada de serviço não está disponíveis.
  4. Verifique a disponibilidade do recurso no servidor de back-end. Talvez ela não esteja disponível temporária/permanentemente, ou ele pode ter sido movido para outro local.

Resolução do exemplo 1

  1. Verifique a disponibilidade do recurso no servidor de back-end. Talvez ela não esteja disponível temporária/permanentemente, ou ele pode ter sido movido para outro local.
  2. Corrija o URL do servidor de back-end na política da chamada de serviço para apontar para um endereço válido recurso.
  3. Se o recurso só estiver temporariamente indisponível, tente fazer a solicitação de API assim que o recurso estiver disponível.

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

Vamos conferir outro exemplo, em que o erro 500 - Erro interno do servidor é causado por um erro. na política "Extrair variáveis" e ver como resolver o problema.

  1. O rastro a seguir na sessão da interface mostra o código de status 500 devido a um erro em "Extrair". Política de variáveis:

  2. Selecione a política "Extrair variáveis" com falha, role para baixo e veja a mensagem "Erro Conteúdo" para mais detalhes:

  3. O conteúdo de erro indica que a variável "serviceCallout.oamCookieValidationResponse" não está disponível nas a política "Extrair variáveis". Como o nome da variável indica, ela deve conter o da política de chamada de serviço anterior.
  4. Selecione a política de chamada de serviço no trace. Talvez você descubra "serviceCallout.oamCookieValidationResponse" não foi definida. Isso indica que a chamada para o serviço de back-end falhou, resultando em uma resposta vazia variável.
  5. Embora a política de chamada de serviço tenha falhado, a execução das políticas após o Serviço A política de chamada continua porque o erro "continueOnError" na política de chamada de serviço está definida como verdadeiro, 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 exclusivo da mensagem &quot;X-Apigee.Message-ID&quot; para essa API específica. do trace, da seguinte maneira:
    1. Selecione "Dados de análise registrados" da solicitação.
    2. Role para baixo e confira o valor de X-Apigee.Message-ID.

  7. Visualizar o registro do processador de mensagens (/opt/apigee/var/log/edge-message-processor/system.log) e pesquise pelo o ID da mensagem anotado na etapa 6. A seguinte mensagem de erro foi observada para a API específica solicitação: 
    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 da chamada de serviço falhou devido a uma conexão erro de tempo limite ao se conectar com o servidor de back-end.

  8. Para determinar a causa do erro de tempo limite de conexão, foi executado o comando telnet do(s) processador(es) de mensagens ao servidor de back-end. O Telnet O comando "O tempo limite de conexão expirou" foi exibido. como 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 estiver configurado para permitir tráfego da mensagem de borda Processadores.
    • Se o servidor de back-end não estiver detectando na porta específica.

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

    Sua própria política de extração de variáveis se comportará de maneira diferente e poderá falhar para outro e por um bom motivo. Você pode solucionar o problema adequadamente dependendo da causa da falha sua política "Extrair variáveis", verificando a mensagem na coluna erro .

Resolução do exemplo 2

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

Exemplo 3: falha na política Java callout

Agora, vejamos mais um exemplo, em que o erro 500 Interno do servidor é causado por um erro. na política de chamadas em Java e saiba como resolver esses problemas.

  1. O trace da 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 "Error" seguido pela política de chamadas de Java com falha para acessar os detalhes do erro, conforme mostrado na figura abaixo:

  3. Neste exemplo, a propriedade "error" na seção "Propriedades" revela que a falha se deve à senha expirada sendo usada durante a conexão com o banco de dados Oracle de acordo com a política JavaAnnotation. Sua própria chamada Java se comportará de maneira diferente e preencher uma mensagem diferente na propriedade error.
  4. Verifique o código da política JavaCall e confirme a configuração correta que precisa ser usados.

Resolução do exemplo 3

Corrija o código ou a configuração de chamada Java de maneira adequada para evitar a exceção de ambiente de execução. Em no exemplo ilustrado de falha de chamada de Java ilustrado 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 do servidor de back-end. Esta seção explica como resolver 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ê vai 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 mais detalhes.
  2. Se o erro foi causado pelo servidor de back-end, continue. Se o erro ocorreu durante execução da política, acesse Erro de execução no Edge Política.
  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 for 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 o servidor de back-end registros para receber detalhes sobre o erro.
  2. Se possível, ative o modo de depuração no servidor de back-end para conferir mais detalhes sobre a o erro e a causa.

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

Se você tiver 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 o erro 500 Servidor interno Erro.
  2. Selecione a fase Resposta recebida do servidor de destino entre as opções solicitação de API, conforme mostrado na figura abaixo:

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

  4. Neste exemplo, o conteúdo de resposta, que é um envelope de SOAP, mostra a string de falha como "Não autorizado". A causa mais provável para isso o problema é que as credenciais corretas (nome de usuário/senha, token de acesso etc.) não são passadas para servidor de back-end pelo usuário. Este problema pode ser corrigido ao transmitir as credenciais corretas ao no servidor de back-end.

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

  1. Se o back-end for um servidor de back-end do Node.js, verifique os registros do Node.js para o proxy de API específico na interface do usuário do Edge (usuários da nuvem pública e privada podem verifique os registros do Node.js). Se você for um usuário da nuvem privada do Edge, também pode 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 de 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 problema no servidor de back-end.
  2. Se for um servidor de back-end do Node.js:
    1. Verifique se o erro é gerado com base no código personalizado e corrija o problema, se possível.
    2. Se o erro não for gerado a partir do código personalizado ou se você precisar de ajuda, entre em contato Suporte da Apigee.

Se você precisar de mais ajuda para solucionar problemas do 500 Erro interno do servidor ou se suspeitar se for um problema no Edge, entre em contato com a Apigee Suporte.

Determinar a origem do problema

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

Como usar o Trace na IU

Observação: as etapas nesta seção podem ser seguidas pelas equipes de Suporte Público e e usuários da nuvem privada.

  1. Se o problema persistir, ative o rastreamento na interface da API afetada.
  2. Depois de capturar o rastreamento, 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 Erro 500 do Servidor Interno:
    1. Se o erro for gerado durante a execução de uma política, prossiga para Erro de execução em uma política do Edge.
    2. Se o servidor de back-end tiver respondido com "500 Servidor interno", prossiga para a seção 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 API Monitoring permite isolar rapidamente as áreas problemáticas para diagnosticar problemas de erro, desempenho, latência e a origem deles. como apps para desenvolvedores, proxies de API, destinos de back-end ou a plataforma de API.

Confira um exemplo de cenário que demonstra como resolver problemas 5xx com suas APIs usando a API Monitoring. Por exemplo, talvez você queira configurar um alerta para ser notificado quando o número de códigos de status 500 ou falhas steps.servicecallout.ExecutionFailed exceder um limite específico.

Como usar o acesso do NGINX Registros

Observação:as etapas nesta seção são 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 pelo servidor de back-end. Isso é será especialmente útil se o problema tiver ocorrido no passado ou se o problema for intermitente e você não conseguem capturar o rastro na interface. Siga estas etapas para determinar essas informações em 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 no duração
  3. Se houver algum erro 500, verifique se é um erro de política ou de servidor de destino. conforme mostrado abaixo:

    Exemplo de entrada com um erro de política

    Exemplo de entrada mostrando um erro do servidor de destino

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