Servizi di richiesta-risposta

Un servizio di richiesta/risposta è un servizio in cui un cliente chiede esplicitamente al servizio di svolgere qualche operazione e attende che l'operazione sia completata correttamente. Gli esempi più comuni di tali servizi sono:

  • Applicazioni web con cui gli utenti interagiscono direttamente con il browser.
  • Applicazioni per dispositivi mobili composte da un'applicazione client su un telefono cellulare di un utente e da un backend dell'API con cui interagisce il client.
  • Backend delle API utilizzati da altri servizi (invece che da utenti umani).

Per tutti questi servizi, l'approccio comune consiste nell'iniziare con la disponibilità (misurazione del rapporto tra le richieste riuscite) e la latenza (misurazione del rapporto tra le richieste completate entro una soglia di tempo). Per ulteriori informazioni sugli SLI di disponibilità e latenza, consulta Concetti nel monitoraggio dei servizi.

Per esporre uno SLI di disponibilità basato su richiesta, utilizza la struttura TimeSeriesRatio per configurare un rapporto tra le richieste buone e le richieste totali. Decidi come filtrare la metrica utilizzando le etichette disponibili per arrivare alla determinazione che preferisci "valida"; o valida.

Per esprimere uno SLI di latenza basato su richiesta, puoi utilizzare una struttura DistributionCut.

Cloud Endpoints

Cloud Endpoints è un servizio per la gestione delle API. Permette di prendere un'API esistente e di esporla con autenticazione, quote e monitoraggio.

Endpoints viene implementato come proxy davanti al server delle applicazioni ggC. Misurando le metriche del proxy, puoi gestire correttamente la richiesta quando tutti i backend non sono disponibili e gli utenti visualizzano degli errori. Endpoints scrive i dati nei tipi di metrica che iniziano con il prefisso serviceruntime.googleapis.com.

Per ulteriori informazioni, consulta i seguenti articoli:

SLI di disponibilità

Cloud Endpoints scrive i dati delle metriche in Cloud Monitoring utilizzando il tipo di risorsa monitorata api e il tipo di metrica api/request_count di runtime del servizio, che è possibile filtrare utilizzando l'etichetta della metrica response_code per conteggiare le richieste "good" e totali.

Per esprimere uno SLI di disponibilità basato su richiesta, crea una struttura TimeSeriesRatio per le richieste valide alle richieste totali, come mostrato nell'esempio seguente:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"serviceruntime.googleapis.com/api/request_count\"
         resource.type=\"api\"
         metric.label.\"response_code_class\"!=\"4xx\"",
      "goodServiceFilter":
        "metric.type=\"serviceruntime.googleapis.com/api/request_count\"
         resource.type=\"api\"
         (metric.label.\"response_code_class\"=\"1xx\"" OR
          metric.label.\"response_code_class\"=\"2xx\""),
    }
  }
}

SLI di latenza

Cloud Endpoints utilizza i seguenti tipi di metriche principali per acquisire la latenza:

  • api/request_latencies: una distribuzione delle latenze in secondi per le richieste non di streaming. Da utilizzare quando l'esperienza utente generale è di importanza primaria.
  • api/request_latencies_backend: distribuzione di latenze di backend in secondi per richieste non di streaming. Da utilizzare per misurare direttamente le latenze del backend.
  • api/request_latencies_overhead: distribuzione delle latenze delle richieste in secondi per le richieste non di streaming, escluso il backend. Da utilizzare per misurare l'overhead introdotto dal proxy Endpoints.

Tieni presente che la latenza totale delle richieste è la somma delle latenza di backend e overhead:

request_latencies = request_latencies_backend + request_latencies_overhead

Endpoints scrive i dati delle metriche in Cloud Monitoring utilizzando il tipo di risorsa monitorata e api e uno dei tipi di metriche di latenza della richiesta. Nessuno di questi tipi di metriche fornisce un'etichetta response_code o response_code_class; pertanto, segnalano le latenze per tutte le richieste.

Per esprimere uno SLI di latenza basato su richiesta, puoi utilizzare una struttura DistributionCut come illustrato negli esempi seguenti.

Il seguente SLO di esempio prevede che il 99% di tutte le richieste nel progetto rientri tra 0 e 100 ms di latenza totale su un periodo di un'ora:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"serviceruntime.googleapis.com/ap/request_latencies\"
           resource.type=\"api\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

L'SLO di esempio si aspetta che il 98% delle richieste rientri tra 0 e 100 ms di latenza backend in un periodo di un'ora continuativa:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"serviceruntime.googleapis.com/api/backend_latencies\"
           resource.type=\"api\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.98,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

Cloud Run

Cloud Run è una piattaforma di computing completamente gestita per eseguire il deployment e scalare applicazioni containerizzate in modo rapido e sicuro. È inteso a togliere ogni gestione all'infrastruttura rispondendo alle variazioni del traffico facendo automaticamente lo scale up e lo scale down da zero in modo quasi istantaneo e addebitandoti solo le risorse esatte che utilizzi.

Per ulteriori informazioni sull'osservabilità di Cloud Run, vedi quanto segue:

SLI di disponibilità

Cloud Run scrive i dati delle metriche in Cloud Monitoring utilizzando il tipo di risorsa monitorata cloud_run_revision e il tipo di metrica request_count. Puoi filtrare i dati utilizzando l'etichetta della metrica response_code o response_code_class per conteggiare le richieste"buone"e"totali";

Per esprimere uno SLI di disponibilità basato su richiesta, crea una struttura TimeSeriesRatio per le richieste valide alle richieste totali, come mostrato nell'esempio seguente:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"run.googleapis.com/request_count\"
         resource.type=\"cloud_run_revision\"
         metric.label.\"response_code_class\"!=\"4xx\"",
      "goodServiceFilter":
        "metric.type=\"run.googleapis.com/request_count\"
         resource.type=\"cloud_run_revision\"
         (metric.label.\"response_code_class\"=\"1xx\"" OR
          metric.label.\"response_code_class\"=\"2xx\""),
     }
  }
}

SLI di latenza

Per misurare la latenza, Cloud Run scrive i dati delle metriche in Cloud Monitoring utilizzando il tipo di risorsa monitorata cloud_run_revision e il tipo di metrica request_latencies. I dati sono una distribuzione della latenza delle richieste in millisecondi che raggiunge la revisione. Puoi filtrare i dati utilizzando l'etichetta della metrica response_code o response_code_class se devi misurare in modo esplicito la latenza di tutte le richieste o solo le richieste riuscite.

Per esprimere uno SLI di latenza basato su richiesta, puoi utilizzare una struttura DistributionCut. Il seguente SLO di esempio prevede che il 99% delle richieste rientri tra 0 e 100 ms di latenza totale nell'arco di un'ora:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"run.googleapis.com/https/request_latencies\"
           resource.type=\"cloud_run_revision"",
        "range": {
           "min": 0,
           "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

Cloud Functions

Cloud Functions è un'offerta Functions as a Service scalabile a consumo, che esegue il codice senza dover gestire alcuna infrastruttura. Le funzioni vengono utilizzate in molti modelli di architettura per eseguire operazioni quali l'elaborazione degli eventi, l'automazione e la gestione di richieste HTTP/S.

Per informazioni sull'osservabilità di Cloud Functions, vedi:

SLI di disponibilità

Cloud Functions scrive i dati delle metriche in Cloud Monitoring utilizzando il tipo di risorsa monitorata, cloud_function e il tipo di metrica function/execution_time. Puoi filtrare i dati utilizzando l'etichetta della metrica status per conteggiare le esecuzioni"buoni"e il totale.

Per esprimere uno SLI di disponibilità basato su richiesta, crea una struttura TimeSeriesRatio per le richieste valide alle richieste totali, come mostrato nell'esempio seguente:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"cloudfunctions.googleapis.com/function/execution_count\"
         resource.type=\"cloud_function\"",
      "goodServiceFilter":
        "metric.type=\"cloudfunctions.googleapis.com/function/execution_count\"
         resource.type=\"cloud_function\
         metric.label.\"status\"=\"ok\"",
     }
  }
}

SLI di latenza

Per misurare la latenza, Cloud Functions scrive i dati delle metriche in Cloud Monitoring utilizzando il tipo di risorsa monitorata cloud_function e il tipo di metrica function/execution_times. I dati sono una distribuzione dei tempi di esecuzione delle funzioni in nanosecondi. Puoi filtrare i dati utilizzando il criterio status se devi misurare esplicitamente la latenza di tutte le esecuzioni o solo delle esecuzioni riuscite.

Per esprimere uno SLI di latenza basato su richiesta, puoi utilizzare una struttura DistributionCut. Il seguente SLO di esempio prevede che il 99% di tutte le esecuzioni di Cloud Functions rientri in una latenza totale compresa tra 0 e 100 ms nell'arco di un'ora:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"cloudfunctions.googleapis.com/function/execution_times\"
           resource.type=\"cloud_function\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

App Engine

App Engine offre una piattaforma serverless completamente gestita per creare ed eseguire applicazioni. Puoi scegliere tra due ambienti, standard o flessibile. Per ulteriori informazioni, consulta Scelta di ambienti App Engine.

L'ambiente flessibile di App Engine non fornisce metriche che puoi utilizzare facilmente come SLI di disponibilità o latenza; consigliamo l'utilizzo di un Cloud Load Balancing o una metrica basata su log per gli SLI. Per ulteriori informazioni, consulta la seguente documentazione dello SLI:

Per ulteriori informazioni su App Engine, consulta quanto segue:

SLI di disponibilità

L'ambiente standard di App Engine scrive dati delle metriche in Cloud Monitoring utilizzando il tipo di risorsa monitorata gae_app e il tipo di metrica http/server/response_count. Puoi filtrare i dati utilizzando l'etichetta della metrica response_code per conteggiare le risposte "good" e "total".

Per esprimere uno standard SLI di disponibilità basato su richiesta per l'ambiente standard di App Engine, crea una struttura di tipo TimeSeriesRatio per le richieste buone alle richieste totali, come mostrato nell'esempio seguente:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"appengine.googleapis.com/http/server/response_count\"
         resource.type=\"gae_app\"
         metric.label.\"response_code\">\"499\"
         metric.label.\"response_code\"<\"399\"",
      "goodServiceFilter":
        "metric.type=\"appengine.googleapis.com/http/server/response_count\"
         resource.type=\"gae_app\"
         metric.label.\"response_code\"<\"299\"",
     }
  }
}

SLI di latenza

Per misurare la latenza, l'ambiente standard di App Engine scrive dati delle metriche in Cloud Monitoring utilizzando il tipo di risorsa gae_app monitorata e il tipo di metrica http/server/response_latencies. Puoi filtrare i dati utilizzando l'etichetta della metrica response_code per conteggiare le esecuzioni "good" e "total".

Per creare uno SLI di latenza basato su richiesta per un ambiente standard di App Engine, utilizza una struttura DistributionCut. Il seguente SLO di esempio prevede che il 99% di tutte le richieste rientri tra 0 e 100 ms di latenza totale su un periodo di un'ora:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"appengine.googleapis.com/http/server/response_latencies\"
           resource.type=\"gae_app\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

GKE e Istio

Google Kubernetes Engine (GKE) è il servizio Kubernetes protetto e gestito di Google con scalabilità automatica a quattro vie e supporto multi-cluster. Istio è un mesh di servizi open source che consente di connettere, proteggere, controllare e osservare i servizi. Istio può essere installato su GKE come componente aggiuntivo (Istio su GKE) oppure dall'utente nel progetto open source. In entrambi i casi, Istio fornisce un'eccellente telemetria, incluse informazioni su traffico, errori e latenza per ogni servizio gestito dal mesh.

Per un elenco completo delle metriche Istio, consulta la pagina relativa ai tipi di metriche istio.io.

SLI di disponibilità

Istio scrive i dati delle metriche in Cloud Monitoring utilizzando il tipo di metrica service/server/request_count e uno dei seguenti tipi di risorse monitorate:

Puoi filtrare i dati utilizzando l'etichetta della metrica response_code per conteggiare le richieste "buone" e "totali"; Puoi anche utilizzare l'etichetta della metrica destination_service_name per conteggiare le richieste di un servizio specifico.

Puoi esprimere uno SLI di disponibilità basato su richiesta per un servizio in esecuzione su GKE gestito dal mesh di servizi Istio creando una struttura TimeSeriesRatio per le richieste valide alle richieste totali, come mostrato nell'esempio seguente:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"istio.io/service/server/request_count\"
         resource.type=\"k8s_container\"
         metric.label.\"destination_service_name\"=\"frontend\"",
      "goodServiceFilter":
        "metric.type=\istio.io/server/response_count\"
         resource.type=\"k8s_container\"
         metric.label.\"destination_service_name\"=\"frontend\"
         metric.label.\"response_code\"<\"299\"",
    }
  }
}

SLI di latenza

Per misurare la latenza, Istio scrive i dati delle metriche in Cloud Monitoring utilizzando il tipo di metrica service/server/response_latencies e uno dei seguenti tipi di risorse monitorate:

Puoi filtrare i dati utilizzando l'etichetta della metrica response_code per conteggiare l'etichetta della metrica "good" and "total" requests. You can also use thedestination_service_name al fine di conteggiare le richieste di un servizio specifico.

Puoi esprimere uno SLI di latenza basato su richiesta per un servizio in esecuzione su GKE gestito dal mesh di servizi Istio utilizzando una struttura DistributionCut. L'SLO di esempio seguente prevede che il 99% di tutte le richieste al servizio frontend rientri tra 0 e 100 ms di latenza totale nell'arco di un'ora:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"istio.io/server/response_latencies\"
           resource.type=\"k8s_container\"
           metric.label.\"destination_service_name\"=\"frontend\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}