19.03.01 - Note di rilascio di Apigee Edge per il cloud pubblico

Bilanciamento del carico: maggiore controllo per la rimozione dei server non funzionanti

Quando configuri un bilanciatore del carico per un proxy API, puoi determinare il numero di errori di risposta che si verificano prima che un server venga rimosso dalla rotazione del bilanciamento del carico. Un errore di risposta significa che Apigee non riceve alcuna risposta da un server di destinazione. In questo caso, il contatore degli errori aumenta di uno. Quando Apigee riceve una risposta da una destinazione, anche se la risposta è un errore HTTP (ad esempio 500), questa viene conteggiata come risposta dal server di destinazione e il contatore degli errori viene reimpostato. Per contribuire a garantire che anche le risposte HTTP errate (ad esempio 500) aumentino il contatore degli errori in modo da escludere un server non integro dalla rotazione del bilanciamento del carico il prima possibile, puoi aggiungere un nuovo elemento <ServerUnhealthyResponse> con elementi secondari <ResponseCode> alla configurazione del bilanciatore del carico. Edge conteggerà anche le risposte con questi codici come errori.

<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>
  
  

Miglioramenti dei criteri AccessControl

Il criterio AccessControl determina quali indirizzi IP possono effettuare chiamate a un proxy API. Un nuovo elemento di queste norme offre agli sviluppatori di API un maggiore controllo nell'identificazione degli indirizzi IP da valutare.

<IgnoreTrueClientIPHeader>: facoltativo (il valore predefinito è false). Se lo imposti su true, il criterio ignora l'intestazione True-Client-IP e valuta gli indirizzi IP nell'intestazione X-Forwarded-For, seguendo il comportamento di valutazione X-Forwarded-For che hai configurato.

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

Per maggiori dettagli, consulta questo post della community.

Nella norma RaiseFault sono disponibili due nuovi elementi per rendere la gestione di FaultRules più pulita ed efficace.

• ShortFaultReason è un valore booleano che, se impostato su true, inserisce il nome della policy nella variabile fault.reason.
• AssignVariable, disponibile in FaultResponse, consente di assegnare la risposta all'errore a una variabile da utilizzare in altre norme nel flusso proxy API.

Ora vengono applicati limiti per i target ospitati. Per i dettagli sui limiti, consulta la sezione Limiti.

Ora puoi utilizzare le variabili del modello di messaggio per impostare indirizzi IP e maschere CIDR nel criterio AccessControl. Ad esempio, se vuoi memorizzare un indirizzo IP e una maschera in una mappa chiave-valore (KVM), puoi recuperare questi valori da una variabile che hai impostato nel flusso del proxy API. In questo modo puoi modificare più facilmente i valori IP in fase di runtime senza dover modificare la configurazione dei criteri.

Ad esempio, invece di:

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

Potresti configurare il criterio in questo modo, supponendo che i valori siano memorizzati in una KVM, e utilizzare il criterio KeyValueMapOperations per recuperare i valori e assegnarli alle variabili mostrate qui:

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

API Monitoring fornisce due ruoli: Amministratore API Monitoring e Utente API Monitoring, descritti in Accedere ad API Monitoring. Queste sono state rese disponibili a dicembre 2018.

Edge ora aggiunge l'intestazione X-Apigee.Message-Timeout a ogni richiesta. Questa intestazione è per uso interno di Edge. Non fare affidamento sui valori delle intestazioni X-Apigee.* nei proxy API, in quanto queste intestazioni non sono destinate all'uso da parte dei clienti e possono essere rimosse o modificate da Apigee in qualsiasi momento.

Gestire gli errori di eliminazione del keystore in modo che la chiamata API non non riesca

x-apigee.edge.execution.sense.action è sempre impostato su null

Nella norma ResponseCache, NIOTheread viene eseguito senza rifiuto dal pool di thread

Più esportatori di log sui router Apigee causano un utilizzo elevato della CPU

Errori 404 intermittenti in organizzazioni specifiche

Il flusso condiviso di cui è stato eseguito il deployment non viene eseguito su alcuni elaboratori di messaggi

Questa correzione verrà inclusa nella prossima release di Edge for Private Cloud.

Questa correzione verrà inclusa nella prossima release di Edge for Private Cloud.

Questa correzione verrà inclusa nella prossima release di Edge for Private Cloud.