Bilanciamento del carico tra server di backend

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. informazioni

Apigee Edge migliora la disponibilità della tua API fornendo il supporto integrato per il bilanciamento del carico e il failover su più istanze del server di backend.

Le configurazioni TargetServer disaccoppiano gli URL di endpoint concreti dalle configurazioni di TargetEndpoint. A ogni TargetServer viene fatto riferimento per nome in una HTTPConnection TargetEndpoint. Anziché definire un URL concreto nella configurazione, puoi configurare uno o più TargetServer denominati come descritto nella sezione TargetEndpoint.

Una definizione di TargetServer è composta da un nome, un host e una porta, con un elemento aggiuntivo per indicare se TargetServer è abilitato o disabilitato.

Video

Guarda i seguenti video per scoprire di più sul routing delle API e sul bilanciamento del carico tramite i server di destinazione

Video	Descrizione
Bilanciamento del carico mediante server di destinazione	API di bilanciamento del carico nei server di destinazione.
Routing delle API basato sull'ambiente che utilizza i server di destinazione	Instrada un'API a un server di destinazione diverso in base all'ambiente.
Routing delle API e bilanciamento del carico mediante i server di destinazione (Classic Edge)	Instrada un'API a un server di destinazione diverso in base all'ambiente e bilancia il carico dell'API tra i server di destinazione nella UI della versione classica di Edge.

Configurazione TargetServer di esempio

Il seguente codice definisce un server di destinazione:

<TargetServer  name="target1">
  <Host>1.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >

Elementi di configurazione di TargetServer

La seguente tabella descrive gli elementi utilizzati per creare e configurare un TargetServer:

Nome	Descrizione	Predefinito	Campo obbligatorio?
name	Il nome della configurazione TargetServer, che deve essere univoco all'interno dell'ambiente. Il nome TargetServer può contenere solo caratteri alfanumerici.	N/A	Sì
Host	L'URL host del servizio di backend (senza il protocollo).	N/A	Sì
Port	La porta su cui il servizio di backend è in ascolto	N/A	Sì
IsEnabled	Un valore booleano che indica se la configurazione TargetServer è abilitata o disabilitata. In questo modo puoi escludere TargetServers dalla rotazione senza modificare la configurazione del proxy API. Un utilizzo comune potrebbe essere scrivere un'app o uno script che attivi o disabilita automaticamente TargetServers in base ai requisiti di capacità previsti, alle pianificazioni della manutenzione e così via.	true	Sì

Gestione dei server di destinazione mediante l'interfaccia utente

Gestisci i server di destinazione come descritto di seguito.

Gestione dei server di destinazione mediante l'API

Puoi utilizzare l'API Edge per creare, eliminare, aggiornare, ottenere ed elencare i server di destinazione. Per ulteriori informazioni, consulta TargetServers.

Utilizza la seguente chiamata API per creare un server di destinazione:

$ curl -H "Content-Type:text/xml" -X POST -d \
'<TargetServer name="target1">
   <Host>1.mybackendservice.com</Host>
   <Port>80</Port>
   <IsEnabled>true</IsEnabled>
 </TargetServer>' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Esempio di risposta:

{
  "host" : "1.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

Dopo aver creato il primo TargetServer, utilizza la seguente chiamata API per creare un secondo TargetServer. Con la definizione di due TargetServer, vengono forniti due URL che un TargetEndpoint può utilizzare per il bilanciamento del carico:

$ curl -H "Content-type:text/xml" -X POST -d \
'<TargetServer  name="target2">
  <Host>2.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Esempio di risposta:

{
  "host" : "2.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target2",
  "port" : 80
}

Utilizza la seguente chiamata API per recuperare un elenco di TargetServers in un ambiente:

$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Esempio di risposta:

[ "target2", "target1" ]

Ora sono disponibili due TargetServer utilizzabili dai proxy API di cui è stato eseguito il deployment nell'ambiente di test. Per bilanciare il carico del traffico tra questi TargetServer, devi configurare la connessione HTTP nell'endpoint di destinazione di un proxy API in modo da utilizzare TargetServer.

Esiste un limite di 500 TargetServer per ambiente, come documentato nell'argomento Limiti.

Configurazione di un TargetEndpoint per bilanciare il carico tra TargetServer denominati

Ora che hai a disposizione due TargetServer, puoi modificare l'impostazione di connessione HTTP TargetEndpoint per fare riferimento a questi due TargetServer per nome:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Server name="target1" />
      <Server name="target2" />
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

La configurazione riportata sopra è la configurazione di bilanciamento del carico più di base possibile. Il bilanciatore del carico supporta tre algoritmi di bilanciamento del carico: Round Robin, weight e Least Connection. Round robin è l'algoritmo predefinito. Poiché nella configurazione precedente non è specificato alcun algoritmo, le richieste in uscita dal proxy API ai server di backend si alternano, una per uno, tra target 1 e target 2.

L'elemento <Path> forma il percorso base dell'URI TargetEndpoint per tutti i server di destinazione. Viene usato solo quando si usa <LoadBalancer>. In caso contrario, viene ignorato. Nell'esempio precedente, una richiesta che raggiunge "target1" sarà http://target1/test, e così via per altri server di destinazione.

Impostazione delle opzioni del bilanciatore del carico

Puoi ottimizzare la disponibilità utilizzando le opzioni per il bilanciamento del carico e il failover a livello di bilanciatore del carico e TargetServer. In questa sezione sono descritte queste opzioni.

Algoritmo

Imposta l'algoritmo utilizzato da <LoadBalancer>. Gli algoritmi disponibili sono RoundRobin, Weighted e LeastConnections, ognuno dei quali è documentato di seguito.

Round robin

L'algoritmo predefinito, round robin, inoltra una richiesta a ciascun TargetServer nell'ordine in cui i server sono elencati nella connessione HTTP dell'endpoint di destinazione. Ad esempio:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Somma

L'algoritmo di bilanciamento del carico ponderato consente di configurare carichi di traffico proporzionali per i TargetServer. Il LoadBalancer ponderato distribuisce la richiesta ai tuoi TargetServer in proporzione diretta alla ponderazione di ogni TargetServer. Di conseguenza, l'algoritmo ponderato richiede che venga impostato un attributo weight per ogni TargetServer. Ad esempio:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>Weighted</Algorithm>
      <Server name="target1">
        <Weight>1</Weight>
      </Server>
      <Server name="target2">
        <Weight>2</Weight>
      </Server>
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

In questo esempio, due richieste verranno instradate a target2 per ogni richiesta instradata a target1.

Connessione minima

I LoadBalancer configurati per utilizzare l'algoritmo con meno connessioni instradano le richieste in uscita a TargetServer con il minor numero di connessioni HTTP aperte. Ad esempio:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

Numero massimo di errori

Il numero massimo di richieste non riuscite dal proxy API a TargetServer che comporta il reindirizzamento della richiesta a un altro TargetServer.

Un errore di risposta significa che Apigee non riceve alcuna risposta da un server di destinazione. In questi casi, il contatore degli errori viene incrementato di uno.

Tuttavia, quando Apigee riceve una risposta da una destinazione, anche se la risposta è un errore HTTP (come 500), viene conteggiata una risposta dal server di destinazione e il contatore di errori viene reimpostato. Per garantire che le risposte HTTP non corrette (come 500) aumentino anche il contatore degli errori, in modo da rimuovere il prima possibile la rotazione di un server in stato non integro dalla rotazione del bilanciamento del carico, puoi aggiungere l'elemento <ServerUnhealthyResponse> con gli elementi secondari <ResponseCode> alla configurazione del bilanciatore del carico. Inoltre, Edge conteggerà le risposte con questi codici come errori.

Nell'esempio seguente, la rotazione target1 verrà rimossa dopo cinque richieste non riuscite, incluse alcune risposte 5XX del server di destinazione.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
        <ServerUnhealthyResponse>
            <ResponseCode>500</ResponseCode>
            <ResponseCode>502</ResponseCode>
            <ResponseCode>503</ResponseCode>
        </ServerUnhealthyResponse>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Il valore predefinito di MaxFailures è 0. Ciò significa che Edge tenta sempre di connettersi alla destinazione per ogni richiesta e non rimuove mai il server di destinazione dalla rotazione.

È preferibile utilizzare MaxFailures > 0 con un HealthMonitor. Se configuri MaxFailures > 0, TargetServer viene rimosso dalla rotazione quando il target non supera il numero di volte indicato. Quando viene attivato un HealthMonitor, Apigee riporta automaticamente la rotazione di TargetServer dopo che il target è di nuovo attivo e in esecuzione, in base alla configurazione di tale HealthMonitor. Per ulteriori informazioni, consulta Monitoraggio dello stato di integrità.

In alternativa, se configuri MaxFailures > 0 e non configuri HealthMonitor, Apigee non includerà automaticamente di nuovo TargetServer nella rotazione dopo che Apigee rileva un errore. In questo caso, devi eseguire nuovamente il deployment del proxy API prima che Apigee esegua di nuovo la rotazione di TargetServer. Vedi Deployment di un proxy API.

Riprova

Se è abilitato il nuovo tentativo, verrà tentata un'altra richiesta ogni volta che si verifica un errore di risposta (errore I/O o timeout HTTP) o la risposta ricevuta corrisponde a un valore impostato da <ServerUnhealthyResponse>. Consulta la sezione Numero massimo di errori qui sopra per saperne di più sull'impostazione di <ServerUnhealthyResponse>.

Il valore predefinito di <RetryEnabled> è true. Imposta su false per disattivare il nuovo tentativo. Ad esempio:

<RetryEnabled>false</RetryEnabled>

IsFallback

È possibile impostare un (e uno solo) TargetServer come server di "fallback". TargetServer di riserva non è incluso nelle routine di bilanciamento del carico finché tutti gli altri TargetServer non vengono identificati come non disponibili dal bilanciatore del carico. Quando il bilanciatore del carico determina che tutti i TargetServer non sono disponibili, tutto il traffico viene instradato al server di fallback. Ad esempio:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <Server name="target3">
          <IsFallback>true</IsFallback>
        </Server>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

La configurazione riportata sopra genera il bilanciamento del carico round robin tra i target 1 e 2 finché non sono disponibili entrambi i target 1 e 2. Quando i target 1 e 2 non sono disponibili, tutto il traffico viene instradato alla destinazione 3.

Percorso

Il percorso definisce un frammento URI che verrà aggiunto a tutte le richieste inviate da TargetServer al server di backend.

Questo elemento accetta un percorso stringa letterale o un modello di messaggio. Un modello di messaggio consente di sostituire le stringhe di variabili in fase di runtime. Ad esempio, nella seguente definizione dell'endpoint di destinazione, per il percorso viene utilizzato il valore di {mypath}:

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

Configurazione di un server di destinazione per TLS/SSL

Se utilizzi TargetServer per definire il servizio di backend e il servizio di backend richiede la connessione per utilizzare il protocollo HTTPS, devi abilitare TLS/SSL nella definizione di TargetServer. Questa operazione è necessaria perché il tag <Host> non consente di specificare il protocollo di connessione. Di seguito è riportata la definizione di TargetServer per TLS/SSL unidirezionale, in cui Edge invia richieste HTTPS al servizio di backend:

<TargetServer name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo> 
</TargetServer>

Se il servizio di backend richiede TLS/SSL bidirezionale o reciproco, configura TargetServer utilizzando le stesse impostazioni di configurazione TLS/SSL di TargetEndpoints:

<TargetServer  name="TargetServer 1">
    <IsEnabled>true</IsEnabled>
    <Host>www.example.com</Host>
    <Port>443</Port>
    <SSLInfo>
        <Ciphers/>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <Enabled>true</Enabled>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <KeyAlias>keystore-alias</KeyAlias>
        <KeyStore>keystore-name</KeyStore>
        <Protocols/>
        <TrustStore>truststore-name</TrustStore>
    </SSLInfo>
</TargetServer >

Per informazioni sulle proprietà <SSLInfo>, come <Ciphers> e <ClientAuthEnabled>, consulta le informazioni sull'impostazione di queste proprietà per un host virtuale in Configurazione dell'accesso TLS a un'API per il cloud privato.

Per istruzioni complete sulla configurazione di TLS/SSL in uscita, consulta Configurazione di TLS da Edge al backend (cloud e cloud privato).

Schema TargetServer

Consulta lo schema per TargetServer e altre entità su GitHub.

Monitoraggio della salute

Il monitoraggio dello stato di integrità consente di migliorare le configurazioni di bilanciamento del carico eseguendo il polling attivo degli URL dei servizi di backend definiti nelle configurazioni TargetServer. Con il monitoraggio di integrità abilitato, un TargetServer non riuscito viene automaticamente reinserito in rotazione quando HealthMonitor determina che TargetServer è attivo.

Il monitoraggio della salute funziona con <MaxFailures>. Se il monitoraggio di integrità non è abilitato, <MaxFailures> specifica il numero di richieste non riuscite dal proxy API a TargetServer, che comporta il reindirizzamento della richiesta a un altro TargetServer. TargetServer non funzionante viene quindi tolto dalla rotazione fino a quando non esegui nuovamente il deployment del proxy.

Con il monitoraggio di integrità abilitato, un TargetServer non riuscito viene automaticamente reinserito in rotazione e non sono necessari ulteriori deployment del proxy.

HealthMonitor funge da client semplice che richiama un servizio di backend su TCP o HTTP:

• Un client TCP assicura semplicemente che un socket possa essere aperto.
• Devi configurare il client HTTP in modo che invii una richiesta HTTP valida al servizio di backend. Puoi definire operazioni HTTP GET, PUT, POST o DELETE. La risposta alla chiamata di monitoraggio HTTP deve corrispondere alle impostazioni configurate nel blocco <SuccessResponse>.

Successi e errori

Quando abiliti il monitoraggio di integrità, Edge inizia a inviare controlli di integrità al server di destinazione. Un controllo di integrità è una richiesta inviata al server di destinazione che determina se il server di destinazione è integro o meno.

Un controllo di integrità può avere uno di due possibili risultati:

• Operazione riuscita:il server di destinazione viene considerato integro quando un controllo di integrità ha esito positivo. In genere questo è il risultato di una o più delle seguenti situazioni:
  • Il server di destinazione accetta una nuova connessione alla porta specificata, risponde a una richiesta su quella porta e poi chiude la porta entro il periodo di tempo specificato. La risposta del server di destinazione contiene "Connessione: chiusura"
  • Il server di destinazione risponde a una richiesta di controllo di integrità con un codice di stato HTTP 200 (OK) o altro codice che ritieni accettabile.
  • Il server di destinazione risponde a una richiesta di controllo di integrità con un corpo del messaggio corrispondente a quello previsto.

  Quando Edge determina che un server è integro, continua o riprende l'invio delle richieste al server.

• Errore: il server di destinazione può non superare un controllo di integrità in diversi modi, a seconda del tipo di controllo. È possibile che venga registrato un errore quando il server di destinazione:
  • Rifiuta una connessione da Edge alla porta per il controllo di integrità.
  • Non risponde a una richiesta di controllo di integrità entro un determinato periodo di tempo.
  • Restituisce un codice di stato HTTP imprevisto.
  • Risponde con un corpo del messaggio che non corrisponde a quello previsto.

  Quando un server di destinazione non supera un controllo di integrità, Edge incrementa il numero di errori del server. Se il numero di errori per il server soddisfa o supera una soglia predefinita (<MaxFailures>), Edge interrompe l'invio di richieste al server.

Attivazione di un HealthMonitor

Per creare un HealthMonitor, aggiungi l'elemento <HealthMonitor> alla configurazione HTTPConnection di TargetEndpoint per un proxy. Non puoi eseguire questa operazione nell'interfaccia utente. Puoi invece creare una configurazione proxy e caricarla come file ZIP su Edge. Una configurazione proxy è una descrizione strutturata di tutti gli aspetti di un proxy API. Le configurazioni del proxy consistono in file XML in una struttura di directory predefinita. Per ulteriori informazioni, consulta la documentazione sulla configurazione del proxy API.

Un HealthMonitor semplice definisce un IntervalInSec combinato con un TCPMonitor o un HTTPMonitor. L'elemento <MaxFailures> specifica il numero massimo di richieste non riuscite dal proxy API a TargetServer, che comporta il reindirizzamento della richiesta a un altro TargetServer. Per impostazione predefinita, <MaxFailures> è pari a 0, il che significa che Edge non esegue alcuna azione correttiva. Quando configuri un monitoraggio di integrità, assicurati di impostare <MaxFailures> nel tag <HTTPTargetConnection> del tag <TargetEndpoint> su un valore diverso da zero.

TCPMonitor

La configurazione seguente definisce un HealthMonitor che esegue il polling di ogni TargetServer aprendo una connessione sulla porta 80 ogni cinque secondi. (la porta è facoltativa. Se non specificata, la porta TCPMonitor è la porta TargetServer.

• Se la connessione non riesce o richiede più di 10 secondi, il conteggio degli errori aumenta di 1 per quel TargetServer.
• Se la connessione ha esito positivo, il numero di errori per TargetServer viene reimpostato su 0.

Puoi aggiungere un HealthMonitor come elemento secondario dell'elemento HTTPTargetConnetion di TargetEndpoint, come mostrato di seguito:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
      <Path>/test</Path>
      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <TCPMonitor>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <Port>80</Port>
        </TCPMonitor>
      </HealthMonitor>
  </HTTPTargetConnection>
. . .

HealthMonitor con elementi di configurazione TCPMonitor

Nella tabella seguente vengono descritti gli elementi di configurazione di TCPMonitor:

Nome	Descrizione	Predefinito	Campo obbligatorio?
IsEnabled	Un valore booleano che attiva o disattiva HealthMonitor.	false	No
IntervalInSec	L'intervallo di tempo, in secondi, tra ogni richiesta TCP di polling.	0	Sì
ConnectTimeoutInSec	Tempo in cui deve essere stabilita la connessione alla porta TCP per essere considerata riuscita. La mancata connessione nell'intervallo specificato viene conteggiata come errore e incrementa il numero di errori del bilanciatore del carico per TargetServer.	0	Sì
Port	Campo facoltativo. La porta su cui verrà stabilita la connessione TCP. Se non specificata, la porta TCPMonitor è la porta TargetServer.	0	No

HTTPMonitor

Un HealthMonitor di esempio che utilizza un HTTPMonitor invierà una richiesta GET al servizio di backend una volta ogni cinque secondi. Nell'esempio riportato di seguito, viene aggiunta un'intestazione di autorizzazione di base HTTP al messaggio di richiesta. La configurazione della risposta definisce le impostazioni che verranno confrontate con la risposta effettiva del servizio di backend. Nell'esempio riportato di seguito, la risposta prevista è un codice di risposta HTTP 200 e un'intestazione HTTP personalizzata ImOK il cui valore è YourOK. Se la risposta non corrisponde, la richiesta viene trattata come errore dalla configurazione del bilanciatore del carico.

HTTPMonitor supporta i servizi di backend configurati per l'utilizzo dei protocolli HTTP e HTTPS unidirezionali. Tuttavia, non supporta quanto segue:

• HTTPS bidirezionale (chiamato anche TLS/SSL bidirezionale)
• Certificati autofirmati.

Tieni presente che tutte le impostazioni Richieste e risposte in un monitoraggio HTTP saranno specifiche per il servizio di backend che deve essere richiamato.

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <IsSSL>true</IsSSL>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
          <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>80</Port>
          <Verb>GET</Verb>
          <Path>/healthcheck</Path>
          <Header name="Authorization">Basic 12e98yfw87etf</Header>
          <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
          <Header name="ImOK">YourOK</Header>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
    

HealthMonitor con elementi di configurazione HTTPMonitor

Nella tabella seguente vengono descritti gli elementi di configurazione di HTTPMonitor:

Nome	Descrizione	Predefinito	Campo obbligatorio?
IsEnabled	Un valore booleano che attiva o disattiva HealthMonitor.	false	No
IntervalInSec	L'intervallo di tempo, in secondi, tra ogni richiesta di polling.	0	Sì
Request	Opzioni di configurazione per il messaggio di richiesta in uscita inviato da HealthMonitor a TargetServers nella rotazione. Il percorso non supporta le variabili.	N/A	Sì
IsSSL	Consente di specificare se utilizzare HTTPS (HTTP sicuro) per il monitoraggio delle connessioni. Valori potenziali: true: vengono utilizzati HTTPS. false: viene utilizzato il protocollo HTTP. Non specificato: utilizza la configurazione del server di destinazione.	false	No
ConnectTimeoutInSec	Tempo, in secondi, in cui deve essere completato l'handshake della connessione TCP al servizio HTTP affinché venga considerato un successo. La mancata connessione nell'intervallo specificato viene conteggiata come errore e incrementa il numero di errori del LoadBalancer per TargetServer.	0	No
SocketReadTimeoutInSec	Tempo, in secondi, durante il quale i dati devono essere letti dal servizio HTTP per essere considerati un esito positivo. La mancata lettura nell'intervallo specificato viene conteggiata come errore e incrementa il numero di errori del LoadBalancer per TargetServer.	0	No
Port	La porta su cui verrà stabilita la connessione HTTP al servizio di backend.	N/A	No
Verb	Il verbo HTTP utilizzato per ogni richiesta HTTP di polling al servizio di backend .	N/A	No
Path	Il percorso aggiunto all'URL definito in TargetServer. Utilizza l'elemento del percorso per configurare un "endpoint di polling" sul tuo servizio HTTP.	N/A	No
IncludeHealthCheckIdHeader	Consente di monitorare le richieste di controllo di integrità sui sistemi upstream. IncludeHealthCheckIdHeader accetta un valore booleano e il valore predefinito è false. Se lo imposti su true, esiste un Header denominato X-Apigee-Healthcheck-Id che viene inserito nella richiesta di controllo di integrità. Il valore dell'intestazione viene assegnato dinamicamente e assume il formato ORG/ENV/SERVER_UUID/N, dove ORG è il nome dell'organizzazione, ENV è il nome dell'ambiente, SERVER_UUID è un ID univoco che identifica MP e N è il numero di millisecondi trascorsi dal 1° gennaio 1970. Esempio di intestazione della richiesta risultante: X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123	false	No
Payload	Il corpo HTTP generato per ogni richiesta HTTP di polling. Tieni presente che questo elemento non è obbligatorio per le richieste GET.	N/A	No
SuccessResponse	Opzioni di corrispondenza per il messaggio di risposta HTTP in entrata generato dal servizio di backend sottoposto a polling. Le risposte che non corrispondono incrementano il numero di errori di 1.	N/A	No
ResponseCode	Il codice di risposta HTTP che dovrebbe ricevere dal TargetServer polled. Un codice diverso da quello specificato determina un errore e il conteggio viene incrementato per il servizio di backend sottoposto a polling. Puoi definire più elementi ResponseCode.	N/A	No
Headers	Un elenco di una o più intestazioni e valori HTTP che si prevede di ricevere dal servizio di backend polled. Eventuali intestazioni o valori HTTP nella risposta diversi da quelli specificati portano a un errore e il conteggio per TargetServer polling viene incrementato di 1. Puoi definire più elementi di intestazione.	N/A	No