19.03.01 – Versionshinweise zu Apigee Edge for Public Cloud

Load-Balancing – mehr Kontrolle beim Entfernen ausgefallener Server

Beim Konfigurieren eines Load-Balancers für einen API-Proxy können Sie festlegen, wie viele Antwortfehler auftreten, bevor ein Server aus der Load-Balancing-Rotation entfernt wird. Ein Antwortfehler bedeutet, dass Apigee keine Antwort von einem Zielserver empfängt. In diesem Fall erhöht sich der Fehlerzähler um eins. Wenn Apigee eine Antwort von einem Ziel erhält, zählt dies als Antwort vom Zielserver, selbst wenn die Antwort ein HTTP-Fehler ist (z. B. 500), und der Fehlerzähler wird zurückgesetzt. Sie können Ihrer Load-Balancer-Konfiguration ein neues <ServerUnhealthyResponse>-Element mit untergeordneten <ResponseCode>-Elementen hinzufügen, damit fehlerhafte HTTP-Antworten (z. B. 500) auch den Fehlerzähler erhöhen, um einen fehlerhaften Server so schnell wie möglich aus der Load-Balancing-Rotation auszuschließen. Edge zählt auch Antworten mit diesen Codes als Fehler.

<HTTPTargetConnection>
  <LoadBalancer>
    <Algorithm>RoundRobin</Algorithm>
    <Server name="target1" />
    <Server name="target2" />
    <ServerUnhealthyResponse>
        <ResponseCode>500</ResponseCode>
        <ResponseCode>502</ResponseCode>
        <ResponseCode>503</ResponseCode>
    </ServerUnhealthyResponse>
    <MaxFailures>5</MaxFailures>
  </LoadBalancer>
</HTTPTargetConnection>
  
  

Verbesserungen an AccessControl-Richtlinien

Die AccessControl-Richtlinie legt fest, welche IP-Adressen Aufrufe an einen API-Proxy tätigen können. Ein neues Element in dieser Richtlinie gibt API-Entwicklern mehr Kontrolle darüber, welche IP-Adressen ausgewertet werden sollen.

<IgnoreTrueClientIPHeader>: Optional (Standardeinstellung ist „false“). Wenn Sie dies auf „true“ setzen, ignoriert die Richtlinie den Header True-Client-IP und wertet IP-Adressen im Header X-Forwarded-For gemäß dem von Ihnen konfigurierten Auswertungsverhalten „X-Forwarded-For“ aus.

<AccessControl async="false" continueOnError="false"
    enabled="true" name="Access-Control-1">
    <DisplayName>Access Control-1</DisplayName>
    <IgnoreTrueClientIPHeader>true</IgnoreTrueClientIPHeader>
    ...
</AccessControl>

Weitere Informationen findest du in diesem Communitybeitrag.

In der Richtlinie "IncreaseFault" sind zwei neue Elemente verfügbar, die den FaultRules-Umgang sauberer und leistungsfähiger machen.

• ShortFaultReason ist ein boolescher Wert, der bei Einstellung auf „true“ den Richtliniennamen in die Variable „error.reason“ einfügt.
• Mit AssignVariable, das in der FaultResponse verfügbar ist, können Sie die Fehlerantwort einer Variablen zuweisen, die von anderen Richtlinien im API-Proxy-Ablauf verwendet werden soll.

Für gehostete Ziele werden jetzt Limits erzwungen. Weitere Informationen zu Limits finden Sie unter Limits.

Sie können jetzt Nachrichtenvorlagenvariablen verwenden, um IP-Adressen und CIDR-Masken in der AccessControl-Richtlinie festzulegen. Wenn Sie beispielsweise eine IP-Adresse und -Maske in einer Schlüssel/Wert-Zuordnung (KVM) speichern möchten, können Sie diese Werte aus einer Variablen abrufen, die Sie im API-Proxy-Ablauf festgelegt haben. So können Sie IP-Werte einfacher zur Laufzeit ändern, ohne die Richtlinienkonfiguration ändern zu müssen.

Anstelle von:

<MatchRule action="DENY">
    <SourceAddress mask="24">198.51.100.1</SourceAddress>
</MatchRule>
     

Sie könnten die Richtlinie so konfigurieren, dass die Werte in einer KVM gespeichert sind, und mithilfe der KeyValueMapOperations-Richtlinie die Werte abrufen und den hier gezeigten Variablen zuweisen:

<MatchRule action="DENY">
    <SourceAddress mask="{kvm.mask.ref}">{kvm.ip.ref}</SourceAddress>
</MatchRule>
     

Die API-Überwachung bietet zwei Rollen: API-Überwachungsadministrator und API-Überwachungsnutzer, die unter Access API-Überwachung beschrieben werden. Sie wurden im Dezember 2018 zur Verfügung gestellt.

Edge fügt jetzt jeder Anfrage den Header X-Apigee.Message-Timeout hinzu. Dieser Header ist zur internen Verwendung durch Edge vorgesehen. Verlassen Sie sich nicht auf die Werte in den X-Apigee.*-Headern Ihrer API-Proxys, da diese Header nicht für die Verwendung durch Kunden bestimmt sind und jederzeit von Apigee entfernt oder geändert werden können.

Fehler beim Löschen von Schlüsselspeichern beheben, damit der API-Aufruf nicht fehlschlägt

x-apigee.edge.ausführung.sense.action ist immer auf null gesetzt

In der ResponseCache-Richtlinie wird NIOTheread ohne Ablehnung aus dem Thread-Pool ausgeführt.

Mehrere Logexporter auf Apigee-Routern verursachen eine hohe CPU-Auslastung

Zeitweilige 404-Fehler in bestimmten Organisationen

Bereitgestellter freigegebener Ablauf wird auf einigen Message Processorn nicht ausgeführt

Diese Fehlerbehebung wird im nächsten Release von Edge for Private Cloud enthalten sein.

Diese Fehlerbehebung wird im nächsten Release von Edge for Private Cloud enthalten sein.

Diese Fehlerbehebung wird im nächsten Release von Edge for Private Cloud enthalten sein.