19.03.01 - Note di rilascio di Apigee Edge for Public Cloud

Bilanciamento del carico: maggiore controllo sui server in errore

Quando configuri un bilanciatore del carico per un proxy API, puoi determinare quanti errori di risposta si verificano prima che un server sia rimosso dalla rotazione del bilanciamento del carico. Un errore di risposta indica 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), viene conteggiata una risposta dal server di destinazione e il contatore degli errori viene reimpostato. Per assicurarti che le risposte HTTP errate (ad esempio 500) incrementino anche il contatore di errori per escludere un server in stato 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. Inoltre, Edge conteggia le risposte con questi codici come operazioni non riuscite.

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

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

<IgnoreTrueClientIPHeader>: facoltativo (il valore predefinito è false). Se questo criterio viene impostato su vero, 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 scheda Community.

Nel criterio IncreaseFault sono disponibili due nuovi elementi per rendere la gestione delle FaultRegole più precisa e potente.

• ShortFaultReason è un valore booleano che, se impostato su true, inserisce il nome del criterio nella variabile error.reason.
• AssignVariable, disponibile in FaultResponse, ti consente di assegnare la risposta all'errore a una variabile che verrà utilizzata da altri criteri nel flusso del proxy API.

Per i target ospitati sono ora in vigore limiti. Per informazioni dettagliate sui limiti, consulta Limiti.

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

Ad esempio, invece di:

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

Puoi configurare il criterio in questo modo, supponendo che i valori siano archiviati in una KVM e utilizzando 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>
     

Monitoraggio API offre due ruoli: amministratore di monitoraggio API e utente monitoraggio API, descritto in Accedere a monitoraggio API. Questi dati sono stati resi disponibili a dicembre 2018.

Ora Edge aggiunge l'intestazione X-Apigee.Message-Timeout a ogni richiesta. Questa intestazione è per uso interno da parte di Edge. Non fare affidamento sui valori nelle intestazioni X-Apigee.* nei proxy API, poiché tali 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 dell'archivio chiavi in modo che la chiamata API non vada a buon fine

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

Nel criterio ResponseCache, NIOtheread è in esecuzione senza rifiuto dal pool di thread

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

Errori 404 intermittenti in organizzazioni specifiche

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

Questa correzione verrà inclusa nella prossima release di Edge per il cloud privato.

Questa correzione verrà inclusa nella prossima release di Edge per il cloud privato.

Questa correzione verrà inclusa nella prossima release di Edge per il cloud privato.