Utilizzo delle metriche di Cloud Load Balancing

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 indicatori SLI.

I servizi Cloud Load Balancing spesso forniscono il primo punto di accesso per le applicazioni ospitate in Google Cloud. I bilanciatori del carico vengono strumentati automaticamente per fornire informazioni su traffico, disponibilità e latenza dei servizi che espongono; pertanto, i bilanciatori del carico spesso fungono da eccellente fonte di metriche SLI senza la necessità di strumentazione dell'applicazione. Google Cloud

Quando inizi, potresti scegliere di concentrarti su disponibilità e latenza come dimensioni principali dell'affidabilità e creare indicatori di livello del servizio e obiettivi di livello del servizio per misurare e generare avvisi su queste dimensioni. Questa pagina fornisce esempi di implementazione.

Per ulteriori informazioni, consulta le seguenti risorse:

SLI e SLO di disponibilità

Per le applicazioni non UDP, l'indicatore SLI di disponibilità basato sulle richieste è il più appropriato, poiché le interazioni del servizio corrispondono perfettamente alle richieste.

Esprimi un indicatore SLI di disponibilità basato sulle richieste utilizzando la struttura TimeSeriesRatio per impostare un rapporto tra le richieste valide e il totale delle richieste, come mostrato negli esempi di disponibilità riportati di seguito. Per ottenere la determinazione "buono" o "valido" che preferisci, filtra la metrica utilizzando le etichette disponibili.

Bilanciatore del carico esterno di livello 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 Monitoring 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 le richieste che generano un codice di risposta di errore 4xx come "valide" perché potrebbero indicare errori del client anziché errori del servizio o dell'applicazione, puoi scrivere il filtro per "totale" nel seguente 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 anche determinare come conteggiare le richieste "buone". Ad esempio, se scegli di conteggiare solo quelli che restituiscono un codice di risposta di stato riuscito 200 OK, puoi scrivere il filtro per "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 un 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 viene gestito da più backend, potresti scegliere di definire gli indicatori SLI per un backend specifico. Per creare un indicatore 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 interno di livello 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 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 sulle richieste:

"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 indicatori del livello di servizio (SLI) di disponibilità.

Per creare indicatori 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 SLO di latenza:

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

SLO di latenza basati sulle richieste

Uno SLO basato sulle richieste applica una soglia di latenza e conteggia la frazione di richieste che vengono completate al di sotto della soglia in una determinata finestra di conformità. Un esempio di SLO basato sulle richieste è "Il 99% delle richieste viene completato in meno di 100 ms in una finestra mobile di un'ora".

Esprimi un SLI di latenza basato sulle richieste utilizzando una struttura DistributionCut, come mostrato negli esempi di latenza riportati di seguito.

Un singolo SLO basato sulle richieste non può acquisire sia le prestazioni tipiche sia il peggioramento dell'esperienza utente, in cui le richieste "di coda" o più lente vedono tempi di risposta sempre più lunghi. Un SLO per le prestazioni tipiche non supporta la comprensione della latenza finale. Per una discussione sulla latenza di coda, vedi la sezione "Worrying About Your Tail" nel capitolo 6: Monitoraggio dei sistemi distribuiti di Site Reliability Engineering.

Per mitigare questa limitazione, puoi scrivere un secondo SLO per concentrarti in modo specifico sulla latenza finale, ad esempio "Il 99,9% delle richieste viene completato in meno di 1000 ms in una finestra mobile di 1 ora". La combinazione dei due SLO registra i peggioramenti sia nell'esperienza utente tipica sia nella latenza di coda.

SLO di latenza basati su finestra

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 di latenza del 95° percentile è inferiore a 100 ms per almeno il 99% delle finestre di un minuto, in una finestra mobile 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 si verificano entrambe le seguenti condizioni:

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

Per questo tipo di dati, ogni gruppo di percentile indica il tempo che divide 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 acquisire 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 ACK dal client sull'ultimo byte di risposta. Utilizza questa opzione 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 a quando il proxy ha ricevuto dal backend l'ultimo byte di risposta. Utilizza 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

Questa SLO di esempio prevede che il 99% delle richieste rientri tra 0 e 100 ms di latenza totale 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 SLO prevede che il 98% delle richieste al target di backend "my-app-backend" rientri tra 0 e 100 ms di latenza in un periodo di un'ora continuativo:

{
  "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 ha ricevuto ACK dal client sull'ultimo byte di risposta. Utilizza questa opzione 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 a quando il proxy ha ricevuto dal backend l'ultimo byte di risposta. Utilizza 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

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

Questa SLO di esempio prevede che il 99% delle richieste rientri tra 0 e 100 ms di latenza totale in un periodo di un'ora.

Latenza di backend

Questo SLO prevede che il 98% delle richieste alla destinazione di backend "my-internal-backend" rientri tra 0 e 100 ms di latenza in un periodo di un'ora continuativo:

{
  "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 esterno di livello 3 (TCP)

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 sulle connessioni TCP per i flussi del bilanciatore del carico esterno.

Questa metrica viene scritta in base alla risorsa tcp_lb_rule.

Questa SLO di esempio prevede che il 99% delle richieste rientri tra 0 e 100 ms di latenza totale 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 singolo 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.

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