Bekannte Probleme mit Apigee

Sie sehen die Dokumentation zu Apigee Edge.
Rufen Sie die Apigee X-Dokumentation auf. weitere Informationen

In den folgenden Abschnitten werden die bekannten Probleme mit Apigee beschrieben. In den meisten Fällen werden die aufgeführten Probleme in einer zukünftigen Version behoben.

Bekannte Probleme mit verschiedenen Edge-Geräten

In den folgenden Abschnitten werden verschiedene bekannte Probleme mit Edge beschrieben.

Standort Bekannte Probleme
Bei Cache-Ablauf wird cachehit-Wert falsch

Wenn die Flussvariable cachehit nach der LookupCache-Richtlinie verwendet wird, füllt die LookupPolicy aufgrund der Art und Weise, wie Debug-Punkte für asynchrones Verhalten gesendet werden, das DebugInfo-Objekt auf, bevor der Callback ausgeführt wird. Dies führt zu einem Fehler.

Problemumgehung: Wiederholen Sie den Vorgang direkt nach dem ersten Aufruf noch einmal.

Das Festlegen der InvalidCache-Richtlinie PurgeChildEntries auf „true“ funktioniert nicht richtig

Wenn du PurgeChildEntries in der InvalidCache-Richtlinie festlegst, werden nur die KeyFragment-Elementwerte dauerhaft gelöscht, aber der gesamte Cache wird geleert.

Problemumgehung:Verwenden Sie die KeyValueMapOperations-Richtlinie, um die Cache-Versionsverwaltung zu iterieren und die Notwendigkeit einer Cache-Entwertung zu umgehen.

Bekannte Probleme mit der Edge-UI

In den folgenden Abschnitten werden bekannte Probleme mit der Edge-UI beschrieben.

Gebiet Bekannte Probleme
Auf die Seite der Edge SSO Zone Administration kann nicht über die Navigationsleiste zugegriffen werden, nachdem die Organisation einer Identitätszone zugeordnet wurde Wenn Sie eine Organisation mit einer Identitätszone verbinden, können Sie nicht mehr auf die Seite "Edge SSO Zone Administration" in der linken Navigationsleiste zugreifen. Wählen Sie dazu "Admin" > "SSO" aus. Sie können das Problem umgehen, indem Sie mit der folgenden URL direkt die Seite aufrufen: https://apigee.com/sso

Bekannte Probleme mit dem integrierten Portal

In den folgenden Abschnitten werden die bekannten Probleme des integrierten Portals beschrieben.

Gebiet Bekannte Probleme
SmartDocs
  • Apigee Edge unterstützt OpenAPI Specification 3.0, wenn Sie Spezifikationen mit dem Spezifikationseditor erstellen und APIs mit SmartDocs auf Ihrem Portal veröffentlichen. Einige Funktionen werden 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 der API-Referenzdokumentation weniger einschränkend als SmartDocs ist, können die Ergebnisse der beiden 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.
SAML-Identitätsanbieter Die einmalige Abmeldung (SLO) mit dem SAML-Identitätsanbieter wird für benutzerdefinierte Domains nicht unterstützt. Wenn Sie eine benutzerdefinierte Domain mit einem SAML-Identitätsanbieter aktivieren möchten, lassen Sie das Feld Abmelde-URL beim Konfigurieren der SAML-Einstellungen leer.
Portal-Administrator
  • 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.
  • Bei der Konfiguration der Content Security Policy kann es bis zu 15 Minuten dauern, bis die Änderungen vollständig wirksam sind.
  • Bei der Anpassung des Portaldesign kann es bis zu 5 Minuten dauern, bis die Änderungen vollständig übernommen werden.
Portalfunktionen
  • Die Suche wird in einer zukünftigen Version in das integrierte Portal integriert.

Bekannte Probleme mit Edge for Private Cloud

In den folgenden Abschnitten werden bekannte Probleme mit Edge for Private Cloud beschrieben.

Gebiet Bekannte Probleme
4.53.00 Edge-Router-Funktionen

Die apigee-nginx auf Edge-Router-Knoten können Probleme mit der Bindung von Ports oder dem Beenden des nginx-Prozesses melden.

Betroffene Komponente:Edge-Router

Problem: Diese Probleme können durch Fehler bei der Einstellung von Funktionen während der Installation von apigee-nginx verursacht werden.

Problemumgehung:Sie können Funktionen manuell festlegen, indem Sie den folgenden Befehl ausführen:

setcap CAP_NET_BIND_SERVICE=+ep CAP_KILL=+ep /opt/nginx/sbin/nginx
4.53.00 SSO und neue Benutzeroberfläche

Dieses Problem betrifft Nutzer, die versuchen, die Einmalanmeldung oder die neue Benutzeroberfläche auf FIPS-kompatiblem RHEL 8 auf Edge for Private Cloud 4.53.00 zu installieren.

Betroffene Komponente:SSO und neue Benutzeroberfläche

Problem:Wenn Sie SSO oder die neue Benutzeroberfläche auf einem FIPS-kompatiblen RHEL 8-Betriebssystem installieren, schlägt die Installation fehl.

Umgehungslösung:Wir empfehlen Ihnen, die klassische Benutzeroberfläche zu verwenden, die alle Funktionen bietet und die Anforderungen an die Benutzeroberfläche erfüllt.
Edge for Private Cloud 4.52.01 Mint-Update

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

Betroffene Komponente:edge-message-processor

Problem: Wenn Sie die Monetarisierung aktiviert haben und 4.52.01 als Neuinstallation installieren oder ein Upgrade von früheren Private Cloud-Versionen durchführen, tritt ein Problem mit Nachrichten-Prozessoren auf. Die Anzahl der offenen Threads steigt nach und nach an, was zu einer Ressourcenausschöpfung führt. Im edge-message-processor-Systemprotokoll wird die folgende Ausnahme angezeigt:

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread
Apigee-HTTP/2-Sicherheitslücke

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 kann 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. Bei 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:

Führen Sie die folgenden Schritte aus, wenn Sie Edge Private Cloud-Versionen 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 Properties-Datei diese Zeile hinzu: 
      conf_webserver_http2.enabled=false
    3. Starten Sie die Verwaltungsserverkomponente neu: 
      apigee-service edge-management-server restart

  2. Nachrichtenverarbeiter aktualisieren:

    1. Öffnen Sie auf jedem Nachrichtenprozessorknoten /opt/apigee/customer/application/message-processor.properties
    2. Fügen Sie der Properties-Datei diese 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 Properties-Datei diese 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 Properties-Datei diese 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 Properties-Datei diese Zeile hinzu: 
      conf_webserver_http2.enabled=false
    3. Starten Sie die Message Processor-Komponente neu: 
      apigee-service edge-postgres-server restart

Führen Sie die folgenden Schritte aus, wenn Sie Edge for Private Cloud-Versionen verwenden, die älter als 4.51.00.11 sind:

  1. Verwaltungsserver aktualisieren:

    1. Öffnen Sie auf jedem Verwaltungsserverknoten /opt/apigee/customer/application/management-server.properties.
    2. Fügen Sie der Properties-Datei die folgenden beiden 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. Nachrichtenverarbeiter aktualisieren:

    1. Öffnen Sie auf jedem Nachrichtenprozessorknoten /opt/apigee/customer/application/message-processor.properties
    2. Fügen Sie der Properties-Datei die folgenden beiden 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 Properties-Datei die folgenden beiden 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 Properties-Datei die folgenden beiden 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 Properties-Datei die folgenden beiden 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
PostgreSQL-Upgrade bei Aktualisierung auf Version 4.52

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 über 500 liegt.

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

select count(*) from information_schema.tables

Umgehung: Wenn Sie Apigee Edge 4.50.00 oder 4.51.00 auf 4.52.00 aktualisieren, führen Sie unbedingt den vorbereitenden Schritt aus, bevor Sie Apigee-postgresql aktualisieren.
apigee-mirror unter RHEL 8.0

apigee-mirror funktioniert nicht unter Red Hat Enterprise Linux (RHEL) 8.0.

Umgehungslösung:Sie können apigee-mirror als Umgehungslösung auf einem Server installieren, auf dem eine niedrigere Version von RHEL oder ein anderes unterstütztes Betriebssystem für Apigee ausgeführt wird. Sie können dann Pakete über den Spiegel hinzufügen, auch wenn Sie Apigee auf RHEL 8.0-Servern installiert haben.

LDAP-Richtlinie

149245401: Die LDAP-Verbindungspooleinstellungen für JNDI, die über die LDAP-Ressource konfiguriert wurden, werden nicht berücksichtigt. Außerdem führen die JNDI-Standardeinstellungen jedes Mal zu Verbindungen zur einmaligen Verwendung. Daher werden Verbindungen jedes Mal für den einmaligen Gebrauch 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-Verbindungspools ä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-Properties (Java Naming and Directory Interface) entsprechend den Anforderungen an die 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. Der Eigentümer der Datei /opt/apigee/customer/application/message-processor.properties muss apigee:apigee sein.
  4. Starten Sie jeden Nachrichtenprozessor neu.

Um zu prüfen, ob die JNDI-Eigenschaften Ihres Verbindungspools wirksam werden, können Sie einen tcpdump ausführen, um das Verhalten des LDAP-Verbindungspools im Zeitverlauf zu beobachten.
Hohe Latenz bei der Anfrageverarbeitung

139051927: Hohe Proxy-Verarbeitungslatenzen im Message Processor wirken sich auf alle API-Proxys aus. Zu den Symptomen gehören Verzögerungen von 200 bis 300 ms bei der Verarbeitung im Vergleich zu den 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: Nachrichten-Prozessoren verwalten einen Cache, der die URL des Zielservers dem HTTPClient-Objekt für ausgehende Verbindungen zu Zielservern zuordnet. Standardmäßig ist diese Einstellung auf 50 festgelegt, was für die meisten Bereitstellungen möglicherweise zu niedrig ist. Wenn eine Bereitstellung mehrere Kombinationen von Organisation/Umgebung in einer Einrichtung hat und eine große Anzahl von Zielservern (mehr als 50), werden die Zielserver-URLs immer wieder aus dem Cache entfernt, was zu Latenzen führt.

Validierung: Wenn du herausfinden möchtest, ob die Auslagerung der Zielserver-URL das Latenzproblem verursacht, suche in den Systemprotokollen des Message Processor nach dem Keyword „onEvict“ oder „Eviction“. Ihre Anwesenheit in den Protokollen weist darauf hin, dass Zielserver-URLs aus dem HTTPClient-Cache entfernt werden, weil die Cachegröße zu klein ist.

Umgehungslösung:In den 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 Nachrichtenprozessor neu. Nehmen Sie dieselben Änderungen für alle Message Processors vor.

Der Wert 500 ist ein Beispiel. Der optimale Wert für Ihre Einrichtung sollte größer als die Anzahl der Zielserver sein, mit denen der Message Processor eine Verbindung herstellen würde. Wenn Sie diese Property höher festlegen, hat das keine Nebenwirkungen. Die einzige Auswirkung ist eine verbesserte Verarbeitungszeit von Proxyanfragen durch den Nachrichtenprozessor.

Hinweis:In Edge for Private Cloud Version 50.00 ist die Standardeinstellung 500.
Mehrere Einträge für Schlüssel/Wert-Zuordnungen

157933959: Wenn gleichzeitig Einträge und Aktualisierungen in dieselbe Schlüssel/Wert-Zuordnung (KVM) auf Organisations- oder Umgebungsebene vorgenommen werden, führt dies 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 Problemumgehung in Edge for Private Cloud können Sie die KVM auf apiproxy-Ebene erstellen.