Un servizio di richiesta-risposta è un servizio in cui un cliente chiede esplicitamente al servizio di eseguire un'attività e attende che venga completata correttamente. Gli esempi più comuni di questi servizi sono:
- Applicazioni web con cui gli utenti umani interagiscono direttamente utilizzando un browser.
- Applicazioni mobile costituite da un'applicazione client sullo smartphone di un utente e da 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 gli SLI di disponibilità (misurazione del rapporto tra richieste riuscite) e latenza (misurazione del rapporto tra richieste completate entro una soglia di tempo). Per ulteriori informazioni sugli indicatori di livello del servizio di disponibilità e latenza, consulta Concetti nel monitoraggio dei servizi.
Esprimi un SLI di disponibilità basato su richiesta utilizzando la struttura
TimeSeriesRatio per impostare un rapporto
tra le richieste valide e le richieste totali. Decidi come filtrare la metrica
utilizzando le etichette disponibili per ottenere la tua determinazione preferita di
"buono" o "valido".
Esprimi un SLI di latenza basato su richiesta utilizzando una struttura DistributionCut.
Cloud Endpoints
Cloud Endpoints è un servizio per la gestione delle API. Ti consente di prendere un'API esistente ed esporla con autenticazione, quote e monitoraggio.
Endpoints viene implementato come proxy davanti al server delle applicazioni gRPC. Misurando le metriche nel proxy, puoi gestire correttamente il caso in cui tutti i backend non sono disponibili e gli utenti visualizzano errori.
Gli endpoint scrivono i dati nei tipi di metrica che iniziano con il
prefisso serviceruntime.googleapis.com.
Per ulteriori informazioni, consulta le seguenti risorse:
- Documentazione per Cloud Endpoints.
- Elenco dei tipi di metrica
serviceruntime.googleapis.com.
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 service-runtime
api/request_count, che puoi filtrare utilizzando l'etichetta metrica response_code per conteggiare le richieste "buone" e "totali".
Esprimi un SLI di disponibilità basato su richiesta creando una struttura TimeSeriesRatio per le richieste soddisfacenti rispetto 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. Utilizza questa metrica quando l'esperienza utente complessiva è di primaria importanza. -
api/request_latencies_backend: una distribuzione delle latenze di backend in secondi per le richieste non di streaming. Utilizza to per misurare direttamente le latenze di backend. -
api/request_latencies_overhead: una distribuzione delle latenze delle richieste in secondi per le richieste non di streaming, escluso il backend. Utilizza questa metrica per misurare l'overhead introdotto dal proxy Endpoints.
Tieni presente che la latenza totale della richiesta è la somma delle latenze 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 api e uno dei tipi di metriche di latenza delle richieste.
Nessuno di questi tipi di metriche fornisce un'etichetta response_code o response_code_class, pertanto segnalano le latenze per tutte le richieste.
Esprimi un SLI di latenza basato su richiesta utilizzando una struttura DistributionCut, come mostrato 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 in un periodo di un'ora mobile:
{
"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"
}
Il seguente SLO prevede che il 98% delle richieste rientri tra 0 e 100 ms di latenza di backend in un periodo di un'ora mobile:
{
"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. È progettato per astrarre tutta la gestione dell'infrastruttura rispondendo alle variazioni di 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, consulta quanto segue:
- Documentazione per Cloud Run.
- Elenco dei tipi di metrica
run.googleapis.com.
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".
Esprimi un SLI di disponibilità basato su richiesta creando una struttura TimeSeriesRatio per le richieste soddisfacenti rispetto 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 raggiungono la revisione. Puoi filtrare i dati utilizzando l'etichetta della metrica response_code o response_code_class se devi misurare esplicitamente la latenza di tutte le richieste o solo di quelle riuscite.
Esprimi un SLI di latenza basato su richiesta utilizzando una struttura DistributionCut. Il seguente
SLO di esempio prevede che il 99% delle richieste rientri tra 0 e 100 ms di latenza totale
in un periodo di un'ora continuativo:
{
"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 Run Functions
Cloud Run Functions è un'offerta Functions-as-a-Service scalabile con pagamento a consumo che esegue il codice senza la necessità di gestire alcuna infrastruttura. Le funzioni vengono utilizzate in molti pattern di architettura per attività come l'elaborazione di eventi, l'automazione e la gestione di richieste HTTP/S.
Per informazioni sull'osservabilità di Cloud Run Functions, consulta quanto segue:
- Documentazione di Cloud Run Functions.
- Elenco dei tipi di metrica
run.googleapis.com.
SLI di disponibilità
Le funzioni Cloud Run scrivono 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 "buone" e "totali".
Esprimi un SLI di disponibilità basato su richiesta creando una struttura TimeSeriesRatio per le richieste soddisfacenti rispetto 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, le funzioni Cloud Run scrivono 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 status se devi misurare esplicitamente la latenza di tutte le esecuzioni o solo di quelle riuscite.
Esprimi un SLI di latenza basato su richiesta utilizzando una struttura DistributionCut. Il seguente
SLO di esempio prevede che il 99% di tutte le esecuzioni delle funzioni Cloud Run rientri
tra 0 e 100 ms di latenza totale in un periodo di un'ora mobile:
{
"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 ed eseguire applicazioni. Puoi scegliere tra due ambienti, standard o flessibile. Per ulteriori informazioni, consulta la sezione Scelta di un ambiente App Engine.
Per ulteriori informazioni su App Engine, consulta le seguenti risorse:
- Documentazione per App Engine.
- Elenco dei tipi di metrica
appengine.googleapis.com.
SLI di disponibilità
App Engine scrive i 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 "buone" e "totali".
Esprimi un indicatore SLI di disponibilità basato sulle richieste per App Engine
creando una struttura TimeSeriesRatio
per le richieste soddisfacenti rispetto alle richieste totali, come mostrato nel seguente
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 il tipo di risorsa monitorata
gae_app e il tipo di metrica
http/server/response_latencies.
Puoi filtrare i dati utilizzando l'etichetta della metrica response_code
per conteggiare le esecuzioni "buone" e "totali".
Esprimi un SLI di latenza basato su richiesta per App Engine
utilizzando 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 in un periodo di un'ora mobile:
{
"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 connettere, proteggere, controllare e osservare i servizi. Istio può essere installato su GKE come componente aggiuntivo, Cloud Service Mesh, o dall'utente dal progetto open source. In entrambi i casi, Istio fornisce un'ottima telemetria, incluse informazioni su traffico, errori e latenza per ogni servizio gestito dal mesh.
Per un elenco completo delle metriche Istio, consulta Tipi di metriche di 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 metrica destination_service_name
per conteggiare le richieste per un servizio specifico.
Esprimi un indicatore SLI di disponibilità basato sulle richieste per un servizio in esecuzione su GKE gestito dal mesh di servizi Istio creando una struttura TimeSeriesRatio per le richieste valide rispetto al totale delle richieste, 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` per conteggiare le richieste per un servizio specifico.
Esprimi un indicatore SLI di latenza basato sulle richieste per un servizio in esecuzione su
GKE gestito dal mesh di servizi Istio
utilizzando una struttura DistributionCut.
Il seguente SLO di esempio prevede che il 99% di tutte le richieste al servizio frontend
rientri tra 0 e 100 ms di latenza totale in un periodo di un'ora
continuo:
{
"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"
}