499 Клиент закрыл соединение

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

Симптом

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

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

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

Клиентские приложения могут видеть такие ошибки, как:

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. Постройте график кода состояния в зависимости от времени .
  4. Выберите ячейку с 499 ошибками, как показано ниже:

  5. Вы увидите информацию об ошибке 499 на правой панели, как показано ниже:

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

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

    • Запрос : предоставляет метод запроса и URI, используемый для совершения вызовов.
    • Время ответа : показывает общее время, затраченное на запрос.

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

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

    Например :

    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 или журналы доступа 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 .

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

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

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

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