19.03.01 – Versionshinweise zu Apigee Edge for Public Cloud

Load-Balancing – mehr Kontrolle zum Entfernen ausfallender Server

Bei der Konfiguration eines für einen API-Proxy, können Sie festlegen, wie viele Fehler treten auf, bevor ein Server aus der Load-Balancing-Rotation entfernt wird. Fehler bei der Antwort bedeutet, dass Apigee keine Antwort von einem Zielserver erhält. In diesem Fall wird der Fehler wird der Zähler um eins erhöht. Wenn Apigee eine Antwort von einem Ziel erhält, selbst wenn der Antwort ein HTTP-Fehler (z. B. 500) ist, der als Antwort des Zielservers zählt, und der Fehlerzähler wird zurückgesetzt. Um sicherzustellen, dass fehlerhafte HTTP-Antworten (z. B. 500) auch den Fehlerzähler erhöhen, um einen fehlerhaften Server aus der Load-Balancing-Rotation zu entfernen, können Sie so bald wie möglich ein neues <ServerUnhealthyResponse>-Element hinzufügen mit untergeordneten Elementen aus <ResponseCode> der Load-Balancer-Konfiguration. 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 der AccessControl-Richtlinie

Die AccessControl-Richtlinie legt fest, 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 die auszuwertenden Adressen.

<IgnoreTrueClientIPHeader>: Optional (Standardeinstellung ist „false“). Wenn Sie dies auf „true“ setzen, ignoriert die Richtlinie den Header „True-Client-IP“ und wertet IP-Adressen im X-Forwarded-For-Header nach dem <ph type="x-smartling-placeholder"></ph> X-Forwarded-For Bewertungsverhalten, 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 unter diesem Communitybeitrag.

In der RaiseFault-Richtlinie sind zwei neue Elemente verfügbar, mit denen FaultRules erstellt werden kann. sauberer und leistungsstärker.

• ShortFaultReason ist ein boolescher Wert, der bei Einstellung auf „true“ den Richtliniennamen in die Variable „error.reason“ setzt.
• 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. Details zu den Grenzwerten finden Sie hier.

Sie können jetzt Nachrichtenvorlagenvariablen verwenden, um IP-Adressen und CIDR-Masken für die AccessControl-Richtlinie Wenn Sie beispielsweise ein IP-Adresse und -Maske in einer Schlüsselwertzuordnung (KVM) können Sie diese Werte aus einer von Ihnen festgelegten Variablen abrufen im API-Proxy-Ablauf. So können Sie die IP-Werte während der Laufzeit einfacher ändern, die Richtlinienkonfiguration zu ändern.

Anstelle von:

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

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

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

API Monitoring bietet zwei Rollen: API-Überwachungsadministrator und API-Überwachungsnutzer (siehe API-Überwachung aufrufen). Sie sind seit Dezember 2018 verfügbar.

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

Fehler beim Löschen des Schlüsselspeichers so beheben, dass der API-Aufruf nicht fehlschlägt

x-apigee.edge.execute.sense.action ist immer auf null gesetzt.

In der ResponseCache-Richtlinie wird NIOTheread ohne Ablehnung durch den Threadpool

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

Intermittierende 404-Fehler in bestimmten Organisationen

Bereitgestellter freigegebener Ablauf wird auf einigen Nachrichtenprozessoren nicht ausgeführt

Diese Korrektur wird in der nächsten Version von Edge für Private Cloud enthalten.

Diese Korrektur wird in der nächsten Version von Edge für Private Cloud enthalten.

Diese Korrektur wird in der nächsten Version von Edge für Private Cloud enthalten.