Apigee に関する既知の問題

cachehit フロー変数を LookupCache ポリシーの後に使用する場合、非同期動作でのデバッグ ポイントのディスパッチ方法により、LookupPolicy によってコールバックの実行前に DebugInfo オブジェクトにデータが入力されるため、エラーが発生します。

回避策: 最初の呼び出しの直後に、プロセスをもう一度繰り返します（2 回目の呼び出しを行います）。

InvalidateCache ポリシーで PurgeChildEntries を設定すると、KeyFragment 要素の値のみがパージされますが、キャッシュ全体がクリアされます。

回避策: KeyValueMapOperations ポリシーを使用してキャッシュ バージョニングを繰り返し、キャッシュ無効化の必要性を回避します。

• 仕様エディタを使用して仕様を作成し、ポータルで SmartDocs を使用して API を公開する場合、Apigee Edge は OpenAPI 仕様 3.0 をサポートしますが、一部の機能はまだサポートされていません。

  たとえば、OpenAPI 仕様 3.0 の次の機能は現時点ではサポートされていません。

  • スキーマの組み合わせと拡張用の allOf プロパティ
  • リモート参照

  サポートされていない機能が OpenAPI 仕様で参照されると、ツールはその機能を無視し、API リファレンス ドキュメントをレンダリングする場合があります。それ以外の場合、サポートされていない機能によってエラーが発生し、API リファレンス ドキュメントの正常なレンダリングができないようにします。いずれの場合も、今後のリリースでサポートされるまで、OpenAPI 仕様を変更して、サポートされていない機能の使用を避ける必要があります。

  注: API リファレンス ドキュメントのレンダリング時は、仕様エディタで SmartDocs よりも制限が緩いため、ツールによって結果が異なる場合があります。

• ポータルでこの API を試しに使用すると、OpenAPI 仕様の consumes に設定されている値に関係なく、Accept ヘッダーが application/json に設定されます。

• 現時点では、複数のユーザーによる同時のポータルの更新（ページ、テーマ、CSS、スクリプトの編集など）はサポートされていません。
• API リファレンス ドキュメントのページをポータルから削除した場合、再作成する方法はありません。API プロダクトを削除して再度追加し、API リファレンス ドキュメントを再生成する必要があります。
• コンテンツ セキュリティ ポリシーの設定時に、変更が完全に適用されるまでに最長で 15 分ほどかかる場合があります。
• ポータルのテーマをカスタマイズするときには、変更が完全に適用されるまで最大で 5 分かかることがあります。

• Google 検索は今後のリリースで統合ポータルに統合される予定です。

この問題の影響を受けるのは、Edge for Private Cloud インストールで MINT を使用しているユーザー、または MINT が有効になっているユーザーのみです。

影響を受けるコンポーネント: edge-message-processor

問題: 収益化を有効にしていて、4.52.01 を新規インストールとしてインストールする場合、または以前の Private Cloud バージョンからアップグレードする場合、Message Processor で問題が発生します。開いているスレッド数が徐々に増加し、リソースの枯渇につながります。Edge-message-processor system.log に、次の例外があります。

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread

先ごろ、複数の Google サービスで最近、サービス拒否攻撃（DoS）の脆弱性が発見されました。 HTTP/2 プロトコル（CVE-2023-44487）の実装が、Apigee Edge for プライベート クラウドこの脆弱性により、Apigee API 管理機能の DoS が発生する可能性があります。 詳しくは、Apigee のセキュリティに関する公開情報 GCP-2023-032 をご覧ください。

Edge for Private Cloud のルーターと管理サーバーのコンポーネントは、 脆弱になる可能性があります。管理ページで HTTP/2 は有効になっていますが、 Edge for Private Cloud のその他の Edge 固有のコンポーネントの 公開されません。Cassandra、Zookeeper などの Edge 以外のコンポーネントでは、 HTTP/2 が有効になっていません。こちらの Edge for Private Cloud の脆弱性に対処する手順は次のとおりです。

• Edge for Private Cloud バージョン 4.51.00.11 以降での手順
• 4.51.00.11 より古いバージョンの Edge for Private Cloud の手順

Edge Private Cloud バージョン 4.51.00.11 以降を使用している場合は、次の操作を行います。

1. 管理サーバーを更新します。

   1. 各 Management Server ノードで、/opt/apigee/customer/application/management-server.properties を開きます。
   2. 次の行をプロパティ ファイルに追加します。

      conf_webserver_http2.enabled=false

   3. Management Server コンポーネントを再起動します。

      apigee-service edge-management-server restart

2. Message Processor を更新します。

   1. 各 Message Processor ノードで /opt/apigee/customer/application/message-processor.properties を開きます。
   2. 次の行をプロパティ ファイルに追加します。

      conf_webserver_http2.enabled=false

   3. Message Processor コンポーネントを再起動します。

      apigee-service edge-message-processor restart

3. ルーターを更新します。

   1. 各ルーターノードで /opt/apigee/customer/application/router.properties を開きます。
   2. 次の行をプロパティ ファイルに追加します。

      conf_webserver_http2.enabled=false

   3. Message Processor コンポーネントを再起動します。

      apigee-service edge-router restart

4. QPID を更新します。

   1. 各 QPID ノードで /opt/apigee/customer/application/qpid-server.properties を開きます。
   2. 次の行をプロパティ ファイルに追加します。

      conf_webserver_http2.enabled=false

   3. Message Processor コンポーネントを再起動します。

      apigee-service edge-qpid-server restart

5. Postgres を更新します。

   1. 各 Postgres ノードで /opt/apigee/customer/application/postgres-server.properties を開きます。
   2. 次の行をプロパティ ファイルに追加します。

      conf_webserver_http2.enabled=false

   3. Message Processor コンポーネントを再起動します。

      apigee-service edge-postgres-server restart

4.51.00.11 より前のバージョンの Edge for Private Cloud を使用している場合は、次の操作を行います。

1. 管理サーバーを更新します。

   1. 各 Management Server ノードで、/opt/apigee/customer/application/management-server.properties を開きます。
   2. プロパティ ファイルに次の 2 行を追加します。

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Management Server コンポーネントを再起動します。

      apigee-service edge-management-server restart

2. Message Processor を更新します。

   1. 各 Message Processor ノードで /opt/apigee/customer/application/message-processor.properties を開きます。
   2. プロパティ ファイルに次の 2 行を追加します。

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Message Processor コンポーネントを再起動します。

      apigee-service edge-message-processor restart

3. ルーターを更新します。

   1. 各ルーターノードで /opt/apigee/customer/application/router.properties を開きます。
   2. プロパティ ファイルに次の 2 行を追加します。

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Message Processor コンポーネントを再起動します。

      apigee-service edge-router restart

4. QPID を更新します。

   1. 各 QPID ノードで /opt/apigee/customer/application/qpid-server.properties を開きます。
   2. プロパティ ファイルに次の 2 行を追加します。

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Message Processor コンポーネントを再起動します。

      apigee-service edge-qpid-server restart

5. Postgres を更新します。

   1. 各 Postgres ノードで /opt/apigee/customer/application/postgres-server.properties を開きます。
   2. プロパティ ファイルに次の 2 行を追加します。

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Message Processor コンポーネントを再起動します。

      apigee-service edge-postgres-server restart

Apigee-postgresql で Edge for Private Cloud からのアップグレードで問題が発生する 4.50 または 4.51 からバージョン 4.52 にアップグレードします。主な問題は テーブル数が 500 を超えるときに発生します。

以下の SQL クエリを実行すると、Postgres のテーブルの合計数を確認できます。

select count(*) from information_schema.tables

回避策: Apigee Edge 4.50.00 または 4.51.00 から 4.52.00 への更新、 忘れずに <ph type="x-smartling-placeholder"></ph> 準備手順を行ってから、Apigee-postgresql をアップグレードします。

apigee-mirror は Red Hat Enterprise Linux（RHEL）8.0 では機能しません。

回避策: 回避策として、下位バージョンを実行しているサーバーに apigee-mirror をインストールします。 他の RHEL アプリケーションや、 サポート オペレーティング システムです。その後、ミラーを使用して Apigee を RHEL 8.0 サーバーにインストールしている場合でも、パッケージを追加できます。

149245401: LDAP リソース 反映されず、JNDI のデフォルトにより、毎回 1 回限りの接続が発生します。 その結果、新しい ReplicaSet の 使用して 1 回しか使用できないため、 LDAP サーバーへの 1 時間あたりの接続数。

回避策:

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 は 管理する必要があります。
4. 各 Message Processor を再起動します。

接続プールの JNDI が 設定が有効である場合は、 tcpdump を実行して、LDAP 接続プールの動作を確認する 学習します。

139051927: Message Processor でプロキシ処理のレイテンシが高い。 影響しています 許可します。症状として、処理時間が通常より 200 ～ 300 ミリ秒遅れる API レスポンス 低い TPS でもランダムに発生する可能性があります。これは、ターゲットが 50 個を超える場合に発生することがあります。 Message Processor が接続を行うサーバー。

根本原因: Message Processor は、ターゲット サーバーの URL を HTTPClient オブジェクトに ターゲットサーバーへの送信接続数を定義します。デフォルトでは 50 に設定されていますが、 ほとんどのデプロイで低すぎます。Deployment の設定に複数の組織/環境の組み合わせがある場合は、 ターゲット サーバーの数が合計で 50 を超える場合、そのターゲット サーバーの URL は 継続的にキャッシュから削除され レイテンシの原因となっています

検証: ターゲット サーバーの URL エビクションがレイテンシの問題を引き起こしているかどうかを判断するには、 Message Processor の system.logs キーワード「onEvict」の場合「エビクション」です。ログにこれらの情報が存在する場合は、ターゲット サーバーの 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

次に、Message Processor を再起動します。すべての Message Processor に同じ変更を加えます。

500 は一例です。設定に最適な値は次の値より大きい必要があります Message Processor が接続するターゲット サーバーの数。何も面がない の効果を このプロパティを高く設定すると、Message Processor の改善のみが影響を受けます プロキシ リクエストの処理時間。

注: Edge for Private Cloud バージョン 50.00 のデフォルトの設定は 500 です。

157933959: スコープが同一の Key-Value マップ（KVM）の 組織レベルまたは環境レベルでは、データの不整合や更新の損失が発生します。

注: この制限は Edge for Private Cloud にのみ適用されます。Edge for Public Cloud ハイブリッドにはこの制限はありません。

Edge for Private Cloud で回避策として、KVM を apiproxy スコープ。