Esta página foi traduzida pela API Cloud Translation.

500 Erro interno do servidor - Transmissão ativada

Esta é a documentação do Apigee Edge.
Acesse Documentação da Apigee X. informações

Sintoma

O aplicativo cliente recebe um código de status de resposta HTTP 500 com a mensagem Internal Server Error para chamadas de API.

Mensagens de erro

Os aplicativos clientes podem receber uma resposta de erro, conforme mostrado abaixo:

HTTP/1.1 500 Internal Server Error

Isso pode ser seguido por uma mensagem de erro como esta:

{
   "fault":{
      "faultstring":"Expecting } at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

OR

{
   "fault":{
      "faultstring":"Expecting ] at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

Causas possíveis

O Erro interno do servidor 500 pode ocorrer devido a várias causas diferentes. Este manual concentra-se no erro 500 interno do servidor causado pelo acesso à solicitação/resposta payload ao fazer streaming está ativada.

Causa	Descrição	Quem pode executar as etapas de solução de problemas
Como acessar o payload com Streaming ativado	Ocorreu um erro porque o payload de solicitação/resposta é acessado quando o streaming é ativado.	Usuários de nuvem pública e privada de borda

Causa: acesso ao payload com streaming ativado

Diagnóstico

Procedimento no 1: como usar o Trace

Ativar o trace sessão e faça a chamada de API para reproduzir o problema: 500 Erro interno do servidor.
Selecione uma das solicitações com falha e examine o trace.
Navegue pelas várias fases do trace e localize onde a falha ocorreu.
Este erro pode ter ocorrido enquanto uma política analisava o payload de solicitação/resposta.
Este é um exemplo de captura de tela de rastros mostrando o JSONThreatProtection política falha com o erro "Expecting } at line 1":

Anote as seguintes informações da saída de rastreamento, conforme mostrado acima captura de tela:

Política de falha : JSONThreatProtection

Fluxo: solicitação de proxy

Examine a definição da política com falha e verifique o payload que está sendo analisado.

No cenário de exemplo, analise a política JSONThreatProtection chamada JSON-Threat-Protection que falhou e verifique o elemento <Source>.

<JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JSON-Threat-Protection">
   <DisplayName>JSON Threat Protection</DisplayName>
   <ArrayElementCount>20</ArrayElementCount>
   <ContainerDepth>10</ContainerDepth>
   <ObjectEntryCount>15</ObjectEntryCount>
   <ObjectEntryNameLength>50</ObjectEntryNameLength>
   <Source>request</Source>
   <StringValueLength>1000</StringValueLength>
</JSONThreatProtection>

O elemento <Source> aponta para request.. Isso significa que o erro ocorreu durante a análise da carga útil da solicitação.

Verifique a solicitação de API para determinar o tipo de payload analisado.

É possível verificar o conteúdo do payload da solicitação e do cabeçalho Content-Type em a solicitação de API. No exemplo de comando curl a seguir, é usado um payload JSON.

curl -i https://VIRTUAL_HOST_ALIAS/BASEPATH -H "Content-Type: application/json" \
-X POST -d @request-payload.json

Você também pode verificar a política que está falhando e determinar o tipo de payload que está sendo analisados. No cenário de exemplo acima, a política de proteção contra ameaças JSON está falhando. Isso indica que o payload precisa estar no formato JSON.

Valide se o payload está no formato adequado. Se o payload não for válido, você poderá receber esse erro.

Observação : se o payload for grande, você pode usar qualquer formatador on-line para validar o do payload.
Se o payload for válido, mas você ainda estiver recebendo erros conforme listados no Mensagens de erro, a causa desses erros é que o payload é acessado quando o streaming está ativado.

Dependendo do payload analisado pela política (conforme determinado na etapa 6), examinar o conteúdo do payload na ferramenta Trace na fase apropriada.

No cenário de exemplo, a carga útil da solicitação está sendo analisada, portanto, examine o fase "Request Received from Client" no trace e verifique o Solicitar conteúdo.

Se o conteúdo da solicitação estiver vazio, como mostrado na captura de tela acima, mesmo que você tiver enviado um payload válido, isso indica que a causa provável desse problema é streaming de solicitações ativado.

Isso ocorre porque, quando o streaming está ativado, o payload da solicitação não aparece no trace.

Da mesma forma, se o payload de resposta estiver sendo analisado quando o erro ocorrer, verifique o o conteúdo da resposta na fase "Response recebida do servidor de destino".
Em seguida, examine as definições de proxy e endpoint de destino dependendo do local é usada no fluxo do proxy de API. Verifique se o streaming foi ativado.

No cenário de exemplo, a política com falha foi executada no fluxo de solicitação de proxy (conforme determinado na etapa 5 acima); Portanto, examine o endpoint de proxy:
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
    <Properties>
      <Property name="response.streaming.enabled">true</Property>
      <Property name="request.streaming.enabled">true</Property>
    </Properties>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
Conforme o exemplo acima, o streaming de solicitação foi ativado conforme indicado pelo propriedade "request.streaming.enabled" definida como verdadeira.

A causa do erro é usar a política JSONThreatProtection no proxy da API que acessa o payload da solicitação quando o streaming está ativado. Isso causa erros porque aciona o armazenamento em buffer no proxy de API e invalida o propósito de uso do streaming no Apigee Edge.

Esse erro pode não ser visto com payloads menores, mas, ao usar payloads maiores, podem ver esses erros.
Para confirmar se o erro 500 foi causado pela política, confira o valor do "X-Apigee-fault-source" no "AX" (Dados de análise registrados) fase no rastreamento seguindo as etapas abaixo:
1. Clique na fase "AX" (dados do Google Analytics registrados). conforme mostrado na captura de tela abaixo:
2. Role para baixo em "Stage Details" (Detalhes da fase) até a opção "Error Headers" (Cabeçalhos de erro). e determinar os valores de "X-Apigee-fault-code", "X-Apigee-fault-source" e "X-Apigee-fault-policy" conforme mostrado abaixo:
3. Se o valor de "X-Apigee-fault-source" for "policy" conforme mostrado na imagem acima, isso indica que o erro foi causado por uma política que acessou payload quando o streaming estiver ativado.

Resolução

O acesso ao payload com streaming ativado é um antipadrão, conforme explicado em Antipadrão: acessar o payload de solicitação/resposta quando o streaming estiver ativado.

Se quiser processar o payload, você precisa desativar o streaming no proxy/Destino Endpoint removendo as propriedades "request.streaming.enabled" and "response.streaming.enabled", como mostrado no ProxyEndpoint de exemplo abaixo:
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
OU
Se quiser usar o streaming para seus proxies de API, não use políticas na Proxy de API que acessam o payload de solicitação/resposta.

Observação:

Neste playbook, a política JSONThreatProtection foi usada para processar o payload da solicitação com streaming ativado no cenário de exemplo. Isso levou ao erro 500 Internal Server Error, com erros diferentes.
Esses erros também podem ser vistos com políticas como JSONToXML e XMLToJSON, que processam payloads de solicitação ou resposta quando o streaming está ativado.
Recomendamos não usar essas políticas em proxies que exigem acesso a payloads quando o streaming estiver ativado.
Fazer isso é um antipadrão, conforme documentado em Antipadrão: acessar o payload de solicitação/resposta quando o streaming estiver ativado.

Diagnosticar problemas usando o monitoramento de APIs

Se você for usuário da nuvem privada, pule este procedimento.

O API Monitoring permite isolar as áreas problemáticas rapidamente para diagnosticar problemas de erro, desempenho e latência e a origem deles, como apps para desenvolvedores, proxies de API, destinos de back-end ou 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 500 erros exceder um limite específico.

Se você quiser receber uma notificação quando uma resposta de erro 500 for gerada pela política, configure o alerta para o código de status 500 com a origem da falha como Proxy.

É 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 de diagnóstico. Entre em contato com eles e compartilhe com o suporte da Apigee.

Se você é usuário da nuvem pública, forneça as seguintes informações:

Nome da organização
Nome do ambiente
Nome do proxy da API
Completar o comando curl junto com o payload da solicitação (se houver) para reproduzir o erro 500
Arquivo de rastreamento contendo as solicitações com erro 500 Interno do servidor
Se os erros 500 não estiverem ocorrendo atualmente, forneça o período com as informações de fuso horário em que os erros 500 ocorreram no passado.

Se você é usuário da nuvem privada, forneça as seguintes informações:

Mensagem de erro completa observada para as solicitações com falha
Organização, nome do ambiente e nome do proxy da API para os quais você está observando erros 500
Pacote de proxy de API
Payload usado na solicitação (se houver)
Arquivo de rastreamento contendo as solicitações com erro 500 Interno do servidor
Registros de acesso do NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
Registros 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.