Известные проблемы с Apigee

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

В следующих разделах описаны известные проблемы Apigee. В большинстве случаев перечисленные проблемы будут исправлены в будущих выпусках.

Разное Известные проблемы Edge

В следующих разделах описаны различные известные проблемы с Edge.

Область Известные вопросы
Срок действия кэша приводит к неправильному значению cachehit

Когда переменная потока cachehit используется после политики LookupCache, из-за способа отправки точек отладки для асинхронного поведения LookupPolicy заполняет объект DebugInfo до выполнения обратного вызова, что приводит к ошибке.

Обходной путь: повторите процесс (сделайте второй звонок) еще раз сразу после первого звонка.

Установка для политики InvalidateCache PurgeChildEntries значения true работает неправильно.

Установка PurgeChildEntries в политике InvalidateCache должна очищать только значения элемента KeyFragment , но очищает весь кеш.

Обходной путь: используйте политику KeyValueMapOperations , чтобы итерировать управление версиями кэша и обойти необходимость аннулирования кэша.

Известные проблемы с пользовательским интерфейсом Edge

В следующих разделах описаны известные проблемы с пользовательским интерфейсом Edge.

Область Известные вопросы
Невозможно получить доступ к странице администрирования зоны Edge SSO из панели навигации после того, как организация сопоставлена ​​с зоной идентификации. Когда вы подключаете организацию к зоне идентификации , вы больше не можете получить доступ к странице администрирования зоны Edge SSO с левой панели навигации, выбрав «Администратор» > «Единый вход». В качестве обходного пути перейдите на страницу напрямую, используя следующий URL-адрес: https://apigee.com/sso.

Известные проблемы с интегрированным порталом

В следующих разделах описаны известные проблемы интегрированного портала.

Область Известные вопросы
СмартДокс
  • Apigee Edge поддерживает спецификацию OpenAPI 3.0, когда вы создаете спецификации с помощью редактора спецификаций и публикуете API с помощью SmartDocs на своем портале, хотя подмножество функций еще не поддерживается.

    Например, следующие функции спецификации OpenAPI 3.0 пока не поддерживаются:

    • allOf свойства для объединения и расширения схем
    • Удаленные ссылки

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

    Примечание . Поскольку редактор спецификаций менее строгий, чем SmartDocs, при отображении справочной документации API, вы можете получить разные результаты при использовании разных инструментов.

  • При использовании «Попробуйте этот API» на портале для заголовка Accept устанавливается значение application/json независимо от значения, установленного для consumes в спецификации OpenAPI.
Поставщик удостоверений SAML Единый выход из системы (SLO) с помощью поставщика удостоверений SAML не поддерживается для личных доменов. Чтобы включить личный домен с поставщиком удостоверений SAML, оставьте поле URL-адрес выхода пустым при настройке параметров SAML .
Администратор портала
  • Одновременное обновление портала (например, редактирование страниц, тем, CSS или сценариев) несколькими пользователями в настоящее время не поддерживается.
  • Если вы удалите страницу справочной документации API с портала, восстановить ее будет невозможно; вам потребуется удалить и заново добавить продукт API, а также заново создать справочную документацию по API.
  • При настройке политики безопасности контента для полного применения изменений может потребоваться до 15 минут.
  • При настройке темы портала для полного применения изменений может потребоваться до 5 минут.
Возможности портала
  • Поиск будет интегрирован в интегрированный портал в будущей версии.

Известные проблемы с Edge для частного облака

В следующих разделах описаны известные проблемы с Edge для частного облака.

Область Известные проблемы
OPDK 4.52.01 Mint Обновление

Эта проблема затрагивает только тех, кто использует MINT или включил MINT в установках Edge для частного облака.

Затронутый компонент: Edge-message-processor

Проблема. Если у вас включена монетизация и вы устанавливаете версию 4.52.01 заново или обновляете предыдущие версии Private Cloud, вы столкнетесь с проблемой с обработчиками сообщений. Будет постепенно увеличиваться количество открытых потоков, что приведет к истощению ресурсов. В system.log Edge-message-processor наблюдается следующее исключение:

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread
Уязвимость Apigee HTTP/2

Уязвимость типа «отказ в обслуживании» (DoS) недавно была обнаружена в нескольких реализациях протокола HTTP/2 (CVE-2023-44487), в том числе в Apigee Edge для частного облака. Уязвимость может привести к DoS-атаким функциям управления API Apigee. Дополнительные сведения см. в бюллетене по безопасности Apigee GCP-2023-032 .

Компоненты маршрутизатора Edge for Private Cloud и сервера управления доступны из Интернета и потенциально могут быть уязвимы. Хотя HTTP/2 включен на порту управления других компонентов Edge для частного облака, специфичных для Edge, ни один из этих компонентов не доступен из Интернета. В компонентах, отличных от Edge, таких как Cassandra, Zookeeper и других, HTTP/2 не включен. Мы рекомендуем вам предпринять следующие шаги для устранения уязвимости Edge for Private Cloud:

Выполните следующие действия, если вы используете Edge Private Cloud версии 4.51.00.11 или новее:

  1. Обновите сервер управления:

    1. На каждом узле сервера управления откройте /opt/apigee/customer/application/management-server.properties
    2. Добавьте эту строку в файл свойств: 
      conf_webserver_http2.enabled=false
    3. Перезапустите компонент сервера управления: 
      apigee-service edge-management-server restart

  2. Обновите обработчик сообщений:

    1. На каждом узле процессора сообщений откройте /opt/apigee/customer/application/message-processor.properties
    2. Добавьте эту строку в файл свойств: 
      conf_webserver_http2.enabled=false
    3. Перезапустите компонент процессора сообщений: 
      apigee-service edge-message-processor restart

  3. Обновите роутер:

    1. На каждом узле маршрутизатора откройте /opt/apigee/customer/application/router.properties
    2. Добавьте эту строку в файл свойств: 
      conf_webserver_http2.enabled=false
    3. Перезапустите компонент процессора сообщений: 
      apigee-service edge-router restart

  4. Обновить QPID:

    1. На каждом узле QPID откройте /opt/apigee/customer/application/qpid-server.properties
    2. Добавьте эту строку в файл свойств: 
      conf_webserver_http2.enabled=false
    3. Перезапустите компонент процессора сообщений: 
      apigee-service edge-qpid-server restart

  5. Обновить Постгрес:

    1. На каждом узле Postgres откройте /opt/apigee/customer/application/postgres-server.properties .
    2. Добавьте эту строку в файл свойств: 
      conf_webserver_http2.enabled=false
    3. Перезапустите компонент процессора сообщений: 
      apigee-service edge-postgres-server restart

Выполните следующие действия, если вы используете версии Edge для частного облака старше 4.51.00.11:

  1. Обновите сервер управления:

    1. На каждом узле сервера управления откройте /opt/apigee/customer/application/management-server.properties
    2. Добавьте следующие две строки в файл свойств: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. Перезапустите компонент сервера управления: 
      apigee-service edge-management-server restart

  2. Обновите обработчик сообщений:

    1. На каждом узле процессора сообщений откройте /opt/apigee/customer/application/message-processor.properties
    2. Добавьте следующие две строки в файл свойств: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. Перезапустите компонент процессора сообщений: 
      apigee-service edge-message-processor restart

  3. Обновите роутер:

    1. На каждом узле маршрутизатора откройте /opt/apigee/customer/application/router.properties
    2. Добавьте следующие две строки в файл свойств: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. Перезапустите компонент процессора сообщений: 
      apigee-service edge-router restart

  4. Обновить QPID:

    1. На каждом узле QPID откройте /opt/apigee/customer/application/qpid-server.properties
    2. Добавьте следующие две строки в файл свойств: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. Перезапустите компонент процессора сообщений: 
      apigee-service edge-qpid-server restart

  5. Обновить Постгрес:

    1. На каждом узле Postgres откройте /opt/apigee/customer/application/postgres-server.properties .
    2. Добавьте следующие две строки в файл свойств: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. Перезапустите компонент процессора сообщений: 
      apigee-service edge-postgres-server restart
Обновление Postgresql при обновлении до версии 4.52

У Apigee-postgresql возникли проблемы с обновлением Edge for Private Cloud версии 4.50 или 4.51 до версии 4.52. Проблемы в основном возникают, когда количество таблиц превышает 500.

Вы можете проверить общее количество таблиц в Postgres, выполнив SQL-запрос ниже: 

select count(*) from information_schema.tables

Обходной путь: при обновлении Apigee Edge 4.50.00 или 4.51.00 до 4.52.00 обязательно выполните предварительный шаг перед обновлением Apigee-postgresql.

apigee-mirror на RHEL 8.0

apigee-mirror не работает в Red Hat Enterprise Linux (RHEL) 8.0.

Обходной путь: в качестве обходного пути установите apigee-mirror на сервер с более ранней версией RHEL или другой поддерживаемой операционной системой для Apigee. Затем вы можете использовать зеркало для добавления пакетов, даже если вы установили Apigee на серверах RHEL 8.0.

Политика LDAP

149245401: настройки пула соединений LDAP для JNDI, настроенные через ресурс LDAP, не отражаются, а значения по умолчанию JNDI каждый раз вызывают одноразовые соединения. В результате соединения каждый раз открываются и закрываются для одноразового использования, создавая большое количество подключений к серверу LDAP в час.

Обходной путь:

Чтобы изменить свойства пула соединений LDAP, выполните следующие шаги, чтобы установить глобальное изменение для всех политик LDAP.

  1. Создайте файл свойств конфигурации, если он еще не существует: 
    /opt/apigee/customer/application/message-processor.properties
  2. Добавьте в файл следующее (замените значения свойств Java Naming and Directory Interface (JNDI) в соответствии с требованиями к конфигурации ресурсов LDAP). 
    bin_setenv_ext_jvm_opts="-Dcom.sun.jndi.ldap.connect.pool.maxsize=20
-Dcom.sun.jndi.ldap.connect.pool.prefsize=2
-Dcom.sun.jndi.ldap.connect.pool.initsize=2
-Dcom.sun.jndi.ldap.connect.pool.timeout=120000
-Dcom.sun.jndi.ldap.connect.pool.protocol=ssl"
  3. Убедитесь, что файл /opt/apigee/customer/application/message-processor.properties принадлежит apigee:apigee.
  4. Перезапустите каждый процессор сообщений.

Чтобы убедиться, что свойства JNDI вашего пула соединений вступили в силу, вы можете выполнить tcpdump, чтобы наблюдать за поведением пула соединений LDAP с течением времени.

Высокая задержка обработки запроса

139051927: Высокие задержки обработки прокси-сервера, обнаруженные в процессоре сообщений, влияют на все прокси-серверы API. Симптомы включают задержки обработки на 200–300 мс по сравнению с обычным временем ответа API и могут возникать случайным образом даже при низком TPS. Это может произойти, если имеется более 50 целевых серверов, к которым процессор сообщений устанавливает соединения.

Основная причина: процессоры сообщений хранят кэш, который сопоставляет URL-адрес целевого сервера с объектом HTTPClient для исходящих подключений к целевым серверам. По умолчанию для этого параметра установлено значение 50, что может оказаться слишком низким для большинства развертываний. Если в развертывании имеется несколько комбинаций org/env и большое количество целевых серверов, общее число которых превышает 50, URL-адреса целевых серверов продолжают удаляться из кэша, что приводит к задержкам.

Проверка. Чтобы определить, является ли вытеснение URL-адреса целевого сервера причиной проблемы с задержкой, найдите в системных журналах процессора сообщений ключевое слово «onEvict» или «Eviction». Их присутствие в журналах указывает на то, что URL-адреса целевого сервера исключаются из кэша HTTPClient, поскольку размер кэша слишком мал.

Обходной путь: для Edge for Private Cloud версий 19.01 и 19.06 вы можете редактировать и настраивать кэш HTTPClient, /opt/apigee/customer/application/message-processor.properties : 

conf/http.properties+HTTPClient.dynamic.cache.elements.size=500

Затем перезапустите обработчик сообщений. Внесите одинаковые изменения для всех обработчиков сообщений.

Значение 500 является примером. Оптимальное значение для вашей настройки должно быть больше, чем количество целевых серверов, к которым будет подключаться процессор сообщений. Установка более высокого значения этого свойства не приводит к побочным эффектам, и единственное влияние будет заключаться в уменьшении времени обработки запросов прокси-сервера процессора сообщений.

Примечание. Edge для частного облака версии 50.00 имеет настройку по умолчанию — 500.

Множественные записи для карт значений ключа

157933959: одновременные вставки и обновления одной и той же карты значений ключей (KVM), ограниченной уровнем организации или среды, приводят к противоречивым данным и потере обновлений.

Примечание. Это ограничение применимо только к Edge для частного облака. Edge для публичного облака и гибрида не имеют этого ограничения.

В качестве обходного пути в Edge для частного облака создайте KVM в области apiproxy .