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 il servizio di svolgere delle attività e attende che il lavoro venga completato 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".

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 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 di 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 primarie per acquisire la latenza:

api/request_latencies: una distribuzione di latenze in secondi per le richieste non di 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 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'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 nel progetto rientri tra 0 e 100 ms di latenza totale in un periodo in sequenza 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 calcolo completamente gestita per eseguire il deployment e 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 quanto segue:

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

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 l'etichetta della metrica response_codeo response_code_class per conteggiare le richieste "corrette" e "totali".

Puoi esprimere uno SLI di disponibilità basato su richiesta creando 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 della latenza delle richieste in millisecondi che raggiungono 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.

Un SLI di latenza basato su richiesta viene espresso utilizzando una struttura 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"
}

Funzioni Cloud Run

Cloud Run 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à delle funzioni Cloud Run, consulta quanto segue:

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

SLI di disponibilità

Cloud Run 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.

Puoi esprimere uno SLI di disponibilità basato su richiesta creando 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, 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 è 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. 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 e per eseguire le 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 tipi di metriche appengine.googleapis.com.

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 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 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 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 connetterti, proteggere, controllare osserva 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.

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