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

Bilanciamento del carico: maggiore controllo per la rimozione dei server in errore

Quando configuri un bilanciatore del carico per un proxy API, puoi determinare il numero di risposte gli errori si verificano prima che un server venga rimosso dalla rotazione del bilanciamento del carico. Un errore di risposta significa che Apigee non riceve risposta da un server di destinazione. In questi casi, l'errore viene incrementato di uno. Quando Apigee riceve una risposta da un target, anche se la risposta è un errore HTTP (ad esempio 500), che viene conteggiato come una risposta dal server di destinazione, e il contatore di errori viene reimpostato. Per garantire che anche le risposte HTTP errate (ad esempio 500) aumenta il contatore di errori per escludere la rotazione del bilanciamento del carico di un server in stato non integro come il prima possibile, puoi aggiungere un nuovo elemento <ServerUnhealthyResponse> con <ResponseCode> elementi secondari alla configurazione del bilanciatore del carico. Edge conterà 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 ai criteri AccessControl

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

<IgnoreTrueClientIPHeader>: facoltativo (il valore predefinito è false). Se viene impostato su true, il criterio ignora l'intestazione True-Client-IP e valuta gli indirizzi IP nell'intestazione X-Forwarded-For, seguendo . X-Forwarded-Per il comportamento di valutazione 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, vedi questo post della scheda Community.

Nel criterio RaiseFault sono disponibili due nuovi elementi per creare FaultRules più pulite e potenti.

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

Vengono ora applicati dei limiti per le destinazioni ospitate. Consulta Limiti per i dettagli sui limiti.

Ora puoi utilizzare le variabili del modello di messaggio per impostare indirizzi IP e maschere CIDR nel Criterio AccessControl. Ad esempio, se vuoi archiviare un Indirizzo IP e maschera in una mappa chiave-valore (KVM), puoi recuperare questi valori da una variabile impostata nel flusso proxy API. Ciò consente di 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>
     

Puoi configurare il criterio in questo modo, supponendo che i valori siano archiviati in una KVM, e utilizzerai il criterio KeyValueMapOperations per recuperare i valori e assegnarli a le variabili mostrate qui:

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

API Monitoring offre due ruoli: Amministratore monitoraggio API e Utente monitoraggio API, descritto in Accesso al monitoraggio delle API. Sono stati resi disponibili da dicembre 2018.

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

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

Nel criterio ResponseCache, NIO Theread è in esecuzione senza rifiuto da parte pool di thread

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

Errori 404 intermittenti in organizzazioni specifiche

Distribuito il flusso condiviso non in esecuzione su alcuni processori 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.