19.03.01 – Versionshinweise zu Apigee Edge for Public Cloud

Load-Balancing – mehr Kontrolle beim Entfernen fehlerhafter Server

Wenn Sie einen Load-Balancer für einen API-Proxy konfigurieren, können Sie festlegen, wie viele Antwortfehler auftreten müssen, 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 wird der Fehlerzähler um eins erhöht. Wenn Apigee jedoch eine Antwort von einem Ziel erhält, selbst wenn es sich bei der Antwort um einen HTTP-Fehler (wie z. B. 500) handelt, zählt dies als Antwort vom Zielserver, und der Fehlerzähler wird zurückgesetzt. Um sicherzustellen, dass HTTP-Fehler-Antworten (z. B. 500) auch den Fehlerzähler schrittweise erhöhen, damit ein fehlerhafter Server so schnell wie möglich aus der Load-Balancing-Rotation herausgenommen wird, können Sie ein neues <ServerUnhealthyResponse>-Element mit untergeordneten <ResponseCode>-Elementen zu Ihrer Load-Balancer-Konfiguration hinzufügen. Edge zählt außerdem 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 bei der AccessControl-Richtlinie

Mit der AccessControl-Richtlinie wird festgelegt, welche IP-Adressen Aufrufe an einen API-Proxy senden können. Ein neues Element in dieser Richtlinie gibt API-Entwicklern mehr Kontrolle darüber, welche IP-Adressen ausgewertet werden sollen.

<IgnoreTrueClientIPHeader>: Optional (Standardwert 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 X-Forwarded-For-Evaluierungsverhalten aus, das Sie konfiguriert haben.

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

Weitere Informationen finden Sie in diesem Communitybeitrag.

In der RaiseFault-Richtlinie sind zwei neue Elemente verfügbar, mit denen die Verarbeitung von FaultRules übersichtlicher und leistungsfähiger wird.

• ShortFaultReason ist ein boolescher Wert, der, wenn er auf „true“ gesetzt ist, den Richtliniennamen in die Variable „fault.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 durchgesetzt. Weitere Informationen zu den Limits finden Sie unter Einschränkungen.

Sie können jetzt Variablen für Nachrichtenvorlagen verwenden, um IP-Adressen und CIDR-Masken in der AccessControl-Richtlinie festzulegen. Wenn Sie beispielsweise eine IP-Adresse und eine 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-Flow festlegen. So können Sie IP-Werte zur Laufzeit einfacher ändern, ohne die Richtlinienkonfiguration anpassen zu müssen.

Anstelle von:

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

Sie können die Richtlinie so konfigurieren, wenn die Werte in einer KVM gespeichert sind und Sie die KeyValueMapOperations-Richtlinie verwenden, um die Werte abzurufen und den hier gezeigten Variablen zuzuweisen:

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

Für das API-Monitoring gibt es zwei Rollen: „API Monitoring Administrator“ und „API Monitoring User“. Diese werden unter Auf API-Monitoring zugreifen beschrieben. Sie sind seit Dezember 2018 verfügbar.

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

Fehler beim Löschen des Keystores abfangen, damit der API-Aufruf nicht fehlschlägt

x-apigee.edge.execution.sense.action ist immer auf „null“ gesetzt

In der ResponseCache-Richtlinie wird NIOTheread ohne Ablehnung durch den Threadpool ausgeführt.

Mehrere Log-Exporte auf Apigee-Routern verursachen eine hohe CPU-Auslastung

Zeitweise 404-Fehler in bestimmten Organisationen

Bereitgestellter freigegebener Ablauf wird auf einigen Message-Prozessoren nicht ausgeführt

Diese Korrektur wird in der nächsten Edge for Private Cloud-Version enthalten sein.

Diese Korrektur wird in der nächsten Edge for Private Cloud-Version enthalten sein.

Diese Korrektur wird in der nächsten Edge for Private Cloud-Version enthalten sein.