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:
- Verifique se o erro foi causado pela execução de uma política. Consulte Como determinar a origem do problema para ver mais detalhes.
- 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.
- Selecione a solicitação de API que está falhando com 500 Erro interno do servidor no trace.
- 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.
- Para saber mais detalhes, verifique o campo "erro" na seção "Propriedades" ou o conteúdo do erro.
- 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:
- Verifique se o erro ocorreu durante a execução de uma política. Consulte Como determinar a origem do problema para ver mais detalhes.
- 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.
- 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
- 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. - 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.
- 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" } } }
- 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:
- 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.
- 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
- 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.
- 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.
- 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.
- 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:
- 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:
- 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.
- 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.
- 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>
- Anote o ID de mensagem exclusivo "X-Apigee.Message-ID" para essa solicitação de API específica do trace, da seguinte maneira:
- Selecione a fase "Dados do Analytics registrados" na solicitação.
- Role para baixo e anote o valor de X-Apigee.Message-ID.
- 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.
- 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
- Corrija a causa do erro ou da falha na política "Extrair variáveis" corretamente.
- 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.
- O trace de interface a seguir mostra o código de status 500 devido a um erro na política de chamadas do Java:
- 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:
- 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.
- 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.
- Verifique se o erro foi causado pelo servidor de back-end. Consulte Como determinar a origem do problema para ver mais detalhes.
- 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.
- 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:
- 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.
- 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.
- Na ferramenta Trace, selecione a solicitação de API que falhou com "500 Erro interno do servidor".
- Selecione a fase "Resposta recebida do servidor de destino" na solicitação de API com falha, conforme mostrado na figura abaixo:
- Verifique a seção Conteúdo da resposta para saber mais detalhes sobre o erro.
- 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:
- 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
- Depois de identificar a causa do erro, corrija-o no servidor de back-end.
- Se for um servidor de back-end do Node.js:
- Verifique se o erro é gerado no código personalizado e corrija o problema, se possível.
- 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.
- Se o problema continuar ativo, ative o rastreamento na interface da API afetada.
- Depois de capturar o rastro, selecione a solicitação de API que mostra o código de resposta como 500.
- Navegue por todas as fases da solicitação de API com falha e verifique qual fase retorna o erro 500 interno do servidor:
- Se o erro for gerado durante a execução de uma política, acesse Erro de execução em uma política de borda.
- 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:
- Verifique os registros de acesso do NGINX (
/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log
). - Pesquise se há erros 500 para o proxy de API específico com a duração determinada.
- 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
- Depois de identificar se é um erro de servidor de destino ou política, faça o seguinte:
- Prossiga para Erro de execução em uma política de borda se for um erro de política.
- Prossiga para Erro no servidor de back-end se for um erro de servidor de destino.