Bilanciamento del carico tra server di backend

Stai visualizzando la documentazione di Apigee X.
Visualizza la documentazione di Apigee Edge.

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

I TargetTarget disaccoppiano gli URL di endpoint in cemento dalle configurazioni TargetEndpoint. Invece di definire un URL concreto nella configurazione, puoi configurare uno o più server dei nomi. Quindi, a ogni TargetServer viene fatto riferimento per nome in una HTTPConnection di TargetEndpoint.

Video

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

Video Descrizione
Bilanciamento del carico utilizzando i server di destinazione API di bilanciamento del carico su server di destinazione.
Routing delle API basato sull'ambiente tramite server di destinazione Instradare un'API a un server di destinazione diverso in base all'ambiente.

Informazioni sulla configurazione di TargetServer

Una configurazione di TargetServer è composta da un nome, un host, un protocollo e una porta, con un elemento aggiuntivo che indica se il TargetServer è abilitato o meno.

Il seguente codice fornisce un esempio di una configurazione di TargetServer:

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

Per maggiori informazioni sull'API TargetServers, consulta organization.environments.targetservers.

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

Creazione TargetServer

Crea i TargetTarget utilizzando l'interfaccia utente o l'API Apigee come descritto nelle seguenti sezioni.

Interfaccia utente di Apigee

Per creare TargetServer utilizzando l'interfaccia utente di Apigee:

  1. Accedi alla UI di Apigee.
  2. Seleziona Admin > Environments > TargetServers.
  3. Nell'elenco a discesa Ambiente, seleziona l'ambiente in cui vuoi definire un nuovo TargetServer.

    L'interfaccia utente di Apigee visualizza un elenco dei TargetServer attuali nell'ambiente selezionato:

    Elenco dei server di destinazione

  4. Fai clic su +Server di destinazione per aggiungere un nuovo TargetServer all'ambiente selezionato.

    Viene visualizzata la finestra di dialogo Aggiungi server di destinazione:

    Finestra di dialogo Aggiungi server di destinazione

  5. Fai clic su Abilitato per attivare il nuovo TargetServer. definizione immediatamente dopo la creazione.

  6. Inserisci un nome, host, protocollo e porta nei campi forniti. Le opzioni per Protocollo sono HTTP o GRPC.

    Facoltativamente, puoi selezionare la casella di controllo SSL. Per ulteriori informazioni su questi campi, consulta TargetServers (video 4MV4D).

  7. Fai clic su Aggiungi.

    Apigee crea la nuova definizione di TargetServer.

  8. Dopo aver creato un nuovo TargetServer, puoi modificare il proxy dell'API e cambiare l'elemento <HTTPTargetConnection> per fare riferimento alla nuova definizione.

API Apigee

Le seguenti sezioni forniscono esempi di utilizzo dell'API Apigee per creare ed elencare TargetServers.

Per maggiori informazioni, consulta la pagina relativa all'API TargetServers.

Creazione di un TargetServer in un ambiente con l'API

Per creare un TargetServer denominato target1 che si connetta a 1.mybackendservice.com sulla porta 80, utilizza la seguente chiamata API:

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target1",
  "host": "1.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'

Dove $TOKEN è impostato sul token di accesso OAuth 2.0, come descritto in Ottenere un token di accesso OAuth 2.0. Per informazioni sulle opzioni curl utilizzate in questo esempio, consulta la sezione Utilizzare curl. Per una descrizione delle variabili di ambiente utilizzate, consulta la sezione Impostare le variabili di ambiente per le richieste API Apigee.

Quanto segue fornisce un esempio della risposta:

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

Crea un secondo TargetServer utilizzando la seguente chiamata API. Definendo due TargetServer, fornisci due URL che un TargetEndpoint può utilizzare per il bilanciamento del carico:

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target2",
  "host": "2.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'

Quanto segue fornisce un esempio della risposta:

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

Elenco dei TargetServer in un ambiente che utilizza l'API

Per elencare i TargetServer in un ambiente, utilizza la seguente chiamata API:

curl https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers \
  -H "Authorization: Bearer $TOKEN"

Quanto segue fornisce un esempio della risposta:

[ "target2", "target1" ]

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

Configurazione di un TargetEndpoint per il bilanciamento del carico su TargetServer denominati

Ora che hai disponibile due TargetServer, puoi modificare l'impostazione di connessione HTTP TargetEndpoint in modo che faccia riferimento a quei 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 base del bilanciamento del carico. Il bilanciatore del carico supporta tre algoritmi di bilanciamento del carico, Round Robin, Ponderato e Connessione minima. Round Robin è l'algoritmo predefinito. Poiché non è stato specificato alcun algoritmo nella configurazione riportata sopra, le richieste in uscita dal proxy API ai server di backend si alternano, una per una, tra target1 e target2.

L'elemento <Path> costituisce il percorso di base dell'URI TargetEndpoint per tutti i TargetServer. È usato solo quando viene usato <LoadBalancer>. In caso contrario, viene ignorata. Nell'esempio precedente, una richiesta indirizzata a target1 sarà http://target1/test e quindi per altri TargetServer.

Per ulteriori informazioni, consulta TargetEndpoint.

Configurazione delle opzioni del bilanciatore del carico

Per ottimizzare la disponibilità, configura le opzioni per bilanciamento del carico e failover a livello di bilanciatore del carico e di TargetServer come descritto nelle sezioni seguenti.

Algoritmo

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

Round robin

L'algoritmo predefinito, round robin, inoltra una richiesta a ogni TargetServer nell'ordine in cui 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>

Ponderato

L'algoritmo di bilanciamento del carico ponderato consente di configurare carichi di traffico proporzionale per i server di destinazione. Il bilanciatore del carico ponderato distribuisce le richieste ai tuoi TargetServer in proporzione diretta alla ponderazione di ogni TargetServer. Di conseguenza, l'algoritmo ponderato richiede l'impostazione di 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

LoadBalancer configurato per utilizzare il minor algoritmo di connessione che esegue il routing delle richieste in uscita verso 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

Numero massimo di richieste non riuscite dal proxy API al TargetServer, con il reindirizzamento della richiesta a un altro TargetServer.

Un errore di risposta indica che Apigee non riceve alcuna risposta da un TargetTarget. In questo caso, il contatore di errori aumenta di uno.

Tuttavia, quando Apigee riceve una risposta da un target, anche se è un errore HTTP (ad esempio 500), viene considerata una risposta dal TargetServer e il contatore di errori viene reimpostato. Per garantire che le risposte HTTP con errori (come 500) incrementino anche il contatore di errori al fine di eliminare il server non integro dalla rotazione del bilanciamento del carico il prima possibile, puoi aggiungere l'elemento <ServerUnhealthyResponse> con elementi secondari <ResponseCode> alla configurazione del bilanciatore del carico. Apigee conteggia anche le risposte con questi codici come errori.

Nell'esempio seguente, la rotazione target1 verrà rimossa dopo cinque richieste non riuscite, incluse alcune risposte 5XX da TargetServer.

<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 MaxFailurs è 0. Ciò significa che Apigee tenta sempre di connettersi al target per ogni richiesta e non rimuove mai il TargetServer dalla rotazione.

È meglio utilizzare MaxFailures > 0 con HealthMonitor. Se configuri MaxFailurs > 0, il TargetServer viene rimosso dalla rotazione quando il target non riesce a raggiungere il numero di volte indicato. Quando HealthMonitor è attivo, Apigee torna automaticamente alla rotazione del TargetServer dopo che il target è nuovamente in esecuzione, in base alla configurazione di HealthMonitor. Per ulteriori informazioni, consulta la sezione Monitoraggio della salute.

In alternativa, se configuri MaxFailures > 0 e non configuri uno strumento HealthMonitor, Apigee non includerà nuovamente il TargetServer nella rotazione automaticamente dopo che Apigee ha rilevato un errore. In questo caso, devi rieseguire il deployment del proxy API prima che Apigee riconosca il TargetServer. Vedi Deployment di un proxy API.

Riprova

Se viene attivato un nuovo tentativo, viene ripetuta una richiesta ogni volta che si verifica un errore di risposta (errore I/O o timeout HTTP) oppure quando la risposta ricevuta corrisponde a un valore impostato da <ServerUnhealthyResponse>. Consulta la sezione Numero massimo di errori sopra per ulteriori informazioni sull'impostazione <ServerUnhealthyResponse>.

Per impostazione predefinita, l'opzione <RetryEnabled> è impostata su true. Imposta su false per disattivare i nuovi tentativi. Ad esempio:

<RetryEnabled>false</RetryEnabled>

IsFallback

È possibile impostare un (e uno solo) TargetServer come server di riserva. Il TargetServer di riserva non è incluso nelle routine di bilanciamento del carico finché tutti gli altri TargetServer non sono 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 riserva. 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 consente il bilanciamento del carico round robin tra target1 e target2 finché target1 e target2 non sono disponibili. Quando target1 e target2 non sono disponibili, tutto il traffico viene instradato a target3.

Percorso

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

Questo elemento accetta un percorso stringa letterale o un modello di messaggio. Un modello di messaggio consente di eseguire una sostituzione di stringhe variabili in fase di esecuzione. Ad esempio, nella seguente definizione di endpoint di destinazione, viene utilizzato il valore {mypath} per il percorso:

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

Configurazione di un TargetServer per TLS/SSL

Se utilizzi un Server di destinazione per definire il servizio di backend e quest'ultimo 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 Apigee effettua le richieste HTTPS al servizio di backend:

{
  "name": "target1",
  "host": "mocktarget.apigee.net",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true"
  }
}

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

{
  "name": "TargetServer 1",
  "host": "www.example.com",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true",
    "clientAuthEnabled": "true",
    "keyStore": "keystore-name",
    "keyAlias": "keystore-alias",
    "trustStore": "truststore-name",
    "ignoreValidationErrors": "false",
    "ciphers": []
  }
}

Per creare un TargetServer con SSL utilizzando una chiamata API: 

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json"  \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
    "name": "TargetServer 1",
    "host": "www.example.com",
    "protocol": "http",
    "port": 443,
    "isEnabled": true,
    "sSLInfo":
    {
      "enabled":true,
      "clientAuthEnabled":true,
      "keyStore":"keystore-name",
      "keyAlias":"keystore-alias",
      "ciphers":[],
      "protocols":[],
      "clientAuthEnabled":true,
      "ignoreValidationErrors":false,
      "trustStore":"truststore-name"
    }
  }'

Monitoraggio della salute

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

Il monitoraggio dello stato di integrità funziona con <MaxFailures>. Se il monitoraggio dell'integrità non è abilitato, <MaxFailures> specifica il numero di richieste non riuscite dal proxy API al TargetServer, che reindirizza la richiesta a un altro TargetServer. Il errore di TargetServer viene deprecato dalla rotazione fino a quando non esegui nuovamente il deployment del proxy.

Con il monitoraggio dell'integrità abilitato, un TargetServer non riuscito viene reintegrato automaticamente e non è necessario eseguire nuovamente i 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.
  • Configura il client HTTP in modo che invii una richiesta HTTP valida al servizio di backend. Puoi definire operazioni GET, PUT, POST o DELETE in HTTP. La risposta della chiamata HTTP di monitoraggio deve corrispondere alle impostazioni configurate nel blocco <SuccessResponse>.

Riusciti e fallimenti

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

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

  • Operazione riuscita: il TargetServer è considerato integro quando viene eseguito un controllo di integrità riuscito. In genere, il risultato è uno o più dei seguenti elementi:
    • TargetServer accetta una nuova connessione alla porta specificata, risponde a una richiesta su tale porta e quindi chiude la porta entro il periodo di tempo specificato. La risposta dal TargetServer contiene Connection: close
    • TargetServer risponde a una richiesta di controllo di integrità con un 200 (OK) o un altro codice di stato HTTP da te stabilito come accettabile.
    • TargetServer risponde a una richiesta di controllo di integrità con un corpo di messaggi che corrisponde al corpo del messaggio previsto.

    Quando Apigee determina che un server è in stato integro, Apigee continua o riprende a inviare le richieste.

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

    Quando un TargetServer non supera un controllo di integrità, Apigee aumenta il conteggio degli errori del server. Se il numero di errori del server soddisfa o supera una soglia predefinita (<MaxFailures>), Apigee smette di inviare richieste al server.

Abilitazione di un HealthMonitor

Per creare un HealthMonitor, devi aggiungere l'elemento <HealthMonitor> alla configurazione HTTPConnection di TargetEndpoint per un proxy. Non puoi eseguire questa operazione nell'interfaccia utente. In alternativa, puoi creare una configurazione proxy e caricarla come file ZIP in Apigee. Una configurazione del proxy è una descrizione strutturata di tutti gli aspetti di un proxy API. Le configurazioni del proxy sono costituite da file XML in una struttura di directory predefinita. Per ulteriori informazioni, consulta la guida di riferimento alla configurazione del proxy API.

Un semplice HealthMonitor definisce un IntervalInSec combinato con un TCPMonitor o un HTTPMonitor. L'elemento <MaxFailures> specifica il numero massimo di richieste non riuscite dal proxy API al TargetServer, con il risultato che la richiesta viene reindirizzata a un altro TargetServer. Per impostazione predefinita, <MaxFailures> è 0, il che significa che Apigee non esegue alcuna azione correttiva. Quando configuri un monitor 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 richiedono più di 10 secondi, il numero di errori aumenta di 1 per il TargetServer.
  • Se la connessione ha esito positivo, il conteggio degli errori per TargetServer viene reimpostato su 0.

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

La tabella seguente descrive gli elementi di configurazione TCPMonitor:

Nome Descrizione Predefinito Required?
IsEnabled Un valore booleano che abilita o disabilita HealthMonitor. falso No
IntervalInSec Intervallo di tempo in secondi tra ciascuna 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 considerata come un errore, incrementando il conteggio degli errori del bilanciatore del carico per TargetServer. 0 Sì
Port (Facoltativo) La porta su cui verrà stabilita la connessione TCP. Se non è specificata, la porta TCPMonitor è la porta TargetServer. 0 No

Monitoraggio HTTP

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 HTTP di autorizzazione di base al messaggio della 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 verrà considerata come un errore dalla configurazione del bilanciatore del carico.

HTTPMonitor supporta i servizi di backend configurati per l'utilizzo di protocolli HTTP e unidirezionali HTTPS. Tuttavia, non supporta HTTPS bidirezionale, chiamato anche TLS/SSL bidirezionale.

Tieni presente che tutte le impostazioni di richiesta e risposta in un monitor HTTP saranno specifiche per il servizio di backend che deve essere richiamato.

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <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

La tabella seguente descrive gli elementi di configurazione di HTTPMonitor:

Nome Descrizione Predefinito Required?
IsEnabled Un valore booleano che abilita o disabilita HealthMonitor. falso No
IntervalInSec L'intervallo di tempo, in secondi, tra ogni richiesta di sondaggio. 0 Sì
Request

Opzioni di configurazione per il messaggio di richiesta in uscita inviato da HealthMonitoro ai TargetServer nella rotazione.

Il percorso non supporta le variabili.

 N/A Sì
ConnectTimeoutInSec Il tempo, in secondi, durante il quale l'handshake della connessione TCP al servizio HTTP deve essere completato per essere considerato un successo. La mancata connessione nell'intervallo specificato viene considerata come un errore, con un incremento del conteggio degli errori di LoadBalancer per TargetServer. 0 No
SocketReadTimeoutInSec Tempo, in secondi, in cui i dati devono essere letti dal servizio HTTP per essere considerati riusciti. La lettura nell'intervallo specificato viene considerata come un errore, incrementando il conteggio degli errori di LoadBalancer per TargetServer. 0 No
Port La porta sulla quale 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 nel TargetServer. Utilizza l'elemento percorso per configurare un endpoint &'polling' sul tuo servizio HTTP. N/A No

IncludeHealthCheckIdHeader

 Consente di tenere traccia delle richieste di controllo di integrità sui sistemi upstream. IncludeHealthCheckIdHeader accetta un valore booleano ed è impostato come valore predefinito per 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 in modo dinamico e ha 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 l'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 		falso No
Payload Il corpo HTTP generato per ogni richiesta HTTP del sondaggio. Tieni presente che questo elemento non è richiesto per le richieste GET. N/A No
SuccessResponse Opzioni di corrispondenza per il messaggio di risposta HTTP in entrata generato dal servizio di backend con sondaggio. Le risposte che non corrispondono aumentano di 1 il numero di errori. N/A No
ResponseCode Il codice di risposta HTTP dovrebbe essere ricevuto dal TargetServer polled. Un codice diverso da quello specificato genera un errore e il conteggio viene incrementato per il servizio di backend con sondaggio. Puoi definire più elementi ResponseCode. N/A No
Headers Un elenco di una o più intestazioni HTTP e di valori che dovrebbero essere ricevuti dal servizio di backend con sondaggio. Eventuali intestazioni HTTP o valori nella risposta diversi da quelli specificati generano un errore, mentre il conteggio per il TargetServer polled viene incrementato di 1. Puoi definire più elementi intestazione. N/A No