Esta página foi traduzida pela API Cloud Translation.

500 Erro interno do servidor - Transmissão ativada

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

Sintoma

O aplicativo cliente recebe um código de status de resposta HTTP 500 com a mensagem Erro interno do servidor 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

Pode aparecer uma mensagem de erro parecida com 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. O foco deste playbook é o Erro interno do servidor 500 causado pelo acesso ao payload de solicitação/resposta quando o streaming está ativado.

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

Causa: acessar payload com o streaming ativado

Diagnóstico

Procedimento 1: como usar o Trace

Ative a sessão de rastreamento 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 rastro.
Navegue pelas várias fases do rastro e localize onde a falha ocorreu.
Esse erro pode ter ocorrido enquanto uma política está analisando o payload de solicitação/resposta.
Veja um exemplo de captura de tela de rastros que mostra a falha na política JSONThreatProtection e o erro "Expecting } na linha 1":

Anote as seguintes informações do resultado do rastro, conforme mostrado na captura de tela acima:

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, examine 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 ao analisar o payload da solicitação.

Determine o tipo de payload que está sendo analisado verificando a solicitação de API.

É possível verificar o conteúdo do payload da solicitação e do cabeçalho Content-Type na 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

Também é possível verificar a política que está falhando e determinar o tipo de payload que está sendo analisado. No cenário de exemplo acima, a política JSON-Threat-Protection 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, será possível usar qualquer formatador on-line para validar o formato dele.
Se o payload for válido, mas você ainda estiver recebendo erros conforme listado na seção Mensagens de erro, a causa desses erros é que o payload está sendo acessado quando o streaming está ativado.

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

No cenário de exemplo, o payload da solicitação está sendo analisado. Portanto, examine a fase "Request Received from Client" no rastro e verifique a Request Content.

Se o conteúdo da solicitação estiver vazio, como mostrado na captura de tela acima, mesmo que você tenha enviado um payload válido, isso indica que a causa provável desse problema é que o streaming de solicitações está 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 da resposta estiver sendo analisado quando o erro ocorrer, verifique o conteúdo da resposta na fase "Resposta recebida do servidor de destino".
Em seguida, examine as definições do proxy e do endpoint de destino, dependendo de onde a política com falha é usada no fluxo do proxy da 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 do 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 mostrado no exemplo acima, o streaming de solicitações foi ativado conforme indicado pela propriedade "request.streaming.enabled" definida como "true".

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

É possível que esse erro não apareça com payloads menores. No entanto, ao usar payloads maiores, é possível vê-los.
É possível verificar se o erro 500 é causado devido à política, verificando o valor de "X-Apigee-fault-source" na fase "AX" (Dados do Analytics gravados) no rastro usando as etapas abaixo:
1. Clique na fase "AX" (Dados do Analytics registrados), conforme mostrado na captura de tela abaixo:
2. Role os detalhes da fase para baixo até a seção "Cabeçalhos de erro" e determine 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", como mostrado na imagem acima, isso indica que o erro é causado porque a política acessa o payload quando o streaming está ativado.

Resolução

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

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

Observação:

Neste playbook, a política JSONThreatProtection foi usada para processar o payload da solicitação com o streaming ativado no cenário de exemplo. Isso levou a "500 Internal Server Error" (Erro interno do servidor) 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.
É altamente recomendável não usar essas políticas em proxies que exigem acesso a payloads quando o streaming estiver ativado.
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 um usuário da nuvem privada, pule este procedimento.

O Monitoramento de API 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 de 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 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 o suporte da Apigee e compartilhe com eles.

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

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

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

Concluir a mensagem de erro observada para as solicitações com falha
Organização, nome do ambiente e nome do proxy da API para os quais você está observando 500 erros
Pacote de proxy de API
Payload usado na solicitação (se houver)
Arquivo de rastreamento que contém as solicitações com "500 Erro 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 ocorreram os erros 500.