499 Conexão fechada do cliente

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

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 para essas solicitações de API no Monitoramento de APIs e nos registros de acesso do NGINX. Às vezes, você verá códigos de status diferentes no Google Analytics porque ele mostra o código de status retornado pelo processador de mensagens.

Mensagem de erro

Os aplicativos clientes podem mostrar erros como: 

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

O que causa tempos limite do cliente?

O caminho típico de uma solicitação de API na plataforma Edge é Cliente > Roteador > Processador de mensagens > Servidor de back-end , conforme mostrado na figura a seguir:

Os roteadores e processadores de mensagens na plataforma Apigee Edge são configurados com valores de tempo limite padrão adequados para garantir que as solicitações de 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. Esse é o tempo máximo que um proxy de API pode executar desde o momento em que a solicitação de API é recebida no Edge até que a resposta seja enviada de volta, incluindo a resposta de back-end e todas as políticas executadas. O tempo limite padrão pode ser substituído nos roteadores e hosts virtuais, conforme explicado em Como configurar o tempo limite de E/S nos roteadores.

Tempo limite nos processadores de mensagens

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

Se o cliente fechar a conexão com o roteador antes que o proxy de API atinja o tempo limite, você vai 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 roteador para essas solicitações, que podem ser observadas no Monitoramento de APIs e nos 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 fecha a conexão porque o usuário final cancelou a solicitação antes que ela fosse concluída. Usuários da nuvem pública e privada
Tempo limite do aplicativo cliente Isso acontece quando o aplicativo cliente atinge o tempo limite antes que o proxy de API tenha tempo para processar e enviar a resposta. Normalmente, isso acontece quando o tempo limite do cliente é menor que o tempo limite do roteador. Usuários da 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 o Monitoramento de APIs:

  1. Acesse a página Analisar > Monitoramento de APIs > Investigar.
  2. Filtre erros 4xx e selecione o período.
  3. Faça um gráfico de Código de status em relação ao Tempo.
  4. Selecione uma célula que tenha erros 499, conforme mostrado abaixo:

  5. As informações sobre o erro 499 vão aparecer no painel à direita, conforme mostrado abaixo:

  6. No painel à direita, clique em Ver registros.

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

    • 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 para a solicitação.

    Também é possível receber todos os registros usando a API GET logs do Monitoramento de APIs. Por exemplo, ao consultar registros para org, env, timeRange e status, você poderá fazer o download de todos os registros de transações em que o cliente atingiu o tempo limite.

    Como o Monitoramento de APIs define o proxy como - para erros HTTP 499, você pode usar a API (API Logs) para receber o proxy associado ao host virtual e ao 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. Analise o Tempo de resposta para outros erros 499 e verifique se o Tempo de resposta é consistente (digamos, 30 segundos) em todos os erros 499.

Registros de acesso do NGINX

Para diagnosticar o erro usando os registros de acesso do NGINX:

  1. Se você for um usuário do Private Cloud, poderá usar os registros de acesso do NGINX para determinar as informações principais 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 para ver se há erros 499 durante um período específico (se o problema aconteceu no passado) ou se ainda há solicitações com falha com 499.
  4. Anote as informações a seguir para alguns dos erros 499:
    • Tempo total de resposta
    • URI da 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   -

    Para este exemplo, temos as seguintes informações:

    • Tempo total de resposta:10.001 segundos. Isso indica que o cliente atingiu o tempo limite após 10.001 segundos.
    • Solicitação:GET /v1/products
    • Host:api.acme.org
    • User agent:okhttp/3.9.1
  5. Verifique se o Tempo total de resposta e o User agent são consistentes em todos os erros 499.

Causa: o cliente fechou a conexão abruptamente

Diagnóstico

  1. Quando uma API é chamada de um app de página única em execução em um navegador ou aplicativo para dispositivos móveis, o navegador vai abortar a solicitação se o usuário final fechar o navegador repentinamente, navegar para outra página da Web na mesma guia ou impedir que a página seja carregada clicando ou tocando Parar carregamento.
  2. Se isso acontecer, as transações com status HTTP 499 normalmente vão variar no tempo de processamento da solicitação (Tempo de resposta) para cada uma das solicitações.
  3. Você pode determinar se essa é a causa comparando o Tempo de resposta e verificando se é diferente para cada um dos erros 499 usando o Monitoramento de APIs ou os registros de acesso do NGINX, conforme explicado em Etapas comuns do diagnóstico.

Resolução

  1. Isso é normal e geralmente não é motivo de preocupação se os erros HTTP 499 estiverem ocorrendo em pequenas quantidades.

  2. Se isso acontecer com frequência para o mesmo caminho do URL, pode ser porque o proxy associado a esse caminho é muito lento e os usuários não querem esperar.

    Depois de saber qual proxy pode ser afetado, use o Painel de análise de latência para investigar melhor o que está causando a latência do proxy.

    1. Nesse caso, determine o proxy afetado usando as etapas em Etapas comuns do diagnóstico.
    2. Use o painel de análise de latência para investigar melhor o que está causando a latência do proxy e corrigir o problema.
    3. Se você descobrir que a latência é esperada para o proxy específico, então você pode ter que informar aos seus usuários que este proxy levará algum tempo para responder.

Causa: tempo limite do aplicativo cliente

Isso pode ocorrer em vários cenários.

  1. Espera-se que a solicitação leve um determinado tempo (digamos, 10 segundos) para ser concluída em condições normais de operação. No entanto, o aplicativo cliente é definido com um valor de tempo limite incorreto (digamos, 5 segundos), o que faz com que o aplicativo cliente atinja o tempo limite antes que a solicitação de API seja concluída, resultando em 499. Nesse caso, precisamos definir o tempo limite do cliente para um valor adequado.
  2. Um servidor de destino ou callout está demorando mais do que o esperado. Nesse caso, é necessário corrigir o componente adequado e também ajustar os valores de tempo limite de acordo.
  3. O cliente não precisava mais da resposta e, portanto, foi abortado. Isso pode acontecer para APIs de alta frequência, como preenchimento automático ou polling curto.

Diagnóstico

Monitoramento de APIs ou registros de acesso do NGINX

Diagnostique o erro usando o Monitoramento de APIs ou os registros de acesso do NGINX:

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

Trace

Diagnostique o erro usando o Trace

Se o problema ainda estiver ativo (499 erros ainda estão acontecendo), siga estas etapas:

  1. Ative a sessão de trace para a API afetada na interface da Apigee.
  2. Aguarde a ocorrência do erro ou, se você tiver a chamada de API, faça algumas chamadas de API e reproduza o erro.
  3. Verifique o tempo decorrido em cada fase e anote a fase em que a maior parte do tempo é gasto.
  4. Se você observar o erro com o tempo decorrido mais longo imediatamente após uma das fases a seguir, 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 da interface mostrando um tempo limite do gateway após o envio da solicitação ao servidor de destino:

Resolução

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

Se o problema persistir, acesse Precisa de 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 da Apigee Edge.

Se você for um usuário da 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 trace para as solicitações de API em que você está vendo erros de tempo limite do cliente

Se você for um usuário do Private Cloud, 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 trace para as solicitações de API em que 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)