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 Cloud Load Balancing spesso forniscono il primo punto di contatto per le applicazioni ospitate in Google Cloud. I bilanciatori del carico vengono instrumentati automaticamente per fornire informazioni su traffico, disponibilità e latenza dei servizi Google Cloud che espongono. Pertanto, spesso fungono da eccellente fonte di metriche SLI senza la necessità di eseguire la misurazione dell'applicazione.
Quando inizi, puoi scegliere di concentrarti sulla disponibilità e sulla latenza come dimensioni principali dell'affidabilità e creare SLI e SLO per misurare e generare avvisi in base a queste dimensioni. Questa pagina fornisce esempi di implementazione.
Per ulteriori informazioni, consulta quanto segue:
- Concetti relativi al 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, un SLI di disponibilità basato su richieste è il più appropriato, poiché le interazioni con il servizio vengono mappate in modo preciso 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 determinazione preferita di "buono" o "valido", filtra la metrica utilizzando le etichette disponibili.
Bilanciatore del carico di livello 7 (HTTP/S) esterno
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 determinare come conteggiare le richieste "corrette". Ad esempio, se scelgo di conteggiare solo quelle che restituiscono un codice di risposta di stato di esito positivo 200 OK, posso scrivere il filtro per "buono" come segue:
"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 un SLI basato su richiesta come segue:
"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 viene gestito da più backend, puoi scegliere di definire gli SLI per un backend specifico. Per creare un SLI di disponibilità per un backend specifico, utilizza la 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 interni scrivono i dati delle metriche in Monitoring utilizzando il tipo di risorsa monitorata internal_http_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/internal_request_count, che puoi filtrare utilizzando l'etichetta della metrica response_code_class.
Di seguito è riportato un esempio di SLI di disponibilità basato 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. Nessuna delle
loadbalancing.googleapis.com metriche fornite da questi bilanciatori del carico si presta
a buoni SLI di disponibilità.
Per creare SLI di disponibilità per questi bilanciatori del carico, devi creare metriche 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 tipo richiesta-risposta, esistono due modi per scrivere SLO sulla latenza:
- Come SLO basati su richiesta.
- Come SLO basati su finestre.
SLO di latenza basate sulle richieste
Uno SLO basato sulle richieste applica una soglia di latenza e conteggia la frazione di richieste completate al di sotto della soglia in un determinato intervallo di conformità. Un esempio di SLO basato sulle richieste è "Il 99% delle richieste viene completato in meno di 100 ms in una finestra temporale continua di un'ora".
Un SLI di latenza basato su richiesta viene espresso utilizzando una struttura DistributionCut, come mostrato nei seguenti esempi di latenza.
Un singolo SLO basato sulle richieste non può acquisire sia le prestazioni tipiche sia il degrado dell'esperienza utente, in cui le richieste "in coda" o più lente registrano tempi di risposta sempre più lunghi. Uno SLO per le prestazioni tipiche non supporta la comprensione della latenza finale. Per una discussione sulla latenza coda, consulta la sezione "Preoccuparsi della coda" nel capitolo 6: Monitoraggio dei 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 consente di rilevare i degradi sia nell'esperienza utente tipica sia nella 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 è almeno pari a 0,99, calcolata durante il 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 principali per registrare la latenza:
https/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 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 calcolata dal momento in cui la richiesta è stata inviata dal proxy al backend fino al momento in cui il proxy ha ricevuto dal backend l'ultimo byte della risposta. Da utilizzare per misurare le latenze di backend specifici che gestiscono il traffico dietro il bilanciatore del carico.
Queste metriche vengono scritte in base al tipo di risorsa monitorata https_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/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
Questo esempio di SLO prevede che il 98% delle richieste al backend di destinazione "my-app-backend" abbia una latenza compresa tra 0 e 100 ms in un periodo dinamico di un'ora:
{
"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 principali di metriche 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 calcolata dal momento in cui la richiesta è stata inviata dal proxy al backend fino al momento in cui il proxy ha ricevuto dal backend l'ultimo byte della risposta. Da utilizzare per misurare le latenze di backend specifici che gestiscono il traffico dietro il bilanciatore del carico.
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 backend target "my-internal-backend" abbia una latenza compresa tra 0 e 100 ms in un periodo dinamico di un'ora:
{
"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 unico tipo di metrica,
l3/external/rtt_latencies, che registra la distribuzione del
tempo di round trip misurato sulle connessioni TCP per i flussi del bilanciatore del carico esterno.
Questa metrica viene scritta in base alla risorsa
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 round trip misurato sulle connessioni TCP per i flussi del bilanciatore del carico interno.
Questa metrica viene scritta in base alla risorsa 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"
}