Bekannte Probleme mit Apigee

Wenn die Ablaufvariable cachehit nach der LookupCache-Richtlinie verwendet wird, füllt die LookupPolicy das DebugInfo-Objekt aufgrund der Art und Weise, wie Debugpunkte für das asynchrone Verhalten gesendet werden, aus, bevor der Rückruf ausgeführt wurde. Dies führt zu einem Fehler.

Problemumgehung:Wiederholen Sie den Vorgang (führen Sie einen zweiten Anruf aus) direkt nach dem ersten Anruf.

Wenn Sie PurgeChildEntries in der InvalidateCache-Richtlinie festlegen, sollten nur die Werte des KeyFragment-Elements gelöscht werden. Stattdessen wird jedoch der gesamte Cache geleert.

Umgehung:Verwenden Sie die KeyValueMapOperations-Richtlinie, um die Cache-Versionierung zu iterieren und die Cache-Entwertung zu umgehen.

Dies kann beispielsweise der Fall sein, wenn eine CI/CD-Bereitstellungspipeline gleichzeitig mit verschiedenen Überarbeitungen ausgeführt wird. Um dieses Problem zu vermeiden, sollten Sie keine API-Proxys oder SharedFlows bereitstellen, bevor die aktuelle Bereitstellung abgeschlossen ist.

Problemumgehung:Vermeiden Sie gleichzeitige API-Proxy- oder SharedFlow-Bereitstellungen.

Edge API Analytics kann manchmal doppelte Daten für API-Aufrufe enthalten. In diesem Fall sind die in Edge API Analytics für API-Aufrufe angezeigten Werte höher als die vergleichbaren Werte in Analysetools von Drittanbietern.

Umgehung: Exportieren Sie die Analysedaten und verwenden Sie das Feld gateway_flow_id, um die Daten zu deduplizieren.

• Apigee Edge unterstützt OpenAPI-Spezifikation 3.0, wenn Sie Spezifikationen mit dem Spezifikationseditor erstellen und APIs mit SmartDocs auf Ihrem Portal veröffentlichen. Eine Teilmenge der Funktionen wird jedoch noch nicht unterstützt.

  Die folgenden Features aus der OpenAPI-Spezifikation 3.0 werden beispielsweise noch nicht unterstützt:

  • allOf-Attribute zum Kombinieren und Erweitern von Schemas
  • Remote-Referenzen

  Wenn in Ihrer OpenAPI-Spezifikation auf eine nicht unterstützte Funktion verwiesen wird, ignorieren die Tools die Funktion in einigen Fällen, rendern aber trotzdem die API-Referenzdokumentation. In anderen Fällen führt eine nicht unterstützte Funktion zu Fehlern, die das erfolgreiche Rendern der API-Referenzdokumentation verhindern. In beiden Fällen müssen Sie Ihre OpenAPI-Spezifikation ändern, um die Verwendung der nicht unterstützten Funktion zu verhindern, bis sie in einer zukünftigen Version unterstützt wird.

  Hinweis: Da der Spezifikationseditor beim Rendern von API-Referenzdokumenten weniger restriktiv ist als SmartDocs, können die Ergebnisse zwischen den Tools unterschiedlich ausfallen.

• Wenn Sie diese API im Portal testen, wird der Accept-Header auf application/json gesetzt, unabhängig von dem für consumes in der OpenAPI-Spezifikation festgelegten Werts.
• 138438484: Mehrere Server werden nicht unterstützt.

• Gleichzeitige Aktualisierung von Portalen (z. B. Seite, Design, CSS oder Skriptänderungen) wird von mehreren Nutzern derzeit nicht unterstützt.
• Wenn Sie eine API-Referenzdokumentationsseite aus dem Portal löschen, gibt es keine Möglichkeit, sie neu zu erstellen; Sie müssen das API-Produkt löschen und neu hinzufügen und die API-Referenzdokumentation neu generieren.
• Wenn Sie die Content Security Policy konfigurieren, kann es bis zu 15 Minuten dauern, bis die Änderungen vollständig übernommen werden.
• Bei der Anpassung des Portaldesign kann es bis zu 5 Minuten dauern, bis die Änderungen vollständig übernommen werden.

• Die Suche wird in einer zukünftigen Version in das integrierte Portal integriert.

Kundenspezifische Java-Callouts, die versuchen, den Bouncy Castle-Kryptografieanbieter mit dem Namen „BC“ zu laden, schlagen möglicherweise fehl, da der Standardanbieter zur Unterstützung von FIPS in Bouncy Castle FIPS geändert wurde. Der neue Name des Anbieters lautet „BCFIPS“.

Die Komponenten edge-message-processor oder edge-router können beim Starten zeitweise einen oder mehrere Keystores nicht laden. Dies führt zu Traffic-Fehlern, wenn der Keystore von einem API-Proxy oder in einem virtuellen Host verwendet wird.

So können Sie das Problem beheben:

1. Fügen Sie in einem Nachrichtenverarbeitungsknoten die Datei $APIGEE_ROOT/customer/application/message-processor.properties hinzu oder bearbeiten Sie sie.
2. Property conf_deployment_bootstrap.executor.thread.count=1 hinzufügen
3. Speichern Sie die Datei und achten Sie darauf, dass sie lesbar ist und dem Apigee-Nutzer chown apigee:apigee $APIGEE_ROOT/customer/application/message-processor.properties gehört.
4. Starten Sie den Message Processor-Dienst apigee-service edge-message-processor restart neu.
5. Wiederholen Sie die oben genannten Schritte für jeden Nachrichtenprozessorknoten einzeln.
6. Fügen Sie in einem Routerknoten die Datei $APIGEE_ROOT/customer/application/router.properties hinzu oder bearbeiten Sie sie.
7. Property conf_deployment_bootstrap.executor.thread.count=1 hinzufügen
8. Speichern Sie die Datei und achten Sie darauf, dass sie lesbar ist und dem Apigee-Nutzer chown apigee:apigee $APIGEE_ROOT/customer/application/router.properties gehört.
9. Starte den Routerdienst apigee-service edge-router restart neu.
10. Wiederhole die obigen Schritte für jeden Routerknoten einzeln.

Kundenspezifische Java-Callouts, die versuchen, den Bouncy Castle-Kryptografieanbieter mit dem Namen „BC“ zu laden, schlagen möglicherweise fehl, da der Standardanbieter zur Unterstützung von FIPS in Bouncy Castle FIPS geändert wurde. Der neue Name des Anbieters lautet „BCFIPS“.

Dieses Problem betrifft nur Nutzer, die MINT verwenden oder MINT in Edge für Private Cloud-Installationen aktiviert haben.

Betroffene Komponente:edge-message-processor

Problem:Wenn Sie die Monetarisierung aktiviert haben und Version 4.52.01 als Neuinstallation installieren oder ein Upgrade von früheren Private Cloud-Versionen durchführen, tritt ein Problem mit Message-Prozessoren auf. Die Anzahl der offenen Threads steigt allmählich an, was zu einer Erschöpfung der Ressourcen führt. Die folgende Ausnahme wird in „edge-message-processor system.log“ angezeigt:

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

Vor Kurzem wurde in mehreren Implementierungen des HTTP/2-Protokolls (CVE-2023-44487) eine DoS-Sicherheitslücke (Denial of Service) festgestellt, darunter auch in Apigee Edge for Private Cloud. Die Sicherheitslücke könnte zu einem DoS der Apigee API-Verwaltungsfunktionen führen. Weitere Informationen finden Sie im Apigee-Sicherheitsbulletin GCP-2023-032.

Die Komponenten des Routers und Verwaltungsservers von Edge for Private Cloud sind über das Internet zugänglich und können anfällig sein. Obwohl HTTP/2 auf dem Verwaltungsport anderer Edge-spezifischer Komponenten von Edge for Private Cloud aktiviert ist, ist keine dieser Komponenten im Internet zugänglich. Auf Nicht-Edge-Komponenten wie Cassandra, Zookeeper und anderen ist HTTP/2 nicht aktiviert. Wir empfehlen, die folgenden Schritte auszuführen, um die Sicherheitslücke von Edge for Private Cloud zu beheben:

• Schritte für Edge for Private Cloud-Versionen 4.51.00.11 oder höher
• Schritte für Edge for Private Cloud-Versionen vor 4.51.00.11

Führen Sie diese Schritte aus, wenn Sie Edge Private Cloud-Version 4.51.00.11 oder höher verwenden:

1. Verwaltungsserver aktualisieren:

   1. Öffnen Sie auf jedem Verwaltungsserverknoten /opt/apigee/customer/application/management-server.properties.
   2. Fügen Sie der Datei mit den Eigenschaften die folgende Zeile hinzu:

      conf_webserver_http2.enabled=false

   3. Starten Sie die Verwaltungsserverkomponente neu:

      apigee-service edge-management-server restart

2. Nachrichtenprozessor aktualisieren:

   1. Öffnen Sie auf jedem Nachrichtenprozessorknoten /opt/apigee/customer/application/message-processor.properties.
   2. Fügen Sie der Datei mit den Eigenschaften die folgende Zeile hinzu:

      conf_webserver_http2.enabled=false

   3. Starten Sie die Message Processor-Komponente neu:

      apigee-service edge-message-processor restart

3. Router aktualisieren:

   1. Öffnen Sie auf jedem Routerknoten /opt/apigee/customer/application/router.properties.
   2. Fügen Sie der Datei mit den Eigenschaften die folgende Zeile hinzu:

      conf_webserver_http2.enabled=false

   3. Starten Sie die Message Processor-Komponente neu:

      apigee-service edge-router restart

4. QPID aktualisieren:

   1. Öffnen Sie auf jedem QPID-Knoten /opt/apigee/customer/application/qpid-server.properties
   2. Fügen Sie der Datei mit den Eigenschaften die folgende Zeile hinzu:

      conf_webserver_http2.enabled=false

   3. Starten Sie die Message Processor-Komponente neu:

      apigee-service edge-qpid-server restart

5. Postgres aktualisieren:

   1. Öffnen Sie auf jedem Postgres-Knoten /opt/apigee/customer/application/postgres-server.properties
   2. Fügen Sie der Datei mit den Eigenschaften die folgende Zeile hinzu:

      conf_webserver_http2.enabled=false

   3. Starten Sie die Message Processor-Komponente neu:

      apigee-service edge-postgres-server restart

Führen Sie diese Schritte aus, wenn Sie Edge for Private Cloud-Versionen vor 4.51.00.11 verwenden:

1. Verwaltungsserver aktualisieren:

   1. Öffnen Sie auf jedem Verwaltungsserverknoten /opt/apigee/customer/application/management-server.properties.
   2. Fügen Sie der Datei mit den Eigenschaften die folgenden zwei Zeilen hinzu:

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

   3. Starten Sie die Verwaltungsserverkomponente neu:

      apigee-service edge-management-server restart

2. Nachrichtenprozessor aktualisieren:

   1. Öffnen Sie auf jedem Nachrichtenprozessorknoten /opt/apigee/customer/application/message-processor.properties.
   2. Fügen Sie der Datei mit den Eigenschaften die folgenden zwei Zeilen hinzu:

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

   3. Starten Sie die Message Processor-Komponente neu:

      apigee-service edge-message-processor restart

3. Router aktualisieren:

   1. Öffnen Sie auf jedem Routerknoten /opt/apigee/customer/application/router.properties.
   2. Fügen Sie der Datei mit den Eigenschaften die folgenden zwei Zeilen hinzu:

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

   3. Starten Sie die Message Processor-Komponente neu:

      apigee-service edge-router restart

4. QPID aktualisieren:

   1. Öffnen Sie auf jedem QPID-Knoten /opt/apigee/customer/application/qpid-server.properties
   2. Fügen Sie der Datei mit den Eigenschaften die folgenden zwei Zeilen hinzu:

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

   3. Starten Sie die Message Processor-Komponente neu:

      apigee-service edge-qpid-server restart

5. Postgres aktualisieren:

   1. Öffnen Sie auf jedem Postgres-Knoten /opt/apigee/customer/application/postgres-server.properties
   2. Fügen Sie der Datei mit den Eigenschaften die folgenden zwei Zeilen hinzu:

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

   3. Starten Sie die Message Processor-Komponente neu:

      apigee-service edge-postgres-server restart

Bei Apigee-postgresql treten Probleme beim Upgrade von Edge for Private Cloud-Version 4.50 oder 4.51 auf Version 4.52 auf. Die Probleme treten hauptsächlich auf, wenn die Anzahl der Tabellen größer als 500 ist.

Mit der folgenden SQL-Abfrage können Sie die Gesamtzahl der Tabellen in Postgres prüfen:

select count(*) from information_schema.tables

Problemumgehung:Wenn Sie Apigee Edge 4.50.00 oder 4.51.00 auf 4.52.00 aktualisieren, müssen Sie vor dem Upgrade von Apigee-postgresql den vorläufigen Schritt ausführen.

149245401: Die LDAP-Verbindungspool-Einstellungen für JNDI, die über die LDAP-Ressource konfiguriert werden, werden nicht berücksichtigt und die JNDI-Standardeinstellungen führen jedes Mal zu Einmalverbindungen. Daher werden Verbindungen jedes Mal für die einmalige Verwendung geöffnet und geschlossen, was zu einer großen Anzahl von Verbindungen pro Stunde zum LDAP-Server führt.

Workaround:

Wenn Sie die Eigenschaften des LDAP-Verbindungs-Pools ändern möchten, führen Sie die folgenden Schritte aus, um eine globale Änderung für alle LDAP-Richtlinien festzulegen.

1. Erstellen Sie eine Konfigurationsattributdatei, falls sie noch nicht vorhanden ist:

   /opt/apigee/customer/application/message-processor.properties

2. Fügen Sie der Datei Folgendes hinzu. Ersetzen Sie die Werte der JNDI-Attribute (Java Naming and Directory Interface) entsprechend den Anforderungen Ihrer LDAP-Ressourcenkonfiguration.

   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. Prüfen Sie, ob die Datei /opt/apigee/customer/application/message-processor.properties dem Nutzer „apigee:apigee“ gehört.
4. Starten Sie jeden Nachrichtenprozessor neu.

Wenn Sie prüfen möchten, ob die JNDI-Eigenschaften Ihres Verbindungspools wirksam werden, können Sie einen tcpdump durchführen, um das Verhalten des LDAP-Verbindungspools im Zeitverlauf zu beobachten.

139051927: Hohe Latenzen bei der Proxyverarbeitung im Message Processor wirken sich auf alle API-Proxys aus. Zu den Symptomen gehören Verzögerungen von 200 bis 300 ms bei den Verarbeitungszeiten im Vergleich zu normalen API-Antwortzeiten. Sie können auch bei niedrigen TPS zufällig auftreten. Das kann passieren, wenn ein Message Processor Verbindungen zu mehr als 50 Zielservern herstellt.

Ursache:Nachrichtenprozessoren verwalten einen Cache, in dem die Zielserver-URL dem HTTPClient-Objekt für ausgehende Verbindungen zu Zielservern zugeordnet wird. Standardmäßig ist diese Einstellung auf 50 festgelegt, was für die meisten Bereitstellungen zu niedrig sein kann. Wenn eine Bereitstellung mehrere Organisations-/Umgebungskombinationen in einer Einrichtung und eine große Anzahl von Zielservern hat, die insgesamt 50 überschreiten, werden die Zielserver-URLs immer wieder aus dem Cache entfernt, was zu Latenzen führt.

Validierung:Suchen Sie in den Systemprotokollen des Message Processor nach dem Keyword „onEvict“ oder „Eviction“, um festzustellen, ob das Problem durch das Entfernen der Zielserver-URL verursacht wird. Ihr Vorhandensein in den Logs weist darauf hin, dass Zielserver-URLs aus dem HTTPClient-Cache entfernt werden, weil die Cachegröße zu klein ist.

Problemumgehung:In Edge for Private Cloud-Versionen 19.01 und 19.06 können Sie den HTTPClient-Cache (/opt/apigee/customer/application/message-processor.properties) bearbeiten und konfigurieren:

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

Starten Sie dann den Message Processor neu. Nehmen Sie dieselben Änderungen für alle Message Processors vor.

Der Wert 500 ist ein Beispiel. Der optimale Wert für Ihre Konfiguration sollte größer als die Anzahl der Zielserver sein, mit denen der Nachrichtenprozessor eine Verbindung herstellen würde. Das Festlegen eines höheren Werts für diese Property hat keine Nebenwirkungen. Die einzige Auswirkung sind kürzere Verarbeitungszeiten für Proxyanfragen des Message-Prozessors.

Hinweis:In Edge for Private Cloud-Version 50.00 ist der Standardwert 500.

157933959: Gleichzeitiges Einfügen und Aktualisieren derselben Schlüssel/Wert-Zuordnung (Key Value Map, KVM) auf Organisations- oder Umgebungsebene führt zu inkonsistenten Daten und verlorenen Aktualisierungen.

Hinweis:Diese Einschränkung gilt nur für Edge for Private Cloud. Für Edge for Public Cloud und Hybrid gilt diese Einschränkung nicht.

Als Workaround in Edge for Private Cloud erstellen Sie den KVM im apiproxy-Bereich.