Servizi di richiesta-risposta

Un servizio di richiesta-risposta è un servizio in cui un cliente chiede esplicitamente il servizio di svolgere delle attività e attende che il lavoro venga completato correttamente. Il più esempi comuni di tali servizi sono:

  • Applicazioni web con cui gli utenti umani interagiscono direttamente tramite un browser.
  • Applicazioni mobile costituite da un'applicazione client sulla un cellulare e un backend API con cui interagisce il client.
  • Backend API utilizzati da altri servizi (anziché da utenti umani).

Per tutti questi servizi, l'approccio comune è iniziare con la disponibilità (misurando il rapporto tra le richieste andate a buon fine) e la latenza (misurando il rapporto tra richieste che vengono completate sotto una soglia temporale). Per ulteriori informazioni gli SLI di latenza e disponibilità, consulta Concetti sul monitoraggio dei servizi.

Per esprimere uno SLI di disponibilità basata sulla richiesta, utilizza il Struttura di TimeSeriesRatio per impostare un rapporto di richieste soddisfacenti rispetto alle richieste totali. Sei tu a decidere come filtrare la metrica per utilizzando le etichette disponibili per arrivare alla determinazione che preferisci "buon" o "valido".

Per esprimere uno SLI di latenza basato sulle richieste, utilizza un Struttura di DistributionCut.

Cloud Endpoints

Cloud Endpoints è un servizio per la gestione delle API. Ti permette di adottare un'API esistente ed esporla con autenticazione, quote e monitoraggio.

Endpoint viene implementato come proxy davanti a gRPC un server delle applicazioni. Misurando le metriche a livello di proxy, puoi correggere per gestire il caso in cui tutti i backend non sono disponibili e gli utenti riscontrano errori. Gli endpoint scrivono i dati nei tipi di metriche che iniziano con prefisso serviceruntime.googleapis.com.

Per ulteriori informazioni, consulta le seguenti risorse:

SLI di disponibilità

Cloud Endpoints scrive i dati delle metriche in Cloud Monitoring utilizzando Tipo di risorsa monitorata e runtime servizio api tipo di metrica api/request_count, in base al quale puoi filtrare utilizzando l'etichetta della metrica response_code per conteggiare "Buono" e "totale" richieste.

Per esprimere uno SLI di disponibilità basata su richiesta, crea un Struttura di TimeSeriesRatio per richieste soddisfacenti 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 primarie per acquisire la latenza:

  • api/request_latencies: una distribuzione di latenze in secondi per le richieste non di streaming. Da utilizzare per l'esperienza utente complessiva è di primaria importanza.
  • api/request_latencies_backend: una distribuzione di latenze di backend in secondi per le richieste non di streaming. Da utilizzare per per misurare direttamente le latenze dei backend.
  • api/request_latencies_overhead: una distribuzione di latenze di richiesta in secondi per le richieste non di streaming, escludendo di backend. Utilizzalo per misurare l'overhead introdotto Proxy endpoint.

Tieni presente che la latenza totale della richiesta è la somma del backend e dell'overhead e la latenza minima:

request_latencies = request_latencies_backend + request_latencies_overhead

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

Per esprimere uno SLI di latenza basato sulle richieste, utilizza un DistributionCut, come mostrato nella i seguenti esempi.

Lo SLO di esempio seguente prevede che il 99% di tutte le richieste nel progetto rientri tra 0 e 100 ms di latenza totale in un periodo continuativo 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": "99% requests under 100 ms"
}

Lo SLO di esempio seguente prevede che il 98% delle richieste rientri tra 0 e 100 ms di latenza di backend in un periodo in sequenza di un'ora:

{
  "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 il deployment scalare applicazioni containerizzate in modo rapido e sicuro. È destinata a astrae completamente la gestione dell'infrastruttura rispondendo ai cambiamenti facendo automaticamente lo scale up e lo scale down da zero quasi istantaneamente e addebitarti solo le risorse esatte che utilizzi.

Per ulteriori informazioni sull'osservabilità di Cloud Run. consulta le seguenti risorse:

SLI di disponibilità

Cloud Run scrive i dati delle metriche in Cloud Monitoring utilizzando cloud_run_revision tipo di risorsa monitorata e request_count tipo di metrica. Puoi filtrare i dati utilizzando response_code o response_code_class etichetta di metrica per conteggiare "Buono" e "totale" richieste.

Per esprimere uno SLI di disponibilità basata su richiesta, crea un Struttura di TimeSeriesRatio per richieste soddisfacenti 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 cloud_run_revision tipo di risorsa monitorata e tipo di metrica request_latencies. I dati sono una distribuzione di richieste in millisecondi per raggiungere la revisione. Puoi filtrare i dati per utilizzando l'etichetta metrica response_code o response_code_class se misurare esplicitamente la latenza di tutte le richieste o solo richieste.

Per esprimere uno SLI di latenza basato sulle richieste, utilizza un Struttura di DistributionCut. Le seguenti lo SLO di esempio prevede che il 99% delle richieste rientri in totale tra 0 e 100 ms latenza in un periodo continuativo di un'ora:

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

Cloud Functions

Cloud Functions è un servizio Functions as a Service scalabile con pagamento a consumo che esegue il codice senza dover gestire alcuna infrastruttura. Le funzioni vengono utilizzate in molti modelli di architettura per fare cose come gli eventi elaborazione, automazione e gestione delle richieste HTTP/S.

Per informazioni sull'osservabilità di Cloud Functions, consulta quanto segue:

SLI di disponibilità

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

Per esprimere uno SLI di disponibilità basata su richiesta, crea un Struttura di TimeSeriesRatio per richieste soddisfacenti 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 cloud_function tipo di risorsa monitorata e tipo di metrica function/execution_times. I dati è una distribuzione dei tempi di esecuzione delle funzioni in nanosecondi." Puoi filtrare i dati utilizzando status se devi specificare e misurare la latenza di tutte le esecuzioni o solo di quelle riuscite.

Per esprimere uno SLI di latenza basato sulle richieste, utilizza un Struttura di DistributionCut. Le seguenti lo SLO di esempio prevede che il 99% di tutte le esecuzioni di Cloud Functions tra 0 e 100 ms di latenza totale in un periodo continuativo 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": "99% requests under 100 ms"
}

App Engine

App Engine fornisce una piattaforma serverless completamente gestita per creare e per eseguire le applicazioni. Puoi scegliere tra due ambienti: standard o flessibile; Per ulteriori informazioni, vedi Scelta di un ambiente App Engine.

Per ulteriori informazioni su App Engine, consulta quanto segue:

SLI di disponibilità

App Engine scrive i dati delle metriche in Cloud Monitoring utilizzando gae_app tipo di risorsa monitorata e il tipo di metrica http/server/response_count. Puoi filtrare i dati utilizzando l'etichetta della metrica response_code per conteggiare i valori "buoni" e "totale" diverse.

Esprimi uno SLI di disponibilità basata su richiesta per App Engine creando un elemento TimeSeriesRatio delle richieste soddisfacenti alle richieste totali, come illustrato di seguito esempio:

"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, App Engine scrive i dati delle metriche in Cloud Monitoring utilizzando gae_app tipo di risorsa monitorata e il tipo di metrica http/server/response_latencies. Puoi filtrare i dati utilizzando l'etichetta della metrica response_code per conteggiare i valori "buoni" e "totale" eseguite.

Esprimi uno SLI di latenza basato sulle richieste per App Engine utilizzando un file DistributionCut alla struttura del centro di costo. Lo SLO dell'esempio seguente prevede che il 99% di tutte le richieste ricada tra 0 e 100 ms di latenza totale in un periodo continuativo 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": "99% 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 ti consente di connetterti, proteggere, controllare osserva i servizi. Istio può essere installato su GKE come (Cloud Service Mesh) o dall'utente dell'open source progetto. In entrambi i casi, Istio fornisce telemetria eccellente, con informazioni su traffico, errori e latenza per ogni servizio gestito dal mesh.

Per un elenco completo delle metriche Istio, consulta istio.io tipi di metriche.

SLI di disponibilità

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

Puoi filtrare i dati utilizzando l'etichetta della metrica response_code per conteggiare "buon" e "totale" richieste. Puoi anche usare destination_service_name etichetta della metrica per conteggiare le richieste per un servizio specifico.

Esprimi uno SLI di disponibilità basata sulla richiesta per un servizio in esecuzione GKE gestito dal mesh di servizi Istio creando una struttura TimeSeriesRatio soddisfa le 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 service/server/response_latencies e uno dei seguenti valori tipi di risorse monitorate:

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

Esprimi uno SLI di latenza basato sulla richiesta per un servizio in esecuzione GKE gestito dal mesh di servizi Istio mediante una struttura DistributionCut. Lo SLO dell'esempio seguente prevede che il 99% di tutte le richieste allo frontend la latenza totale del servizio è compresa tra 0 e 100 ms in un'ora in sequenza periodo:

{
  "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": "99% requests under 100 ms"
}