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 dem Load-Balancing-Zyklus 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 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 das Element <ServerUnhealthyResponse> mit untergeordneten <ResponseCode> Elementen zu Ihrer Load-Balancing-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 an 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 Community-Beitrag.

In der RaiseFault-Richtlinie sind zwei neue Elemente verfügbar, um die Verarbeitung von FaultRules übersichtlicher und leistungsfähiger zu gestalten.

• 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-Paarzuordnung (KVM) speichern möchten, können Sie diese Werte aus einer Variablen abrufen, die Sie im API-Proxy-Ablauf 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>
     

Das API-Monitoring bietet zwei Rollen: „API-Monitoring-Administrator“ und „API-Monitoring-Nutzer“, die unter Auf das API-Monitoring zugreifen beschrieben werden. 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 nicht auf die Werte in den X-Apigee.*-Headern in Ihren API-Proxys, da diese Header nicht für den Kunden bestimmt 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-Exporter auf Apigee-Routern verursachen eine hohe CPU-Auslastung

Zeitweise 404-Fehler in bestimmten Organisationen

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

Dieser Fix wird in der nächsten Version von Edge for Private Cloud enthalten sein.

Dieser Fix wird in der nächsten Version von Edge for Private Cloud enthalten sein.

Dieser Fix wird in der nächsten Version von Edge for Private Cloud enthalten sein.