Questa pagina è stata tradotta dall'API Cloud Translation.

Servizi di richiesta-risposta

Un servizio di richiesta-risposta è un servizio in cui un cliente chiede esplicitamente al servizio di svolgere un'attività e attende che questa venga completata correttamente. Ecco alcuni esempi di questi servizi:

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 il client interagisce.
Back-end 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 le richieste riuscite) e di latenza (misurazione del rapporto tra le richieste completate in un determinato periodo di tempo). Per ulteriori informazioni sugli SLI di disponibilità e latenza, consulta Concetti di monitoraggio dei servizi.

Per esprimere un SLI di disponibilità basato su richiesta, utilizza la struttura TimeSeriesRatio per impostare un rapporto tra le richieste valide e le richieste totali. Puoi decidere come filtrare la metrica utilizzando le etichette disponibili per ottenere la determinazione preferita di "buono" o "valido".

Un SLI di latenza basato su richiesta viene espresso 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 applicazioni gRPC. Misurando le metriche nel proxy, puoi gestire correttamente la situazione in cui tutti i backend non sono disponibili e gli utenti visualizzano errori. Gli endpoint scrivono i dati nei tipi di metriche che iniziano con il prefisso serviceruntime.googleapis.com.

Per ulteriori informazioni, consulta le seguenti risorse:

Documentazione di Cloud Endpoints.
Elenco dei serviceruntime.googleapis.com tipi 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 api/request_count di runtime del servizio, che puoi filtrare utilizzando l'etichetta della metrica response_code per conteggiare le richieste "corrette" e "totali".

Per esprimere un SLI di disponibilità basato su richiesta, crea una struttura TimeSeriesRatio per le richieste valide 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 in streaming. Da utilizzare quando l'esperienza utente complessiva è di primaria importanza.
api/request_latencies_backend: una distribuzione delle latenze del backend in secondi per le richieste non in streaming. Utilizza questa metrica per misurare direttamente le latenze del backend.
api/request_latencies_overhead: una distribuzione delle latenze delle richieste in secondi per le richieste non in streaming, escluso il backend. Da utilizzare per misurare l'overhead introdotto dal proxy Endpoints.

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

request_latencies = request_latencies_backend + request_latencies_overhead

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

Un SLI di latenza basato su richiesta viene espresso utilizzando una struttura DistributionCut, come mostrato negli esempi riportati di seguito.

Lo SLO di esempio seguente prevede che il 99% di tutte le richieste del progetto abbia una latenza totale compresa tra 0 e 100 ms in 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": "99% requests under 100 ms"
}

L'esempio di SLO seguente prevede che il 98% delle richieste abbia una latenza del backend compresa tra 0 e 100 ms in un periodo 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 calcolo completamente gestita per eseguire il deployment e scalare applicazioni containerizzate in modo rapido e sicuro. È progettato per eliminare tutta la gestione dell'infrastruttura rispondendo alle variazioni del traffico facendo automaticamente lo scale up e lo scale down da zero in modo quasi istantaneo e addebitando solo le risorse esatte che utilizzi.

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

Documentazione di Cloud Run.
Elenco dei run.googleapis.com tipi 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_codeo response_code_class per conteggiare le richieste "corrette" e "totali".

Per esprimere un SLI di disponibilità basato su richiesta, crea una struttura TimeSeriesRatio per le richieste valide 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 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.

Un SLI di latenza basato su richiesta viene espresso utilizzando una struttura DistributionCut. Lo SLO di seguito prevede che il 99% delle richieste abbia una latenza totale compresa tra 0 e 100 ms in un periodo 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"
}

Funzioni Cloud Run

Le funzioni Cloud Run sono un'offerta Functions as a Service (FaaS) scalabile con pagamento a consumo che esegue il codice senza dover gestire alcuna infrastruttura. Le funzioni vengono utilizzate in molti pattern di architettura per eseguire operazioni come l'elaborazione degli eventi, l'automazione e il servizio delle richieste HTTP/S.

Per informazioni sull'osservabilità delle funzioni Cloud Run, consulta quanto segue:

Documentazione per le funzioni Cloud Run.
Elenco dei run.googleapis.com tipi di metriche.

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 "corrette" e "totali".

Per esprimere un SLI di disponibilità basato su richiesta, crea una struttura TimeSeriesRatio per le richieste valide 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.

Un SLI di latenza basato su richiesta viene espresso utilizzando una struttura DistributionCut. L'esempio di SLO riportato di seguito 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:

{
  "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 Scegliere un ambiente App Engine.

Per ulteriori informazioni su App Engine, consulta le seguenti risorse:

Documentazione di App Engine.
Elenco dei appengine.googleapis.com tipi 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 "buone" e "totali".

Per esprimere un SLI di disponibilità basato su richiesta per App Engine, crea una struttura TimeSeriesRatio per le richieste valide rispetto 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 metrica response_code per conteggiare le esecuzioni "corrette" e "totali".

Esprimi un SLI sulla latenza basato su richiesta per App Engine utilizzando una struttura DistributionCut. Lo SLO di esempio riportato di seguito prevede che il 99% di tutte le richieste abbia una latenza totale compresa tra 0 e 100 ms in 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": "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 plug-in (Cloud Service Mesh) o dall'utente dal progetto open source. In entrambi i casi, Istio fornisce una telemetria eccellente, incluse informazioni su traffico, errori e latenza per ogni servizio gestito dal mesh.

Per un elenco completo delle metriche di Istio, consulta i 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 "corrette" e "totali". Puoi anche utilizzare l'etichetta della metrica destination_service_name per conteggiare le richieste di un servizio specifico.

Puoi esprimere un 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 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 metrica response_code per conteggiare "good" and "total" requests. You can also use thedestination_service_name` l'etichetta metrica per conteggiare le richieste per un servizio specifico.

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

{
  "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"
}