Utilizzo delle metriche di Cloud Load Balancing

Questa pagina esamina i tipi di bilanciatori del carico disponibili da Cloud Load Balancing e descrive come utilizzare le metriche di Cloud Monitoring che mostrano come SLI.

I servizi di Cloud Load Balancing spesso forniscono il primo punto di ingresso per le applicazioni ospitate in Google Cloud. I bilanciatori del carico sono strumentati automaticamente per fornire informazioni su traffico, disponibilità e latenza dei servizi Google Cloud che presentano. Di conseguenza, fungono spesso da eccellente fonte di metriche SLI senza bisogno di strumentazione applicativa.

All'inizio, potresti scegliere di concentrarti su disponibilità e latenza come dimensioni principali dell'affidabilità e creare SLI e SLO per misurare e creare avvisi su 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 di loadbalancing.googleapis.com tipi di metriche

Nota: le stringhe di filtro in alcuni di questi esempi sono state sottoposte a wrapping per una migliore leggibilità.

SLI e SLO di disponibilità

Per le applicazioni non UDP, uno SLI di disponibilità basato su richiesta è il più appropriato, poiché le interazioni con i servizi sono mappate in modo ordinato alle richieste.

Per indicare uno SLI di disponibilità basato sulle richieste, puoi utilizzare la struttura TimeSeriesRatio per configurare un rapporto tra le richieste soddisfacenti e le richieste totali, come mostrato nei seguenti esempi di disponibilità. Per determinare lo stato "Buono" o "Valido" che preferisci, filtra la metrica in base alle 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 Monitoring utilizzando il tipo di risorsa monitorata https_lb_rule e i tipi di metrica con il prefissoloadbalancing.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 le richieste che generano un codice di risposta di errore 4xx come "valido" perché potrebbero indicare errori del client, anziché errori del servizio o dell'applicazione, puoi scrivere il filtro per "totale" in questo modo:

"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 inoltre determinare come conteggiare le richieste "valide". Ad esempio, se scegli di conteggiare solo quelli che restituiscono un codice di risposta di stato di operazione riuscita 200 OK, puoi 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 uno SLI basato su richiesta in questo modo:

"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, potresti scegliere di definire gli SLI per un backend specifico. Per creare uno 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 interno 7 (HTTP/S)

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 metrica 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 delle richieste perché le applicazioni che le utilizzano potrebbero non essere basate sul modello richiesta-risposta. Nessuna delle metriche loadbalancing.googleapis.com 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 Utilizzo delle metriche personalizzate o Utilizzo delle metriche basate su log.

SLI e SLO di latenza

Per le applicazioni richiesta-risposta, esistono due modi per scrivere gli SLO di latenza:

• Come SLO basati su richiesta.
• Come SLO basati su finestre.

SLO di latenza basata su richiesta

Uno SLO basato su richieste applica una soglia di latenza e conteggia la frazione di richieste completate sotto la soglia entro una determinata finestra di conformità. Un esempio di SLO basato su richiesta è "Il 99% delle richieste viene completato in meno di 100 ms in un intervallo continuativo di un'ora".

Esprimi uno SLI di latenza basato sulle richieste utilizzando una struttura DistributionCut, come mostrato nei seguenti esempi di latenza.

Uno SLO basato su una singola richiesta non è in grado di acquisire sia le prestazioni tipiche sia il peggioramento dell'esperienza utente, in cui le richieste "tail" o più lente registrano tempi di risposta sempre più lunghi. Uno SLO per le prestazioni tipiche non supporta la comprensione della latenza di coda. Per un'analisi della latenza di coda, consulta la sezione "Preoccuparsi della coda" nel Capitolo 6: Monitoraggio dei sistemi distribuiti di Site Reliability Engineering.

Per mitigare questa limitazione, puoi scrivere un secondo SLO per concentrarti specificamente sulla latenza di coda, ad esempio "Il 99,9% delle richieste viene completato in meno di 1000 ms in un periodo continuativo di 1 ora". La combinazione dei due SLO rileva i degradazioni sia dell'esperienza utente tipica che della latenza di coda.

SLO di latenza basati su finestre

Uno SLO basato su finestre definisce un criterio di idoneità per il periodo di tempo delle misurazioni e calcola il rapporto tra intervalli "buoni" e il numero totale di intervalli. Un esempio di SLO basato su finestra è "La metrica di latenza del 95° percentile è inferiore a 100 ms per almeno il 99% delle finestre di un minuto, in una finestra temporale 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 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 entrambe le seguenti condizioni sono vere:

• I dati sono raggruppati in periodi di tempo (ad esempio, in intervalli di un minuto).
• I dati sono espressi in gruppi percentili (ad esempio, p50, p90, p95, p99).

Per questo tipo di dati, ogni gruppo percentile indica il tempo che divide i gruppi di dati sopra e sotto tale 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.

Bilanciatore del carico delle applicazioni esterno

Gli Application Load Balancer esterni utilizzano i seguenti tipi di metriche principali per rilevare 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 ha ricevuto un ACK dal client nell'ultimo byte di risposta. Da usare quando l'esperienza utente complessiva è di importanza primaria.

• https/backend_latencies: una distribuzione della latenza calcolata dal momento in cui la richiesta è stata inviata dal proxy al backend fino a quando il proxy ha ricevuto dal backend l'ultimo byte di risposta. Per misurare le latenze di backend specifici che gestiscono il traffico dietro il bilanciatore del carico.

Queste metriche sono scritte in base al tipo di risorsa monitorata https_lb_rule.

Nota: entrambe le metriche hanno il tipo di valore DISTRIBUTION, il che significa che contengono istogrammi che rappresentano la distribuzione dei valori nei bucket. I limiti dei bucket per queste metriche vengono creati utilizzando potenze pari a 1,4, ovvero il primo bucket è 0-1,4, il secondo 1,4-1,96 e così via. Se hai requisiti di avviso molto precisi, potresti prenderlo in considerazione quando imposti le soglie, ma nella maggior parte dei casi è sufficiente fare affidamento sull'interpolazione per le soglie che rientrano in un bucket.

Latenza totale

Questo SLO di esempio prevede che il 99% delle richieste rientri tra 0 e 100 ms in 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 esempio, lo SLO prevede che il 98% delle richieste alla destinazione di backend "my-app-backend" rientri tra 0 e 100 ms in termini di latenza in un periodo continuativo 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

Gli Application Load Balancer interni utilizzano due tipi di metriche principali 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 ha ricevuto un ACK dal client nell'ultimo byte di risposta. Da usare quando l'esperienza utente complessiva è di importanza primaria.

• https/internal/backend_latencies: una distribuzione della latenza calcolata dal momento in cui la richiesta è stata inviata dal proxy al backend fino a quando il proxy ha ricevuto dal backend l'ultimo byte di risposta. 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.

Nota: entrambe le metriche hanno il tipo di valore DISTRIBUTION, il che significa che contengono istogrammi che rappresentano la distribuzione dei valori nei bucket. I limiti dei bucket per queste metriche vengono creati utilizzando potenze di 2 con una scala da 1e-06. Se hai requisiti di avviso molto precisi, potresti prenderlo in considerazione quando imposti le soglie, ma nella maggior parte dei casi è sufficiente fare affidamento sull'interpolazione per le soglie che rientrano in un bucket.

Latenza totale

Questo SLO di esempio prevede che il 99% delle richieste rientri tra 0 e 100 ms in latenza totale in un periodo continuativo 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 SLO di esempio prevede che il 99% delle richieste rientri tra 0 e 100 ms in latenza totale in un periodo continuativo di un'ora.

Latenza di backend

Questo SLO di esempio prevede che il 98% delle richieste alla destinazione di backend "my-internal-backend" rientri tra 0 e 100 ms in termini di latenza in un periodo continuativo 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 singolo tipo di metrica, l3/external/rtt_latencies, che registra la distribuzione del tempo di round trip misurato su connessioni TCP per i flussi del bilanciatore del carico esterni.

Questa metrica viene scritta in base alla risorsa tcp_lb_rule.

Questo SLO di esempio prevede che il 99% delle richieste rientri tra 0 e 100 ms in latenza totale in un periodo continuativo 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 interno 3 (TCP)

I bilanciatori del carico TCP interni utilizzano un singolo tipo di metrica, l3/internal/rtt_latencies, che registra la distribuzione del tempo di round trip misurato su connessioni TCP per i flussi del bilanciatore del carico interno.

Questa metrica viene scritta in base alla risorsa internal_tcp_lb_rule.

Questo SLO di esempio prevede che il 99% delle richieste rientri tra 0 e 100 ms in latenza totale in un periodo continuativo 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"
}