Un servizio di richiesta-risposta è un servizio in cui un cliente chiede esplicitamente al servizio di svolgere del lavoro e attende che tale lavoro venga completato correttamente. Gli esempi più comuni di questi servizi sono:
- Applicazioni web con cui gli utenti interagiscono direttamente tramite un browser.
- Applicazioni mobile costituite da un'applicazione client sul cellulare dell'utente e da un backend API con cui interagisce il client.
- Backend delle API utilizzati da altri servizi (invece che dagli utenti umani).
Per tutti questi servizi, l'approccio comune prevede di iniziare con gli SLI di disponibilità (misurando il rapporto delle richieste andate a buon fine) e con la latenza (misurando il rapporto di richieste che vengono completate entro una soglia di tempo). Per ulteriori informazioni sugli SLI di disponibilità e latenza, consulta Concetti relativi al monitoraggio dei servizi.
Per esprimere uno SLI di disponibilità basato sulle richieste puoi utilizzare la struttura TimeSeriesRatio per configurare un rapporto
tra richieste soddisfacenti e richieste totali. Decidi come filtrare la metrica utilizzando le etichette disponibili per determinare se "Buono" o "Valido" preferisci.
Esprimi uno SLI di latenza basato su richiesta utilizzando una struttura DistributionCut.
Cloud Endpoints
Cloud Endpoints è un servizio per la gestione delle API. Consente di prendere un'API esistente ed esporla con autenticazione, quote e monitoraggio.
Endpoints viene implementato come proxy davanti al server applicazioni gRPC. Se misuri le metriche a livello di proxy, puoi gestire correttamente il caso in cui tutti i backend non sono disponibili e gli utenti visualizzano errori.
Endpoints scrive i dati nei tipi di metrica a partire dal
prefisso serviceruntime.googleapis.com.
Per ulteriori informazioni, consulta le seguenti risorse:
- Documentazione per Cloud Endpoints.
- Elenco di
serviceruntime.googleapis.comtipi di metriche.
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 di runtime del servizio api/request_count, che puoi filtrare utilizzando l'etichetta della metrica response_code per conteggiare le richieste "valide" e "totali".
Per esprimere uno SLI di disponibilità basato sulle richieste, crei una struttura TimeSeriesRatio per le 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 principali per acquisire la latenza:
-
api/request_latencies: una distribuzione di latenze in secondi per le richieste non in streaming. Da utilizzare quando l'esperienza utente complessiva è di primaria importanza. -
api/request_latencies_backend: una distribuzione di latenze di backend in secondi per le richieste non in streaming. per misurare direttamente le latenze di backend. -
api/request_latencies_overhead: una distribuzione delle latenze di richiesta in secondi per le richieste non in streaming, escluso il backend. Da utilizzare per misurare l'overhead introdotto dal proxy per gli endpoint.
Tieni presente che la latenza totale delle richieste è la somma delle latenze di backend e di 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 metrica della richiesta-latenza.
Nessuno di questi tipi di metriche fornisce un'etichetta response_code o response_code_class, di conseguenza segnalano le latenze per tutte le richieste.
Esprimi uno SLI di latenza basato su richiesta utilizzando una struttura DistributionCut, come mostrato nei 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": "98% requests under 100 ms"
}
Lo SLO di esempio seguente prevede che il 98% delle richieste rientri tra 0 e 100 ms con latenza di backend in un periodo continuativo 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 e la scalabilità delle applicazioni containerizzate in modo rapido e sicuro. Il suo scopo è quello di rimuovere completamente la gestione dell'infrastruttura rispondendo ai cambiamenti del traffico facendo automaticamente lo scale up e lo scale down da zero quasi istantaneamente e addebitandoti solo le risorse esatte che utilizzi.
Per ulteriori informazioni sull'osservabilità di Cloud Run, vedi quanto segue:
- Documentazione per Cloud Run.
- Elenco di
run.googleapis.comtipi di metriche.
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 "valide" e "totali".
Per esprimere uno SLI di disponibilità basato sulle richieste, crei una struttura TimeSeriesRatio per le 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 il tipo di risorsa monitorata cloud_run_revision e il tipo di metrica request_latencies. I dati sono una distribuzione della latenza
della richiesta in millisecondi che raggiunge 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 andate a buon fine.
Esprimi uno 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 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": "98% requests under 100 ms"
}
Cloud Functions
Cloud 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, ad esempio, elaborare eventi, automazione e gestire richieste HTTP/S.
Per informazioni sull'osservabilità di Cloud Functions, vedi quanto segue:
- Documentazione per Cloud Functions.
- Elenco di
run.googleapis.comtipi di metriche.
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 "valide" e "totali".
Per esprimere uno SLI di disponibilità basato sulle richieste, crei una struttura TimeSeriesRatio per le 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 il tipo di risorsa monitorata cloud_function e il tipo di metrica function/execution_times. I dati sono una distribuzione di 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 uno SLI di latenza basato su richiesta utilizzando una struttura DistributionCut. Il seguente SLO di esempio prevede che il 99% di tutte le esecuzioni di Cloud Functions rientri 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": "98% 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 flessibili; per saperne di più, vedi Scelta di un ambiente App Engine.
Per ulteriori informazioni su App Engine, vedi quanto segue:
- Documentazione per App Engine.
- Elenco di
appengine.googleapis.comtipi di metriche.
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 "valide" e "totali".
Esprimi uno SLI di disponibilità basato sulle richieste per App Engine creando una struttura TimeSeriesRatio per le richieste soddisfacenti 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, 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 "valide" e "totali".
Esprimi uno SLI di latenza basato su richiesta per App Engine
utilizzando una struttura DistributionCut. Lo SLO di esempio seguente prevede che il 99% di tutte le richieste rientri
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": "98% requests under 100 ms"
}
GKE e Istio
Google Kubernetes Engine (GKE) è il servizio Kubernetes sicuro 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, Anthos Service Mesh, o dall'utente del progetto open source. In entrambi i casi, Istio fornisce dati di telemetria eccellenti, tra cui informazioni su traffico, errori e latenza, per ogni servizio gestito dal mesh.
Per un elenco completo delle metriche Istio, vedi istio.io tipi di metriche.
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 "valide" e "totali". Puoi utilizzare l'etichetta della metrica destination_service_name anche per conteggiare le richieste per un servizio specifico.
Esprimi uno 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 soddisfacenti 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 per un servizio specifico.
Esprimi uno SLI di latenza basato su richiesta per un servizio in esecuzione su GKE gestito dal mesh di servizi Istio utilizzando una struttura DistributionCut.
Lo SLO di esempio seguente prevede che il 99% di tutte le richieste al servizio frontend rientri tra 0 e 100 ms di latenza totale in un periodo continuativo 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"
}