500 Internal Server Error

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

Vídeos

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

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 erro interno do servidor 500 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, você pode observar outra mensagem de erro com mais detalhes. Confira 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 interno do servidor 500 pode ser gerado devido a várias causas diferentes. No Edge, as causas podem ser classificadas em duas categorias principais com base em onde o erro ocorreu:

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

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

Diagnóstico

Etapas de diagnóstico para usuários do Private e Public Cloud

Se você tiver a sessão de trace da interface para o erro, faça o seguinte:

1. Verifique se o erro foi causado pela execução de uma política. Consulte Determinar a origem do problema para 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 o erro interno do servidor 500 no trace.
4. Examine a solicitação e selecione a política específica que falhou ou o fluxo chamado "Erro" que segue imediatamente a política com falha no trace.
5. Para mais detalhes sobre o erro, confira o campo "error" na seção "Propriedades" ou o conteúdo do erro.
6. Usando os detalhes coletados sobre o erro, tente determinar a causa dele.

Etapas de diagnóstico apenas para usuários do Private Cloud

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

1. Verifique se o erro ocorreu durante a execução de uma política. Consulte 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 execução da política, continue. Se o erro foi causado pelo servidor de back-end, acesse Erro no servidor de back-end.
3. Use os registros de acesso do NGINX, conforme explicado em 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 pesquise o ID exclusivo da mensagem de solicitação.
5. Se você encontrar o ID exclusivo da mensagem de solicitação, verifique se é possível receber mais informações sobre a causa da falha.

Resolução

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

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

Se você precisar de mais ajuda para solucionar o erro interno do servidor 500 ou suspeitar que seja um problema no Edge, entre em contato com o suporte da Apigee.

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

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

1. Confira um exemplo em que o serviço de back-end falha com um erro 404 na política de frase de destaque do 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 de trace da interface mostra o código de status 500 causado por um erro na política de frase de destaque do serviço:

   

3. Neste exemplo, a propriedade "error" lista o motivo da falha da política de frase de destaque do serviço como "ResponseCode 404 is treated as error". Esse erro pode ocorrer se o recurso acessado pelo URL do servidor de back-end na política de frase de destaque do serviço não estiver disponível.
4. Verifique a disponibilidade do recurso no servidor de back-end. Ele pode não estar disponível temporariamente/permanentemente ou pode ter sido movido para outro local.

Resolução do exemplo 1

1. Verifique a disponibilidade do recurso no servidor de back-end. Ele pode não estar disponível temporariamente/permanentemente ou pode ter sido movido para outro local.
2. Corrija o URL do servidor de back-end na política de frase de destaque do serviço para apontar para um recurso válido e existente.
3. Se o recurso estiver temporariamente indisponível, tente fazer a solicitação de API quando o recurso estiver disponível.

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

Vamos agora analisar outro exemplo, em que o erro interno do servidor 500 é causado por um erro na política de extração de variáveis, e como solucionar e resolver 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 de extração de variáveis com falha, role para baixo e confira a seção "Conteúdo do erro" para mais detalhes:
   
   
3. O conteúdo do erro indica que a variável"serviceCallout.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 frase de destaque do serviço anterior.
4. Selecione a política de frase de destaque do 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 de frase de destaque do serviço tenha falhado, a execução das políticas após a política de frase de destaque do serviço continua porque a flag "continueOnError" na política de frase de destaque do serviço está definida como "true", 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 "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. Confira o registro do processador de mensagens (/opt/apigee/var/log/edge-message-processor/system.log) e pesquise o ID exclusivo da mensagem anotado na etapa 6. A seguinte mensagem de erro foi observada para a solicitação de API request:

   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 frase de destaque do 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 telnet comando no servidor de back-end dos processadores de mensagens. O comando telnet gerou o erro "Connection timed out", 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 do Edge Processadores.
   • Se o servidor de back-end não estiver escutando na porta específica.

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

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

Resolução do exemplo 2

1. Corrija a causa do erro ou falha na política de extração de variáveis de maneira adequada.
2. No exemplo ilustrado acima, a solução foi corrigir a configuração de rede para permitir o tráfego dos processadores de mensagens do Edge para o servidor de back-end. Isso foi feito por permitindo os endereços IP dos processadores de mensagens no servidor de back-end específico. Por exemplo, no Linux, é possível 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 JavaCallout

Vamos agora analisar mais um exemplo, em que o erro interno do servidor 500 é causado por um erro na política de frase de destaque Java, e como solucionar e resolver o problema.

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

   

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

   

3. Neste exemplo, a propriedade "error" na seção "Propriedades" revela que a falha é devido à senha expirada usada ao se conectar ao banco de dados Oracle na política JavaCallout. Sua própria chamada de Java vai se comportar de maneira diferente e vai preencher uma mensagem diferente na propriedade error.
4. Verifique o código da política JavaCallout e confirme a configuração correta que precisa ser usada.

Resolução do exemplo 3

Corrija o código ou a configuração da chamada de Java de maneira adequada para evitar a exceção de tempo de execução. No exemplo de falha de chamada de Java ilustrado acima, é necessário usar a senha correta para se conectar ao banco de dados Oracle para resolver o problema.

Erro no servidor de back-end

Um erro interno do servidor 500 também pode se originar do servidor de back-end. Esta seção explica 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. É necessário diagnosticar cada situação de forma independente.

1. Verifique se o erro foi causado pelo servidor de back-end. Consulte 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 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 de trace para a API com falha ou se o back-end é um servidor Node.js:

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

1. Se o trace da interface não estiver disponível para a solicitação com falha, verifique os registros do servidor de back-end logs para receber detalhes sobre o erro.
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.

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

Se você tiver uma sessão de trace, as etapas a seguir vão ajudar a diagnosticar o problema.

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

   

3. Confira a seção "Conteúdo da resposta" para receber detalhes sobre o erro.

   

4. Neste exemplo, o conteúdo da resposta, que é um envelope SOAP, mostra a string de falha como "Não autorizado" mensagem. 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 ao servidor de back-end pelo usuário. Esse problema pode ser corrigido transmitindo as credenciais corretas ao 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 Edge (os usuários do Public e do Private Cloud podem verificar os registros do Node.js). Se você for um usuário do Edge Private Cloud, você 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 de registros do NodeJS na guia "Visão geral" do proxy de API da interface do Edge

   

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 Node.js:
   1. Verifique se o erro é gerado pelo seu código personalizado e corrija o problema, se possível.
   2. Se o erro não for gerado pelo seu código personalizado ou se você precisar de ajuda, entre em contato com o suporte da Apigee.

Se você precisar de mais ajuda para solucionar o erro interno do servidor 500 ou suspeitar que seja um problema no Edge, entre em contato com o suporte da Apigee.

Determinar a origem do problema

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

Usar o trace na interface

Observação: as etapas nesta seção podem ser realizadas por usuários do Public e do Private Cloud.

1. Se o problema ainda estiver ativo, ative o trace na interface para a API afetada.
2. Depois de capturar o trace, 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 interno do servidor 500:
   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 respondeu com o erro interno do servidor 500, prossiga para Erro no servidor de back-end.

Usar o monitoramento de APIs

Observação:as etapas nesta seção só podem ser realizadas por usuários do Public Cloud.

O monitoramento de APIs permite isolar as áreas problemáticas rapidamente para diagnosticar problemas de erro, desempenho e latência e a origem delas, como aplicativos de desenvolvedor, proxies de API, destinos de back-end ou a plataforma de API.

Siga um cenário de exemplo que demonstra como solucionar problemas 5xx com suas APIs usando o monitoramento de APIs. Por exemplo, você pode 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.

Usar registros de acesso do NGINX

Observação: as etapas nesta seção são apenas para usuários do Edge Private Cloud.

Você também pode 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 é particularmente útil se o problema tiver ocorrido no passado ou se o problema for intermitente e você não conseguir capturar o trace na interface. Siga as etapas abaixo para determinar essas informações nos 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 durante o período específico.
3. Se houver erros 500, verifique se o erro é uma política ou um erro do servidor de destino, conforme mostrado abaixo:

   Exemplo de entrada mostrando um erro de política

   

   Exemplo de entrada mostrando um erro do servidor de destino

   

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