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

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

Симптом

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

В журналах мониторинга API и журналах доступа NGINX для таких API-запросов вы увидите код состояния 499 Иногда в 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 logs . Например, запросив журналы по 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-пути. В этом случае определите User Agent из журналов доступа NGINX, что поможет вам определить конкретное клиентское приложение.
  4. Также возможно, что перед Apigee используется балансировщик нагрузки, например Akamai, F5, AWS ELB и т.д. Если Apigee работает за собственным балансировщиком нагрузки, время ожидания запроса у балансировщика должно быть больше, чем время ожидания API Apigee. По умолчанию маршрутизатор Apigee выдает ошибку через 57 секунд, поэтому рекомендуется установить время ожидания запроса на балансировщике нагрузки равным 60 секундам.

След

Диагностируйте ошибку с помощью трассировки.

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

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

    Вот пример трассировки пользовательского интерфейса, демонстрирующий ошибку "Gateway Timeout" после отправки запроса на целевой сервер:

Разрешение

  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 )
  • Системные журналы обработчика сообщений ( /opt/apigee/var/log/edge-message-processor/logs/system.log )