499 Conexão fechada do cliente

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

Sintoma

O aplicativo cliente recebe um erro de tempo limite para solicitações de API ou a solicitação é encerrada abruptamente enquanto a solicitação de API ainda está sendo executada na Apigee.

Você vai observar o código de status 499 dessas solicitações de API na API Monitoring e registros de acesso do NGINX. Às vezes, você verá códigos de status diferentes na API Analytics devido a mostra o código de status retornado pelo processador de mensagens.

Mensagem de erro

Os aplicativos clientes podem encontrar erros como: 

curl: (28) Operation timed out after 6001 milliseconds with 0 out of -1 bytes received

O que causa os tempos limite do cliente?

O caminho típico de uma solicitação de API na plataforma Edge é Cliente > Roteador > Processador de mensagens > Backend Server conforme mostrado na figura a seguir:

Os roteadores e processadores de mensagens na plataforma Apigee Edge são configurados valores de tempo limite padrão para garantir que as solicitações da API não demorem muito para serem concluídas.

Tempo limite no cliente

Os aplicativos clientes podem ser configurados com um valor de tempo limite adequado com base nas suas necessidades.

Clientes como navegadores da Web e apps para dispositivos móveis têm tempos limite definidos pelo sistema operacional.

Tempo limite no roteador

O tempo limite padrão configurado nos roteadores é de 57 segundos. Essa é a quantidade máxima de tempo que uma O proxy de API pode ser executado desde o recebimento da solicitação de API no Edge até a resposta ser enviada de volta, incluindo a resposta de back-end e todas as políticas que são executadas. O padrão pode ser substituído nos roteadores e hosts virtuais, conforme explicado na Como configurar o tempo limite de E/S nos roteadores.

Tempo limite nos processadores de mensagens

O tempo limite padrão configurado em processadores de mensagens é de 55 segundos. Este é o valor máximo tempo que o servidor de back-end pode levar para processar a solicitação e responder ao evento de Processador. O tempo limite padrão pode ser substituído nos processadores de mensagens ou na API proxy, conforme explicado em Configurar o tempo limite de E/S em processadores de mensagens.

Se o cliente encerrar a conexão com o roteador antes que o proxy de API atinja o tempo limite, você observará o erro de tempo limite para a solicitação de API específica. O código de status 499 Client Closed Connection é registrado no Router para essas solicitações, que podem ser observados na API Monitoring e registros de acesso do NGINX.

Causas possíveis

No Edge, as causas típicas do erro 499 Client Closed Connection são:

Causa Descrição Instruções de solução de problemas aplicáveis para
O cliente fechou a conexão abruptamente Isso acontece quando o cliente encerra a conexão porque o usuário final cancelou a antes que ela seja concluída. Usuários de nuvem pública e privada
Tempo limite do aplicativo cliente Isso acontece quando o aplicativo cliente expira antes que o proxy de API tenha tempo para e enviar a resposta. Normalmente, isso acontece quando o tempo limite do cliente é menor que o tempo limite do roteador. Usuários de nuvem pública e privada

Etapas comuns do diagnóstico

Use uma das seguintes ferramentas/técnicas para diagnosticar esse erro:

  • Monitoramento de APIs
  • Registros de acesso do NGINX

Monitoramento de APIs

Para diagnosticar o erro usando a API Monitoring:

  1. Navegue até o menu Analisar > Monitoramento de APIs > Investigar.
  2. Filtre por 4xx erros e selecione o período.
  3. Relacione o Código de status com o Time.
  4. Selecione uma célula com 499 erros, conforme mostrado abaixo:

  5. As informações sobre o erro 499 serão exibidas no painel direito. mostrados abaixo:

  6. No painel à direita, clique em View logs.

    Na janela Registros de tráfego, observe os detalhes a seguir para algumas 499 erros:

    • Solicitação:fornece o método de solicitação e o URI usados para fazer as chamadas.
    • Tempo de resposta:fornece o tempo total decorrido da solicitação.
    .

    Também é possível acessar todos os registros com a API Monitoring GET logs. Para exemplo, consultando os registros para org, env, timeRange e status, você poderá fazer o download de todos os registros de transações em que o tempo limite do cliente expirou.

    Como a API Monitoring define o proxy como - para HTTP 499 use a API (API Logs) para receber a proxy associado para o host virtual e o caminho.

    For example : 

    curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
  7. Revise o Tempo de resposta para ver se há mais erros 499 e verifique se o Tempo de resposta é consistente (digamos, 30 segundos) em todos os 499 erros.

Registros de acesso do NGINX

Para diagnosticar o erro usando registros de acesso do NGINX:

  1. Se você for um usuário de nuvem privada, poderá usar registros de acesso do NGINX para determinar as principais informações sobre erros HTTP 499.
  2. Verifique os registros de acesso do NGINX:
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  3. Pesquise se há erros 499 durante um período específico (se o problema tiver acontecido no passado) ou se houver alguma solicitação que ainda esteja falhando com 499:
  4. Observe as informações a seguir para alguns dos erros 499:
    • Tempo total de resposta
    • URI de solicitação
    • User agent

    Exemplo de erro 499 do registro de acesso do NGINX:

    2019-08-23T06:50:07+00:00       rrt-03f69eb1091c4a886-c-sy      50.112.119.65:47756
10.10.53.154:8443       10.001  -       -       499     -       422     0
   GET /v1/products HTTP/1.1        -       okhttp/3.9.1    api.acme.org
rrt-03f69eb1091c4a886-c-sy-13001-6496714-1
    50.112.119.65   -       -       -       -       -       -       -       -1      -       -       dc-1  router-pod-1
rt-214-190301-0020137-latest-7d
36       TLSv1.2 gateway-1     dc-1  acme    prod  https   -

    Neste exemplo, vemos as seguintes informações:

    • Tempo total de resposta: 10.001 segundos. Isso indica que o tempo limite do cliente atingido após 10,001 segundos
    • Solicitação: GET /v1/products
    • Organizador:api.acme.org
    • User agent:okhttp/3.9.1
  5. Verifique se o Tempo total de resposta e o User agent estão consistentes entre todos os erros 499.

Causa: o cliente fechou a conexão abruptamente

Diagnóstico

  1. Quando uma API é chamada por um app de página única em execução em um navegador ou aplicativo para dispositivos móveis, o navegador abortará a solicitação se o usuário final repentinamente fechar o navegador, navegar para outra página da Web na mesma guia ou interrompe o carregamento da página clicando ou tocando parar de carregar.
  2. Se isso acontecer, as transações com status HTTP 499 normalmente variam. no tempo de processamento de solicitação (Tempo de resposta) para cada uma das solicitações.
  3. Para determinar se essa é a causa, compare o Tempo de resposta e verifique se ela é diferente para cada um dos erros 499 usando a API Monitoring ou o acesso NGINX registros, conforme explicado nas Etapas comuns de diagnóstico.

Resolução

  1. Isso é normal e não costuma ser um motivo de preocupação se os erros HTTP 499 estão acontecendo em pequenas quantidades.

  2. Se isso acontece com frequência no mesmo caminho de URL, pode ser porque o proxy específico associadas a esse caminho é muito lenta e os usuários não estão dispostos a esperar.

    Quando você souber qual proxy pode ser afetado, use o Latência painel de análise para investigar melhor o que está causando a latência do proxy.

    1. Neste caso, determine o proxy que foi afetado usando as etapas em Etapas comuns de diagnóstico.
    2. Use o Painel de análise de latência para saber o que está causando a latência de proxy e corrigir o problema.
    3. Se achar que a latência é esperada para um determinado proxy, você pode ter para informar aos usuários que este proxy vai levar algum tempo para responder.

Causa: tempo limite do aplicativo cliente

Isso pode ocorrer em diversos cenários.

  1. Espera-se que a solicitação leve um certo tempo (digamos, 10 segundos) para ser concluída. em condições normais de operação. No entanto, o aplicativo cliente está configurado com uma valor de tempo limite (digamos, 5 segundos), que faz com que o aplicativo cliente atinja o tempo limite antes a solicitação de API é concluída, levando a 499. Nesse caso, precisamos definir o tempo limite do cliente para um valor apropriado.
  2. Um servidor de destino ou uma frase de destaque está demorando mais do que o esperado. Nesse caso, você precisa corrigir o componente apropriado e ajustar adequadamente os valores de tempo limite.
  3. O cliente não precisava mais da resposta e, por isso, desistiu. Isso pode acontecer para altos e frequência, como preenchimento automático ou sondagem curta.

Diagnóstico

Registros de acesso do API Monitoring ou do NGINX

Diagnostique o erro usando os registros de acesso do API Monitoring ou do NGINX:

  1. Verifique os registros de monitoramento da API ou os registros de acesso do NGINX para as transações HTTP 499, conforme explicado em Etapas comuns de diagnóstico.
  2. Determine se o Tempo de resposta é consistente para todos os erros 499.
  3. Se sim, pode ser que um aplicativo cliente específico tenha configurado um tempo limite fixo por isso. Se um proxy de API ou servidor de destino estiver respondendo lentamente, o cliente atingirá o tempo limite antes que o proxy atinja o tempo limite, resultando em grandes quantidades de 499s HTTP para o mesmo caminho de URI. Nesse caso, determine o User agent nos registros de acesso do NGINX que pode ajudar a determinar o aplicativo cliente específico.
  4. Também pode haver um balanceador de carga na Apigee, como a Akamai, F5, ELB da AWS e assim por diante. Se a Apigee estiver sendo executada atrás de um balanceador de carga personalizado, a solicitação do balanceador de carga precisa ser configurado para ser maior do que o tempo limite da API Apigee. De padrão, o roteador da Apigee expira após 57 segundos. Portanto, é adequado configurar uma solicitação de 60 segundos no balanceador de carga.

Trace

Diagnosticar o erro usando o Trace

Se o problema ainda estiver ativo (499 erros ainda estão acontecendo), execute o etapas a seguir:

  1. Ative o Rastrear sessão da API afetada na interface do Edge.
  2. Aguarde a ocorrência do erro ou, caso tenha a chamada de API, faça algumas chamadas de API e reproduzir o erro.
  3. Verificar o tempo decorrido em cada fase e anotar aquela em que a maior parte do tempo é gasto.
  4. Se você observar o erro com o maior tempo decorrido logo após uma das fases seguintes, isso indica que o servidor de back-end está lento ou demorando muito para processar a solicitação:
    • Solicitação enviada ao servidor de destino
    • Política ServiceCallout

    Confira um exemplo de trace de interface mostrando um tempo limite de gateway depois que a solicitação foi enviados ao servidor de destino:

Resolução

  1. Consulte Práticas recomendadas para configurar o tempo limite de E/S e entender quais valores de tempo limite devem ser definidos em diferentes componentes envolvidos no fluxo de solicitação de API pelo Apigee Edge.
  2. Defina um valor de tempo limite apropriado no aplicativo cliente de acordo com práticas recomendadas.

Se o problema persistir, acesse É preciso coletar informações de diagnóstico .

É necessário coletar informações de diagnóstico

Se o problema persistir, reúna as informações de diagnóstico a seguir e entre em contato com o suporte do Apigee Edge.

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

  • Nome da organização
  • Nome do ambiente
  • Nome do proxy da API
  • Comando curl completo usado para reproduzir o erro de tempo limite
  • Arquivo de rastreamento das solicitações de API para as quais você está vendo erros de tempo limite do cliente

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

  • Mensagem de erro completa observada para as solicitações com falha
  • Nome do ambiente
  • Pacote de proxy de API
  • Arquivo de rastreamento das solicitações de API para as quais você está vendo erros de tempo limite do cliente
  • Registros de acesso do NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
  • Registros do sistema do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log)