Questa pagina esamina i tipi di bilanciatori del carico disponibili in Cloud Load Balancing e descrive come utilizzare le metriche di Cloud Monitoring esposte come SLI.
I servizi di bilanciamento del carico cloud spesso forniscono il primo punto di contatto per le applicazioni ospitate in Google Cloud. I bilanciatori del carico vengono instrumentati per fornire informazioni su traffico, disponibilità e latenza dei servizi Google Cloud che espongono; perciò i bilanciatori del carico spesso rappresentano un'ottima fonte di metriche SLI senza la necessità la strumentazione delle applicazioni.
Quando inizi, potresti scegliere di concentrarti sulla disponibilità come dimensione principale dell'affidabilità e crea SLI e SLO per misurare e generare avvisi su queste dimensioni. Questa pagina illustra l'implementazione esempi.
Per ulteriori informazioni, consulta quanto segue:
- Concetti sul monitoraggio dei servizi
- Documentazione per Cloud Load Balancing
- Elenco dei tipi di metriche
loadbalancing.googleapis.com
SLI e SLO di disponibilità
Per le applicazioni non UDP, viene usato un modello basato su richiesta lo SLI di disponibilità è il più appropriato, poiché le interazioni con il servizio vengono mappate in modo accurato alle richieste.
Per esprimere un SLI di disponibilità basato sulle richieste, utilizza la struttura TimeSeriesRatio per impostare un rapporto tra le richieste valide e quelle totali, come mostrato nei seguenti esempi di disponibilità.
Per arrivare alla tua determinazione preferita di "buona" o "valido", filtri
utilizzando le etichette disponibili.
Bilanciatore del carico di livello esterno 7 (HTTP/S)
I bilanciatori del carico HTTP/S vengono utilizzati per esporre le applicazioni a cui si accede tramite HTTP/S e per distribuire il traffico alle risorse situate in più regioni.
I bilanciatori del carico delle applicazioni esterni scrivono i dati delle metriche in Monitoraggio utilizzando il tipo di risorsa monitorata https_lb_rule e i tipi di metriche con il prefisso loadbalancing.googleapis.com. Il tipo di metrica più pertinente per gli SLO di disponibilità è https/request_count, che puoi filtrare utilizzando l'etichetta della metrica response_code_class.
Se scegli di non conteggiare come "valide" le richieste che generano un codice di risposta di errore 4xx perché potrebbero indicare errori del client anziché del servizio o dell'applicazione, puoi scrivere il filtro per "totale" come segue:
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"!=\"400\"",
Devi anche stabilire come conteggiare i valori "buoni" richieste. Ad esempio, se scegli di conteggiare solo quelli che restituiscono un codice di risposta con stato di operazione riuscita 200 OK, puoi scrivere il filtro "Buono" nel seguente modo:
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"=\"200\"",
Puoi quindi esprimere uno SLI basato su richiesta come questo:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"!=\"400\"",
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"=\"200\"",
}
}
},
Per le applicazioni in cui il traffico è gestito da più backend, puoi scegliere
per definire gli SLI per un backend specifico. Per creare uno SLI di disponibilità per un
un backend specifico, utilizza
Metrica https/backend_request_count
con l'etichetta della risorsa backend_target_name nei filtri,
come mostrato in questo esempio:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/backend_request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
resource.label.\"backend_target_name\"=\"my-app-backend\"
metric.label.\"response_code_class\"!=\"400\"",
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/backend_request_count\"
resource.type=\"https_lb_rule\" resource.label.\"url_map_name\"=\"my-app-lb\"
resource.label.\"backend_target_name\"=\"my-app-backend\"
metric.label.\"response_code_class\"=\"200\"",
}
}
}
Bilanciatore del carico di livello 7 (HTTP/S) interno
I bilanciatori del carico delle applicazioni interno scrivono i dati delle metriche in Monitoring utilizzando
internal_http_lb_rule il tipo di risorsa e le metriche monitorate con
prefisso loadbalancing.googleapis.com. Il tipo di metrica più pertinente per gli SLO di disponibilità è https/internal_request_count, che puoi filtrare utilizzando l'etichetta della metrica response_code_class.
Di seguito è riportato un esempio di SLI di disponibilità basata su richiesta:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/request_count\"
resource.type=\"internal_http_lb_rule\"
resource.label.\"url_map_name\"=\"my-internal-lb\"
metric.label.\"response_code_class\"!=\"400\"",
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/request_count\"
resource.type=\"internal_http_lb_rule\"
resource.label.\"url_map_name\"=\"my-internal-lb\"
metric.label.\"response_code_class\"=\"200\"",
}
}
},
Bilanciatori del carico di livello 3 (TCP)
I bilanciatori del carico TCP non forniscono metriche sulle richieste perché le applicazioni che li utilizzano potrebbero non essere basate sul modello richiesta-risposta. Nessuno dei
loadbalancing.googleapis.com metriche fornite da questi bilanciatori del carico donano
a SLI di buona disponibilità.
Per creare SLI di disponibilità per questi bilanciatori del carico, devi creare personalizzate o basate su log. Per ulteriori informazioni, consulta Utilizzare le metriche personalizzate o Utilizzare le metriche basate su log.
SLI e SLO di latenza
Per le applicazioni di richiesta-risposta, esistono due modi per scrivere gli SLO di latenza:
- come SLO basati sulle richieste.
- Come SLO basati su finestre.
SLO di latenza basata sulle richieste
Uno SLO basato su richiesta applica una soglia di latenza e conteggia la frazione di richieste che vengono completate sotto la soglia entro un determinato periodo di conformità. Un esempio di SLO basato su richieste è "Il 99% delle richieste viene completato in 100 ms in una finestra temporale continua di un'ora".
Per esprimere uno SLI di latenza basato sulle richieste, utilizza un
DistributionCut, come mostrato nella
i seguenti esempi di latenza.
Un singolo SLO basato su richiesta non è in grado di acquisire sia le prestazioni tipiche il degrado dell'esperienza utente, per cui la "coda" o le richieste più lente vedono tempi di risposta sempre più lunghi. Uno SLO per le prestazioni tipiche non supporta la comprensione della latenza finale. Per una discussione sulla latenza di coda, consulta la sezione "Preoccuparsi della coda" nel Capitolo 6: Monitoraggio di sistemi distribuiti di Site Reliability Engineering.
Per attenuare questa limitazione, puoi scrivere un secondo SLO che si concentri specificamente sulla latenza finale, ad esempio "Il 99,9% delle richieste viene completato in meno di 1000 ms in un periodo di 1 ora". La combinazione dei due SLO individua i cali della tipica esperienza utente e della latenza di coda.
SLO di latenza basate su finestre
Uno SLO basato su finestre definisce un criterio di idoneità per il periodo di tempo delle misurazioni e calcola il rapporto tra gli intervalli "buoni" e il numero totale di intervalli. Un esempio di SLO basato su finestre è "La metrica della latenza del 95° percentile è inferiore a 100 ms per almeno il 99% delle finestre di un minuto, in un periodo di 28 giorni":
- Un periodo di misurazione "buono" è un intervallo di un minuto in cui il 95% delle richieste ha una latenza inferiore a 100 ms.
- La misura della conformità è la frazione di questi periodi "buoni". Il servizio è conforme se questa frazione è pari ad almeno 0,99, calcolata nel periodo di conformità.
Devi utilizzare uno SLO basato su finestre se la metrica non elaborata a tua disposizione è un percentile di latenza, ovvero quando si verificano entrambe le seguenti condizioni:
- I dati vengono raggruppati in periodi di tempo (ad esempio in intervalli di un minuto).
- I dati sono espressi in gruppi percentile (ad es. p50, p90, p95, p99).
Per questo tipo di dati, ogni gruppo percentile indica il momento che suddivide i gruppi di dati sopra e sotto quel percentile. Ad esempio, un intervallo di un minuto con una metrica di latenza p95 di 89 ms indica che, per quel minuto, il servizio ha risposto al 95% delle richieste in 89 ms o meno.
Application Load Balancer esterno
I bilanciatori del carico delle applicazioni esterni utilizzano i seguenti tipi di metriche primarie per registrare la latenza:
https/total_latencies: una distribuzione della latenza calcolata dal momento in cui la richiesta è stata ricevuta dal proxy fino al momento in cui il proxy ha ricevuto l'ACK dal client sull'ultimo byte di risposta. Da utilizzare quando l'esperienza utente complessiva è di primaria importanza.https/backend_latencies: una distribuzione della latenza calcolate da quando la richiesta è stata inviata dal proxy al backend fino il proxy ha ricevuto dal backend l'ultimo byte di risposta. Da utilizzare per Misurare le latenze di backend specifici che gestiscono il traffico dietro il carico con il bilanciatore del carico di rete passthrough esterno regionale.
Queste metriche vengono scritte in base ai
https_lb_rule tipo di risorsa monitorata.
Latenza totale
In questo SLO di esempio si prevede che il 99% delle richieste rientri tra 0 e 100 latenza totale in un periodo continuativo di un'ora:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/total_latencies\"
resource.type=\"https_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Latenza di backend
In questo SLO di esempio, il 98% delle richieste allo SLO "my-app-backend" La latenza del target del backend è compresa tra 0 e 100 ms in un'ora in sequenza periodo:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/backend_latencies\"
resource.type=\"https_lb_rule\"
resource.label.\"backend_target_name\"=\"my-app-backend\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.98,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Bilanciatore del carico delle applicazioni interno
I bilanciatori del carico delle applicazioni interni utilizzano due tipi di metriche primarie per acquisire la latenza:
https/internal/total_latencies: una distribuzione della latenza calcolata dal momento in cui la richiesta è stata ricevuta dal proxy fino a quando il proxy non ha ricevuto ACK dal client sull'ultimo byte di risposta. Da utilizzare quando l'esperienza utente complessiva è di primaria importanza.https/internal/backend_latencies: una distribuzione della latenza calcolate da quando la richiesta è stata inviata dal proxy al backend fino il proxy ha ricevuto dal backend l'ultimo byte di risposta. Da utilizzare per Misurare le latenze di backend specifici che gestiscono il traffico dietro il carico con il bilanciatore del carico di rete passthrough esterno regionale.
Queste metriche vengono scritte in base al tipo di risorsa monitorata internal_http_lb_rule.
Latenza totale
Questo esempio di SLO prevede che il 99% delle richieste abbia una latenza totale compresa tra 0 e 100 ms in un periodo di un'ora:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/total_latencies\"
resource.type=\"internal_http_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Questo esempio di SLO prevede che il 99% delle richieste abbia una latenza totale compresa tra 0 e 100 ms in un periodo di un'ora.
Latenza di backend
Questo SLO di esempio prevede che il 98% delle richieste al "my-internal-backend" La latenza del target del backend è compresa tra 0 e 100 ms in un'ora in sequenza periodo:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/backend_latencies\"
resource.type=\"https_lb_rule\"
resource.label.\"backend_target_name\"=\"my-internal-backend\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.98,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Bilanciatore del carico di livello 3 (TCP) esterno
I bilanciatori del carico TCP esterni utilizzano un singolo tipo di metrica,
l3/external/rtt_latencies, che registra la distribuzione di
tempo di round trip misurato sulle connessioni TCP per i flussi del bilanciatore del carico esterni.
Questa metrica è scritta rispetto alla
tcp_lb_rule.
Questo esempio di SLO prevede che il 99% delle richieste abbia una latenza totale compresa tra 0 e 100 ms in un periodo di un'ora:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/l3/external/rtt_latencies\"
resource.type=\"tcp_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Bilanciatore del carico di livello 3 (TCP) interno
I bilanciatori del carico TCP interni utilizzano un unico tipo di metrica,
l3/internal/rtt_latencies, che registra la distribuzione del tempo di percorrenza misurato sulle connessioni TCP per i flussi del bilanciatore del carico interno.
Questa metrica è scritta rispetto alla
internal_tcp_lb_rule.
Questo esempio di SLO prevede che il 99% delle richieste abbia una latenza totale compresa tra 0 e 100 ms in un periodo di un'ora:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/l3/internal/rtt_latencies\"
resource.type=\"internal_tcp_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}