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

Bilanciamento del carico: maggiore controllo per la rimozione dei server con errori

Durante la configurazione di 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 questi casi, il contatore di errori viene incrementato 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 di errori viene reimpostato. Per garantire che le risposte HTTP non corrette (ad esempio 500) aumentino anche il contatore di errori per eliminare il prima possibile la rotazione del bilanciamento del carico di un server non integro, puoi aggiungere un nuovo elemento <ServerUnhealthyResponse> con elementi secondari <ResponseCode> alla configurazione del bilanciatore del carico. Inoltre, Edge conteggerà 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 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 di quali indirizzi IP valutare.

<IgnoreTrueClientIPHeader>: facoltativo (il valore predefinito è false). Se imposti questo valore 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 informazioni dettagliate, consulta questo post della scheda Community.

Il criterio AlzaFault contiene due nuovi elementi per rendere la gestione di FaultRules più chiara ed efficace.

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

Ora vengono 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 gli indirizzi IP e le maschere CIDR nel criterio AccessControl. Ad esempio, se vuoi archiviare un indirizzo IP e una maschera in una mappa chiave-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 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 un KVM e che tu utilizzi 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 di API Monitoring e Utente API Monitoring, descritti in Access API Monitoring. Questi dati sono stati resi disponibili da dicembre 2018.

Edge ora aggiunge l'intestazione X-Apigee.Message-Timeout a ogni richiesta. Questa intestazione è destinata all'uso interno 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 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 utilizzo elevato della CPU

Errori 404 intermittenti in organizzazioni specifiche

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

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

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

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