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:
- Documentazione per Cloud Endpoints.
- Elenco di
serviceruntime.googleapis.com
tipi di metriche.
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:
- Documentazione per Cloud Run.
- Elenco di
run.googleapis.com
tipi di metriche.
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:
- Documentazione per Cloud Functions.
- Elenco di
run.googleapis.com
tipi di metriche.
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:
- Documentazione per App Engine
- Elenco di
appengine.googleapis.com
tipi di metriche.
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 the
destination_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"
}