503 Сервис недоступен

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

Видео

Для получения дополнительной информации об ошибках 503 смотрите следующие видеоролики:

Симптом

После вызова API-прокси клиентское приложение получает HTTP-ответ со статусом 503 и сообщением "Сервис недоступен" .

Сообщения об ошибках

Вы можете увидеть следующее сообщение об ошибке:

HTTP/1.1 503 Service Unavailable
      

В HTTP-ответе также может отображаться следующее сообщение об ошибке:

Сервис недоступен

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.ServiceUnavailable"
       }
    }
}
      

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

HTTP-ответ 503 Service Unavailable с кодом ошибки messaging.adaptors.http.flow.ServiceUnavailable возникает, если обработчик сообщений Apigee Edge испытывает ошибки из-за истечения времени ожидания соединения, неверного имени хоста или сбоев SSL-рукопожатия при обмене данными с бэкэнд-сервером.

Возможные причины ошибки 503 Service Unavailable :

Общие этапы диагностики

Определите идентификатор сообщения (Message ID) запроса, завершившегося с ошибкой.

Ошибки подключения из-за некорректного разрешения DNS.

Диагноз

1. Определите идентификатор сообщения, в котором запрос завершился с ошибкой.
2. Найдите идентификатор конкретного сообщения запроса в журнале обработчика сообщений ( /opt/apigee/var/log/edge-message-processor/logs/system.log ). Вы можете увидеть следующие ошибки:
   
   Ошибка onConnectTimeout указывает на то, что обработчик сообщений не смог подключиться к серверной части в течение заданного периода ожидания соединения (по умолчанию: 3 секунды).

   2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[Connected:]@164162 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11  resolvedAddress=www.abc.com/22.22.22.22
   
   2019-08-14 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)
         

3. Обратите внимание на полученный IP-адрес в сообщении об ошибке onConnectTimeout и проверьте, действителен ли этот IP-адрес для вашего бэкэнд-сервера. Если IP-адрес действителен, перейдите в раздел «Ошибки подключения» .
4. Если IP-адрес недействителен, то, скорее всего, это связано с проблемами разрешения DNS-запросов.
5. Повторите шаги 3 и 4 для нескольких других неудачных запросов к API и проверьте, видите ли вы те же или какие-либо другие недействительные IP-адреса.
6. Просмотрите журнал обработчика сообщений ( /opt/apigee/var/log/edge-message-processor/logs/system.log ) на наличие сообщений, содержащих ключевое слово DNS Refresh . Периодически проверяйте, не добавляются ли в кэш DNS обработчика сообщений некорректные или недействительные IP-адреса.

   2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 INFO c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.reportDifferences() : DNS Refresh for host: apitarget-uat.schemeweb.co.uk:4436. Added 2 IPs [www.abc.com/22.22.22.22, www.abc.com/33.33.33.33] Removed 1 IPs [www.abc.com/11.11.11.11]
         

7. Эта проблема может возникнуть, если есть какие-либо неполадки с авторитетными DNS-серверами или серверами имен, настроенными в файле /etc/resolv.conf .
   
   Как правило, для разрешения DNS-имен может быть настроен один или несколько авторитетных DNS-серверов. Если авторитетных DNS-серверов нет, то будет использоваться конфигурация, заданная в файле /etc/resolv.conf , и разрешение DNS-имен будет выполняться соответствующим образом. Например: если в файле /etc/resolv.conf указано использование определенных серверов имен, то для разрешения DNS-имен будут использоваться именно эти серверы имен.
8. Если возникнут какие-либо проблемы с авторитетными DNS-серверами или серверами имен, указанными в файле /etc/resolv.conf , то имена хостов бэкэнд-серверов будут преобразованы в некорректные/недействительные IP-адреса. Некорректные/недействительные IP-адреса затем будут сохранены в кэше DNS обработчика сообщений.
   1. Если проблема с авторитетными DNS-серверами или серверами имен, указанными в файле /etc/resolv.conf сохраняется, то некорректные/недействительные IP-адреса будут продолжать оставаться в кэше DNS обработчика сообщений. Пока некорректные IP-адреса хранятся в кэше DNS обработчика сообщений, запросы ко всем этим API, использующим конкретный бэкэнд-сервер, будут завершаться ошибкой 503.
   2. Если проблемы с авторитетными DNS-серверами или серверами имен, указанными в файле /etc/resolv.conf носят периодический характер, то в кэше DNS будут периодически сохраняться как корректные, так и некорректные IP-адреса. В этом случае вы будете периодически видеть ошибки 503 для всех API, использующих данный бэкэнд-сервер.
9. Если проблема с DNS-серверами постоянная, то вы будете наблюдать непрерывные сбои. Если проблема с DNS-серверами периодическая, то вы будете наблюдать периодические сбои. То есть, всякий раз, когда имя хоста бэкэнд-сервера преобразуется в некорректный IP-адрес, вы будете наблюдать ошибки 503. А когда имена хостов бэкэнд-сервера преобразуются в корректные IP-адреса, вы будете наблюдать успешные ответы.

Разрешение

Пожалуйста, обратитесь к администратору вашей операционной системы и устраните проблемы с DNS-серверами.

1. Если возникла проблема с вашими авторитетными DNS-серверами или серверами имен, указанными в файле /etc/resolv.conf , устраните проблему на соответствующем сервере.
2. Если на системах с обработчиками сообщений обнаружены какие-либо проблемы с конфигурацией в файле /etc/resolv.conf , устраните эти проблемы.

Ошибки подключения

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

• Обработчик сообщений не может установить соединение в течение заданного времени ожидания (по умолчанию: 3 секунды).
• Серверная часть отклоняет соединение.

Диагноз

1. Определите идентификатор сообщения, в котором запрос завершился с ошибкой.
2. Найдите идентификатор конкретного сообщения запроса в журнале обработчика сообщений ( /opt/apigee/var/log/edge-message-processor/logs/system.log ). Вы можете увидеть следующие ошибки:
   1. Ошибка onConnectTimeout указывает на то, что обработчик сообщений не смог подключиться к серверной части в течение заданного периода ожидания соединения.

      2016-06-23 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@10 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11:80 resolvedAddress=www.abc.com/11.11.11.11
      2016-06-23 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)

   2. Ошибка java.net.ConnectException: Connection refused указывает на то, что соединение было отклонено серверной частью.

      14:40:16.531 +0530
      2016-06-17 09:10:16,531 org:myorg env:prod api:www.abc.com rev:1 rrt07eadn-22739-40983870-15 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() : connect to www.abc.com:11.11.11.11:443 failed with exception {}
      java.net.ConnectException: Connection refused
      at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[na:1.7.0_75]
      at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739) ~[na:1.7.0_75]
      at com.apigee.nio.ClientChannel.finishConnect(ClientChannel.java:121) ~[nio-1.0.0.jar:na]
      at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:108) ~[nio-1.0.0.jar:na]

3. Проверьте, можете ли вы подключиться к конкретному серверу бэкэнда напрямую из каждого из обработчиков сообщений, используя команду telnet :
   1. Если серверная часть выдает один IP-адрес, используйте следующую команду:

      telnet BackendServer-IPaddress 443
                

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

      telnet BackendServer-HostName 443
                

4. Если вам удаётся подключиться к бэкэнд-серверу, вы можете увидеть сообщение типа « Connected to backend-server . Если же подключение к бэкэнд-серверу не удаётся, это может быть связано с тем, что IP-адреса обработчиков сообщений не внесены в список разрешенных адресов на данном бэкэнд-сервере.

Разрешение

Предоставьте доступ к IP-адресам обработчиков сообщений на конкретном бэкэнд-сервере, чтобы разрешить трафик от пограничных обработчиков сообщений к вашему бэкэнд-серверу. Например, в Linux вы можете использовать iptables для разрешения трафика с IP-адресов обработчиков сообщений на бэкэнд-сервере.

Если проблема сохраняется, обратитесь к сетевому администратору для выявления и устранения неисправности. Если вам потребуется дополнительная помощь от Apigee, свяжитесь со службой поддержки Apigee .

Неверное имя хоста целевого сервера.

Диагноз

Если имя хоста, указанное на целевом сервере, неверно, вы можете получить ответ 503 Service Unavailable с кодом ошибки messaging.adaptors.http.flow.ServiceUnavailable.

Разрешение

1. Убедитесь, что имя хоста целевого сервера, указанное в конфигурации целевой конечной точки или в определении целевого сервера , является правильным и не содержит лишних пробелов или специальных символов.
2. Если вы используете политику AssignMessage/JavaScript для динамической генерации имени хоста целевого сервера, изучите определение политики и код и убедитесь, что имя хоста целевого сервера генерируется корректно.

Сбои при установлении SSL-соединения

Целый сборник инструкций по устранению неполадок посвящен ошибкам установления соединения TLS/SSL. См. раздел «Ошибки установления соединения SSL» .

Определение источника проблемы

Определенные типы ошибок могут возникать как на входящем (северном), так и на исходящем (южном) соединении. Ошибка на входящем (северном) соединении возникает между клиентским приложением и Edge. Ошибка на исходящем (южном) соединении возникает между Edge и целевым сервером. Для диагностики подобных проблем в первую очередь необходимо определить, на каком из соединений возникает ошибка — на северном или южном.

Понимание маршрутов в северном и южном направлениях

В Edge вы можете столкнуться с ошибкой 503 Service Unavailable как при входящем, так и при исходящем соединении:

• Входящее (или северное) соединение — это соединение между клиентским приложением и пограничным маршрутизатором. Маршрутизатор — это компонент Apigee Edge, который обрабатывает входящие запросы к системе.
• Исходящее (или южное) соединение — это соединение между обработчиком сообщений Edge и бэкэнд-сервером. Обработчик сообщений является компонентом Apigee Edge, который перенаправляет API-запросы на целевые бэкэнд-серверы.

Если вы являетесь пользователем Edge Public Cloud, вы, вероятно, не знаете о внутренних компонентах, таких как маршрутизатор или обработчик сообщений. Эти внутренние компоненты не видны и недоступны пользователям Public Cloud. По возможности мы предлагаем альтернативные способы исследования проблемы, не требующие прямого доступа к этим компонентам.

На следующем рисунке показаны варианты пересадок в направлении севера и юга для района Апигее-Эдж.

Определение места возникновения ошибки 503 «Сервис недоступен»

Для определения того, произошла ли ошибка 503 Service Unavailable на северном или южном направлении, воспользуйтесь одной из следующих процедур.