Sie sehen sich die Dokumentation zu Apigee Edge an.
Sehen Sie sich die Apigee X-Dokumentation an. info
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.
Sonstige bekannte Probleme mit Edge
In den folgenden Abschnitten werden verschiedene bekannte Probleme mit Edge beschrieben.
| Gebiet | Bekannte Probleme |
|---|---|
Das Ablaufen des Caches führt zu einem falschen cachehit-Wert |
Wenn die Ablaufvariable Problemumgehung:Wiederholen Sie den Vorgang (führen Sie einen zweiten Anruf aus) direkt nach dem ersten Anruf. |
Die InvalidateCache-RichtliniePurgeChildEntries funktioniert nicht richtig, wenn sie auf „wahr“ gesetzt wird |
Wenn Sie Umgehung:Verwenden Sie die KeyValueMapOperations-Richtlinie, um die Cache-Versionierung zu iterieren und die Cache-Entwertung zu umgehen. |
| Gleichzeitige Bereitstellungsanfragen für einen SharedFlow oder API-Proxy können zu einem inkonsistenten Zustand im Verwaltungsserver führen, wenn mehrere Revisionen als bereitgestellt angezeigt werden. |
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. |
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 mit dem integrierten Portal beschrieben.
| Gebiet | Bekannte Probleme |
|---|---|
| SmartDocs |
|
| 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 leer, wenn Sie die SAML-Einstellungen konfigurieren. |
| Portal-Administrator |
|
| Portalfunktionen |
|
Bekannte Probleme mit Edge for Private Cloud
In den folgenden Abschnitten werden bekannte Probleme mit Edge for Private Cloud beschrieben.
| Gebiet | Bekannte Probleme |
|---|
| Edge for Private Cloud 4.52.02 und 4.53.00 |
Wenn Sie die Richtlinie SetOauthV2Info verwenden und der AccessToken nicht in eine Variable aufgelöst werden kann oder null ist, führt die Richtlinie zu einem Datenspeicherfehler: {
"fault": {
"faultstring": "Error while accessing datastore;Please retry later",
"detail": {
"errorcode": "datastore.ErrorWhileAccessingDataStore"
}
}
}
Dieses Verhalten unterscheidet sich von früheren Apigee-Versionen, in denen ein solches Szenario einen {
"fault": {
"faultstring": "Invalid Access Token",
"detail": {
"errorcode": "keymanagement.service.invalid_access_token"
}
}
}
Fügen Sie Ihrem Proxy eine RaiseFault-Richtlinie hinzu, um die ältere Fehlermeldung zu simulieren. Diese RaiseFault-Richtlinie kann ausgeführt werden, wenn die Variable für das Zugriffstoken null ist. Hier ein entsprechendes Beispiel: <!-- Sample Raise Fault Policy ---> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <RaiseFault async="false" continueOnError="false" enabled="true" name="RaiseFault-MissingAccessToken"> <DisplayName>RaiseFault-MissingAccessToken</DisplayName> <Properties/> <FaultResponse> <Set> <Headers/> <Payload contentType="application/json">{"fault":{"faultstring":"Invalid Access Token","detail":{"errorcode":"keymanagement.service.invalid_access_token"}}}</Payload> <StatusCode>500</StatusCode> <ReasonPhrase>Internal Server Error</ReasonPhrase> </Set> </FaultResponse> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </RaiseFault> Die Richtlinie RaiseFault kann bedingt vor der Richtlinie SetOauthV2Info in Ihrem Proxy-Ablauf hinzugefügt werden, wie im folgenden Beispiel gezeigt:
<Step> <!-- Execute RaiseFault policy if access_token flow variable is null --> <Condition>access_token = null</Condition> <Name>RaiseFault-MissingAccessToken</Name> </Step> <Step> <!-- Execute SetOAuthV2Info policy if access_token flow variable is null --> <Condition>access_token != null</Condition> <Name>SetOAuthV2Info</Name> </Step> Apigee wird einen Patch veröffentlichen, um das oben beschriebene Verhalten für die Edge for Private Cloud-Versionen 4.52.02 und 4.53.00 wiederherzustellen. |
| Update auf Edge for Private Cloud 4.52.02 |
Wenn Sie Edge for Private Cloud von Version 4.51.00, 4.52.00 oder 4.52.01 auf Version 4.52.02 aktualisieren, sind zusätzliche Auswirkungen auf die Laufzeit- und Verwaltungs-APIs zu erwarten. Diese Auswirkungen treten auf, nachdem die Cassandra-Knoten aktualisiert wurden, und dauern so lange, bis alle Knoten des Nachrichten- und Verwaltungsservers aktualisiert wurden. In diesem Fall sind folgende Bereiche betroffen:
Apigee veröffentlicht eine überarbeitete Updatedokumentation für Edge for Private Cloud 4.52.02, in der dieses Problem behoben wird. |
| 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:
Führen Sie die folgenden Schritte aus, wenn Sie Edge for Private Cloud-Versionen verwenden, die älter als 4.51.00.11 sind:
|
| PostgreSQL-Upgrade bei der 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 den vorbereitenden Schritt aus, bevor Sie Apigee-postgresql aktualisieren. |
| 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.
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, die insgesamt 50 übersteigt, 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 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: Gleichzeitige Einträge und Aktualisierungen in derselben Schlüssel/Wert-Zuordnung (Key Value Map, KVM), die auf Organisations- oder Umgebungsebene gilt, führen 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 |