499 Client closed connection (499 Клиент закрыл подключение)

Вы просматриваете документацию по Apigee Edge.
Перейдите к документации по Apigee X. Информация

Symptom

Клиентское приложение получает ошибку тайм-аута для запросов API или запрос внезапно завершается, пока он ещё выполняется в Apigee.

В API Monitoring и журналах доступа NGINX для таких запросов API будет указан код статуса 499. Иногда в API Аналитики можно увидеть разные коды статуса, поскольку в нем показывается код статуса, возвращенный обработчиком сообщений.

Сообщение об ошибке

В клиентских приложениях могут появляться следующие ошибки: 

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

Что вызывает тайм-ауты на стороне клиента?

Типичный путь запроса API на платформе Edge: Клиент > Маршрутизатор > Обработчик сообщений > Внутренний сервер, как показано на рисунке ниже.

На платформе Apigee Edge для маршрутизаторов и процессоров сообщений заданы подходящие значения времени ожидания по умолчанию, чтобы запросы к API не выполнялись слишком долго.

Время ожидания на стороне клиента

В клиентских приложениях можно задать подходящее время ожидания.

У клиентов, таких как веб-браузеры и мобильные приложения, есть тайм-ауты, заданные операционной системой.

Время ожидания на маршрутизаторе

По умолчанию на маршрутизаторах настроено время ожидания 57 секунд. Это максимальное время, в течение которого прокси-сервер API может выполняться с момента получения запроса к API в Edge до отправки ответа, включая ответ от внутреннего сервиса и все выполненные правила. Значение тайм-аута по умолчанию можно переопределить на маршрутизаторах и виртуальных хостах, как описано в разделе Настройка тайм-аута ввода-вывода на маршрутизаторах.

Время ожидания процессоров сообщений истекло

По умолчанию время ожидания, настроенное в процессорах сообщений, составляет 55 секунд. Это максимальное время, которое серверу может потребоваться для обработки запроса и отправки ответа процессору сообщений. Время ожидания по умолчанию можно переопределить в процессорах сообщений или в прокси-сервере API, как описано в разделе Настройка времени ожидания ввода-вывода в процессорах сообщений.

Если клиент закроет подключение к маршрутизатору до истечения времени ожидания прокси-сервера API, вы увидите ошибку времени ожидания для определенного запроса к API. Код статуса 499 Client Closed Connection регистрируется в маршрутизаторе для таких запросов, что можно увидеть в журналах мониторинга API и доступа NGINX.

Возможные причины

В Edge ошибка 499 Client Closed Connection обычно возникает по следующим причинам:

Причина Описание Инструкции по устранению неполадок, применимые к
Клиент внезапно закрыл подключение Это происходит, когда клиент закрывает подключение, потому что конечный пользователь отменил запрос до его завершения. Пользователи общедоступного и частного облака
Время ожидания клиентского приложения Это происходит, когда время ожидания клиентского приложения истекает до того, как прокси API успевает обработать и отправить ответ. Как правило, это происходит, когда время ожидания клиента меньше времени ожидания маршрутизатора. Пользователи общедоступного и частного облака

Распространенные этапы диагностики

Чтобы диагностировать эту ошибку, используйте один из следующих инструментов или методов:

  • Мониторинг API
  • Журналы доступа NGINX

Мониторинг API

Чтобы диагностировать ошибку с помощью мониторинга API:

  1. Перейдите на страницу Анализ > Мониторинг API > Исследование.
  2. Отфильтруйте ошибки 4xx и выберите временной диапазон.
  3. Постройте график Код статуса по оси Y и Время по оси X.
  4. Выберите ячейку с ошибками 499, как показано ниже.

  5. Справа появится информация об ошибке 499, как показано ниже:

  6. На панели справа нажмите Посмотреть журналы.

    В окне Журналы трафика обратите внимание на следующие сведения об ошибках 499:

    • Запрос. Метод запроса и URI, использованные для выполнения вызовов.
    • Response Time – общее время, затраченное на запрос.

    Вы также можете получить все журналы с помощью API мониторинга API GET logs. Например, если вы запросите журналы для org, env, timeRange и status, то сможете скачать все журналы для транзакций, в которых истекло время ожидания клиента.

    Поскольку API Monitoring задает для прокси значение - при ошибках HTTP 499, вы можете использовать API (Logs API), чтобы получить связанный прокси для виртуального хоста и пути.

    For example : 

    curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
  7. Проверьте Время ответа на наличие дополнительных ошибок 499 и убедитесь, что Время ответа одинаково (например, 30 секунд) для всех ошибок 499.

Журналы доступа NGINX

Чтобы диагностировать ошибку с помощью журналов доступа NGINX:

  1. Если вы используете частное облако, то можете использовать журналы доступа NGINX, чтобы определить ключевую информацию об ошибках HTTP 499.
  2. Проверьте журналы доступа NGINX:
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  3. Выполните поиск, чтобы узнать, были ли 499 ошибки за определенный период (если проблема возникла в прошлом) или есть ли запросы, которые по-прежнему завершаются с ошибкой 499.
  4. Ниже приведена информация о некоторых ошибках 499:
    • Общее время ответа
    • URI запроса
    • Агент пользователя

    Пример ошибки 499 из журнала доступа 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   -

    В нашем примере мы видим следующую информацию:

    • Общее время ответа: 10.001 секунд. Это означает, что время ожидания клиента истекло через 10,001 секунды.
    • Запрос: GET /v1/products
    • Хост: api.acme.org.
    • Агент пользователя:okhttp/3.9.1
  5. Проверьте, одинаковы ли значения Общее время ответа и Агент пользователя для всех ошибок 499.

Причина: клиент внезапно закрыл подключение.

диагностика;

  1. Если API вызывается из одностраничного приложения, запущенного в браузере или мобильном приложении, браузер прервет запрос, если конечный пользователь внезапно закроет браузер, перейдет на другую веб-страницу на той же вкладке или остановит загрузку страницы, нажав Остановить загрузку.
  2. В этом случае транзакции со статусом HTTP 499 обычно различаются по времени обработки запроса (Время ответа).
  3. Чтобы определить, является ли это причиной, сравните время ответа и проверьте, отличается ли оно для каждой из ошибок 499, используя мониторинг API или журналы доступа NGINX, как описано в разделе Распространенные шаги диагностики.

Разрешение

  1. Это нормальное явление, и, как правило, оно не вызывает беспокойства, если ошибок HTTP 499 немного.

  2. Если это часто происходит с одним и тем же путем URL, возможно, прокси-сервер, связанный с этим путем, работает очень медленно и пользователи не хотят ждать.

    Определив, какой прокси-сервер может быть затронут, используйте панель анализа задержки, чтобы выяснить причину задержки.

    1. В этом случае определите, какой прокси-сервер затронут, выполнив общие шаги диагностики.
    2. Используйте панель мониторинга анализа задержек, чтобы выяснить, что вызывает задержку прокси-сервера, и устранить проблему.
    3. Если вы считаете, что задержка для определенного прокси-сервера является ожидаемой, сообщите пользователям, что ответ от этого прокси-сервера может приходить с задержкой.

Причина: истекло время ожидания клиентского приложения

Это может произойти в нескольких случаях.

  1. Ожидается, что при нормальных условиях работы запрос будет выполнен за определенное время (например, за 10 секунд). Однако в клиентском приложении задано неправильное значение времени ожидания (например, 5 секунд), из-за чего клиентское приложение перестает отвечать до того, как будет выполнен запрос к API, что приводит к ошибке 499. В этом случае необходимо задать подходящее значение для времени ожидания клиента.
  2. Целевой сервер или вызов занимает больше времени, чем ожидалось. В этом случае вам нужно исправить соответствующий компонент и настроить значения времени ожидания.
  3. Клиенту больше не нужен ответ, поэтому он отменил запрос. Это может произойти с API, которые используются часто, например с API автозаполнения или короткого опроса.

диагностика;

Мониторинг API или журналы доступа NGINX

Выполните диагностику ошибки с помощью мониторинга API или журналов доступа NGINX:

  1. Проверьте журналы мониторинга API или журналы доступа NGINX на наличие транзакций HTTP 499, как описано в разделе Распространенные действия по диагностике.
  2. Определите, одинаково ли время ответа для всех ошибок 499.
  3. Если да, возможно, в клиентском приложении настроено фиксированное время ожидания. Если прокси-сервер API или целевой сервер отвечает медленно, клиент будет отключаться по тайм-ауту раньше, чем прокси-сервер, что приведет к большому количеству ошибок HTTP 499s для одного и того же пути URI. В этом случае определите агента пользователя по журналам доступа NGINX, чтобы узнать, какое именно клиентское приложение используется.
  4. Также возможно, что перед Apigee находится балансировщик нагрузки, например Akamai, F5, AWS ELB и т. д. Если Apigee работает за пользовательским балансировщиком нагрузки, время ожидания запроса балансировщика нагрузки должно быть больше, чем время ожидания API Apigee. По умолчанию время ожидания маршрутизатора Apigee составляет 57 секунд, поэтому на балансировщике нагрузки можно настроить время ожидания запроса в 60 секунд.

Трассировка

Как диагностировать ошибку с помощью Trace

Если проблема не устранена (ошибки 499 по-прежнему возникают), выполните следующие действия:

  1. Включите сеанс трассировки для затронутого API в интерфейсе Edge.
  2. Дождитесь появления ошибки или, если у вас есть вызов API, сделайте несколько вызовов API и воспроизведите ошибку.
  3. Проверьте время, затраченное на каждом этапе, и запишите, на каком этапе было потрачено больше всего времени.
  4. Если ошибка с самым большим временем ожидания произошла сразу после одного из следующих этапов, это означает, что сервер работает медленно или долго обрабатывает запрос:
    • Запрос отправлен целевому серверу
    • Правила ServiceCallout

    Ниже приведен пример трассировки интерфейса, в котором после отправки запроса на целевой сервер появляется сообщение Время ожидания шлюза истекло:

Разрешение

  1. Чтобы узнать, какие значения тайм-аута следует задать для разных компонентов, участвующих в потоке запросов API через Apigee Edge, ознакомьтесь с рекомендациями по настройке тайм-аута ввода-вывода.
  2. Убедитесь, что в клиентском приложении задано подходящее значение времени ожидания в соответствии с рекомендациями.

Если проблема не устранена, перейдите к разделу Обязательная диагностическая информация .

Необходимо собрать диагностическую информацию

Если проблема не исчезнет, соберите указанную ниже диагностическую информацию и обратитесь в службу поддержки Apigee Edge.

Если вы используете общедоступное облако, предоставьте следующую информацию:

  • Название организации
  • Название среды
  • Название прокси API
  • Полная команда curl, использованная для воспроизведения ошибки тайм-аута
  • Файл трассировки для запросов API, для которых возникают ошибки тайм-аута клиента

Если вы используете частное облако, предоставьте следующую информацию:

  • Полное сообщение об ошибке, которое появляется при неудачных запросах.
  • Название среды
  • Пакет прокси API
  • Файл трассировки для запросов API, для которых возникают ошибки тайм-аута клиента
  • Журналы доступа NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
  • Системные журналы Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)