Questa pagina è stata tradotta dall'API Cloud Translation.

Servizi di archiviazione e recupero dei dati

I servizi di dati Google Cloud descritti in questa pagina includono quelli che archiviano e forniscono dati in risposta a una richiesta. Gli SLI per questi servizi sono simili agli SLI per i servizi di richiesta-risposta, descritti in Servizi di richiesta-risposta, con un'attenzione principale alla disponibilità e alla latenza. Tieni presente che la latenza, soprattutto quando si misura il tempo di risposta delle query del database, è spesso un fattore della quantità di dati recuperati e può variare in base al carico di lavoro dell'applicazione.

Per esprimere uno SLI di disponibilità basata sulla richiesta, utilizza il TimeSeriesRatio per configurare una rapporto "buono" richieste al totale richieste. Sei tu a decidere come filtrare la metrica utilizzando le etichette disponibili per arrivare alla tua determinazione preferita di "buona" o "valido".

Per esprimere uno SLI di latenza basato sulle richieste, utilizza un Struttura di DistributionCut.

Cloud Storage

Cloud Storage è l'archivio di oggetti a livello mondiale a elevata durabilità di Google Cloud. Cloud Storage è disponibile in più classi di archiviazione, che ti consentono di determinare il modello di costo e recupero appropriato per il tuo servizio o caso d'uso.

Per ulteriori informazioni, consulta quanto segue:

Documentazione di Cloud Storage.
Elenco di storage.googleapis.com tipi di metriche.

SLI di disponibilità

Cloud Storage scrive i dati delle metriche in Cloud Monitoring utilizzando gcs_bucket tipo di risorsa monitorata e tipo di metrica api/request_count. Puoi filtrare i dati utilizzando L'etichetta della metrica response_code per conteggiare "Buono" richieste. Puoi anche utilizzare l'etichetta della metrica method per misurare la disponibilità per uno specifico metodo API ad esempio ReadObject.

Puoi indicare uno SLI di disponibilità basata su richiesta per la lettura degli oggetti da un nel bucket Cloud Storage utilizzando un rapporto, TimeSeriesRatio, di richieste soddisfacenti al totale come mostrato nell'esempio seguente:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"storage.googleapis.com/api/request_count\"
         resource.type=\"gcs_bucket\"
         metric.label.\"method\"=\"ReadObject\"
         resource.label.\"bucket_name\"=\"my_bucket\"",
      "goodServiceFilter":
        "metric.type=\"storage.googleapis.com/api/request_count\"
         resource.type=\"gcs_bucket\"
         metric.label.\"method\"=\"ReadObject\"
         resource.label.\"bucket_name\"=\"my_bucket\"
         metric.label.\"response_code\"=\"OK\"",
    }
  }
}

SLI di latenza

Cloud Storage non fornisce una metrica di latenza; se la latenza è potresti instrumentare il tuo servizio per raccogliere questi dati sul client.

Bigtable

Bigtable è un servizio di database NoSQL scalabile e completamente gestito per carichi di lavoro analitici e operativi di grandi dimensioni. Bigtable è ideale per l'archiviazione di grandi quantità di dati in un archivio chiave-valore. Bigtable supporta inoltre un'elevata velocità effettiva di lettura e scrittura a bassa latenza, offrendo un accesso rapido a grandi quantità di dati.

Per ulteriori informazioni, consulta quanto segue:

Documentazione per Bigtable.
Elenco dei tipi di metriche bigtable.googleapis.com.

SLI di disponibilità

Bigtable scrive i dati delle metriche in Cloud Monitoring utilizzando bigtable_table tipo di risorsa monitorata e i seguenti tipi di metriche:

server/request_count, che conteggia il numero totale di richieste.
server/error_count, che conteggia il numero totale di richieste non andate a buon fine.

Puoi indicare uno SLI di disponibilità basata su richiesta per la lettura degli oggetti da un nel bucket Cloud Storage utilizzando un rapporto, TimeSeriesRatio, di "non buono" richieste al totale come mostrato nell'esempio seguente:

Puoi utilizzare queste due metriche per esprimere un SLI di disponibilità basato sulle richieste creando una struttura TimeSeriesRatio per le richieste non riuscite in base alle richieste totali, come mostrato nell'esempio seguente:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"bigtable.googleapis.com/server/request_count\"
         resource.type=\"bigtable_table\"
         resource.label.\"table\"=\"my_table\"
         resource.label.\"cluster\"=\"my_cluster\"",
      "badServiceFilter":
        "metric.type=\"bigtable.googleapis.com/server/error_count\"
         resource.type=\"bigtable_table\"
         resource.label.\"table\"=\"my_table\"
         resource.label.\"cluster\"=\"my_cluster\"",
    }
  }
}

SLI di latenza

Per misurare la latenza, Bigtable scrive i dati delle metriche in Cloud Monitoring utilizzando il tipo di risorsa monitorata bigtable_table e il tipo di metrica server/latencies. Puoi filtrare i dati utilizzando l'etichetta della metrica method per misurare le latenze di metodi specifici.

Per esprimere uno SLI di latenza basato sulle richieste, utilizza un Struttura di DistributionCut.

L'esempio di SLO seguente prevede che il 99% di tutte le richieste alla tabella my_table nel cluster my_cluster abbia una latenza totale compresa tra 0 e 100 ms in un periodo di un'ora:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"bigtable.googleapis.com/server/latencies\"
           resource.type=\"bigtable_table\"
           resource.label.\"table\"=\"my_table\"
           resource.label.\"cluster\"=\"my_cluster\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

Spanner

Spanner è un database relazionale completamente gestito che offre coerenza transazionale su scala globale, schemi, SQL (ANSI 2011 con estensioni) e replica sincrona automatica per la disponibilità del servizio.

Per ulteriori informazioni, consulta quanto segue:

Documentazione per Spanner
Elenco dei tipi di metriche spanner.googleapis.com.

SLI di disponibilità

Spanner scrive i dati delle metriche in Cloud Monitoring utilizzando il tipo di risorsa monitorata spanner_instance e il tipo di metrica query_count. Puoi filtrare i dati utilizzando l'etichetta della metrica status per conteggiare le query di database riuscite e non riuscite.

Puoi esprimere uno SLI di disponibilità basato su richiesta creando un Struttura di TimeSeriesRatio per "buon" da richieste a richieste totali, come mostrato nell'esempio seguente:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"spanner.googleapis.com/query_count\"
         resource.type=\"spanner_instance\"
         metric.label.\"database\"=\"my_database\"",
      "goodServiceFilter":
        "metric.type=\"spanner.googleapis.com/query_count\"
         resource.type=\"spanner_instance\"
         metric.label.\"database\"=\"my_database\"
         metric.label.\"status\"=\"ok\"",
    }
  }
}

SLI di latenza

Per misurare la latenza, Spanner scrive i dati delle metriche in Cloud Monitoring utilizzando spanner_instance tipo di risorsa monitorata e tipo di metrica api/request_latencies. Puoi filtrare i dati utilizzando l'etichetta della metrica method per misurare le latenze di metodi specifici. I dati includono le latenze non solo per le query, ma anche per altre chiamate dell'API Spanner.

Un SLI di latenza basato su richiesta viene espresso utilizzando una struttura DistributionCut. L'esempio di SLO seguente prevede che il 99% di tutte le richieste API al database my_database abbia una latenza totale compresa tra 0 e 100 ms in un periodo di un'ora:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"spanner.googleapis.com/api/request_latencies\"
           resource.type=\"spanner_instance\"
           metric.label.\"database\"=\"my_database\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

Datastore

Datastore è un database NoSQL a scalabilità elevata per le tue applicazioni. Datastore gestisce automaticamente lo sharding e la replica, mettendoti a disposizione un database a disponibilità elevata e durevolezza in grado di scalare per gestire i carichi di lavoro viene caricato automaticamente.

Per ulteriori informazioni, consulta quanto segue:

Documentazione per Datastore.
Elenco di datastore.googleapis.com tipi di metriche.

SLI di disponibilità

Datastore scrive i dati delle metriche in Cloud Monitoring utilizzando datastore_request tipo di risorsa monitorata e tipo di metrica api/request_count. Puoi filtrare i dati utilizzando l'etichetta metrica response_code per conteggiare le chiamate API riuscite e non riuscite o l'etichetta metrica api_method per misurare, ad esempio, solo le letture del documento.

Puoi esprimere uno SLI di disponibilità basato su richiesta creando un Struttura di TimeSeriesRatio per richieste andate a buon fine a richieste totali, come mostrato nell'esempio seguente:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"datastore.googleapis.com/api/request_count\"
         resource.type=\"datastore_request\"",
      "goodServiceFilter":
        "metric.type=\"datastore.googleapis.com/api/request_count\"
         resource.type=\"datastore_request\"
         metric.label.\"response_code\"=\"success\"",
    }
  }
}

SLI di latenza

Al momento Datastore non fornisce una metrica di latenza. Per le metriche disponibili, consulta datastore.googleapis.com tipi di metriche.