Datenspeicher- und Abrufdienste

Die auf dieser Seite beschriebenen Google Cloud-Datendienste umfassen solche Dienste, die Daten als Antwort auf eine Anfrage speichern und bereitstellen. SLIs für diese Dienste ähneln den unter Anfrage/Antwort-Dienste beschriebenen SLIs für Anfrage/Antwort-Dienste, wobei der Schwerpunkt auf Verfügbarkeit und Latenz liegt. Beachten Sie, dass die Latenz, insbesondere bei der Messung der Antwortzeit der Datenbankabfrage, oft davon abhängt, wie viele Daten abgerufen werden und mit der Arbeitslast der Anwendung variieren kann.

Zur Erstellung von anfragebasierten Verfügbarkeits-SLIs nutzen Sie die TimeSeriesRatio-Struktur, um ein Verhältnis von "guten" Anfragen zur Gesamtzahl der Anfragen einzurichten. Sie entscheiden, wie Sie den Messwert filtern. Hierzu verwenden Sie die verfügbaren Labels, um die gewünschten Beurteilungen "gut" und "gültig" einzurichten.

Zur Erstellung von anfragebasierten Latenz-SLIs nutzen Sie eine DistributionCut-Struktur.

Cloud Storage

Cloud Storage ist der weltweit verfügbare, langlebige Objektspeicher von Google Cloud. Cloud Storage ist in mehreren Speicherklassen verfügbar. So können Sie genau das geeignete Kosten- und Abrufmodell für Ihren Dienst oder Anwendungsfall finden.

Weitere Informationen finden Sie hier:

Verfügbarkeits-SLIs

Cloud Storage schreibt Messwertdaten mit dem überwachten Ressourcentyp gcs_bucket und dem Messwerttyp api/request_count in Cloud Monitoring. Sie können die Daten mit dem Messwertlabels response_code filtern, um "gute" Anfragen zu zählen. Sie können auch das Messwertlabel method verwenden, um die Verfügbarkeit für eine bestimmte API-Methode, beispielsweise ReadObject, zu messen.

Um anfragebasierte Verfügbarkeits-SLIs zum Lesen von Objekten aus einem Cloud Storage-Bucket zu definieren, nutzen Sie ein Verhältnis (TimeSeriesRatio) der fehlerfreien Anfragen zur Gesamtzahl der Anfragen, wie im folgenden Beispiel gezeigt:

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

Latenz-SLIs

Cloud Storage bietet keinen Latenzmesswert. Falls die Latenz ein Problem darstellt, sollten Sie überlegen, Ihren Dienst zu instrumentieren, um dies auf dem Client zu erfassen.

Bigtable

Bigtable ist ein vollständig verwalteter, skalierbarer NoSQL-Datenbankdienst für große analytische und operative Arbeitslasten. Bigtable ist ideal für die Speicherung sehr großer Datenmengen in einem Schlüssel/Wert-Speicher. Bigtable unterstützt auch einen hohen Lese- und Schreibdurchsatz bei niedriger Latenz, sodass Sie schnell auf große Datenmengen zugreifen können.

Weitere Informationen finden Sie hier:

Verfügbarkeits-SLIs

Cloud Bigtable schreibt Messwertdaten mit dem überwachten Ressourcentyp bigtable_table und folgenden Messwerttypen in Cloud Monitoring:

Um anfragebasierte Verfügbarkeits-SLIs zum Lesen von Objekten aus einem Cloud Storage-Bucket zu definieren, nutzen Sie ein Verhältnis (TimeSeriesRatio) der fehlerhaften Anfragen zur Gesamtzahl der Anfragen, wie im folgenden Beispiel gezeigt:

Sie können diese beiden Messwerte verwenden, um anfragebasierte Verfügbarkeits-SLIs auszudrücken. Erstellen Sie dazu wie unten gezeigt eine TimeSeriesRatio-Struktur für fehlgeschlagene Anfragen zur Gesamtzahl der Anfragen:

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

Latenz-SLIs

Zur Messung der Latenz schreibt Cloud Bigtable Messwertdaten in Cloud Monitoring. Verwendet werden dabei der überwachte Ressourcentyp bigtable_table und der Messwerttyp server/latencies. Um die Daten zu filtern, können Sie mit dem Messwertlabel method die Latenzen bestimmter Methoden messen.

Zur Erstellung von anfragebasierten Latenz-SLIs nutzen Sie eine DistributionCut-Struktur.

Das folgende SLO-Beispiel erwartet, dass 99 % aller Anfragen an die my_table-Tabelle im Cluster my_cluster eine Gesamtlatenz zwischen 0 und 100 ms über einen rollierenden Zeitraum von einer Stunde zeigen:

{
  "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 ist ein vollständig verwalteter Dienst für relationale Datenbanken, der konsistente Transaktionen im globalen Maßstab, Schemas, SQL (ANSI 2011 mit Erweiterungen) und automatische synchrone Replikation für Hochverfügbarkeit bietet.

Weitere Informationen finden Sie hier:

Verfügbarkeits-SLIs

Spanner schreibt Messwertdaten mit dem überwachten Ressourcentyp spanner_instance und dem Messwerttyp query_count in Cloud Monitoring. Sie können die Daten mithilfe des Messwertlabels status filtern, um erfolgreiche und fehlgeschlagene Datenbankabfragen zu zählen.

Zur Definition von anfragebasierten Verfügbarkeits-SLIs erstellen Sie eine TimeSeriesRatio-Struktur für das Verhältnis von guten Anfragen zur Gesamtzahl der Anfragen, wie im folgenden Beispiel gezeigt:

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

Latenz-SLIs

Zum Messen der Latenz schreibt Spanner Messwertdaten mit dem überwachten Ressourcentyp spanner_instance und dem Messwerttyp api/request_latencies in Cloud Monitoring. Um die Daten zu filtern, können Sie mit dem Messwertlabel method die Latenzen bestimmter Methoden messen. Die Daten umfassen nicht nur die Latenzen für Abfragen, sondern auch für andere Spanner API-Aufrufe.

Zur Erstellung von anfragebasierten Latenz-SLIs nutzen Sie eine DistributionCut-Struktur. Das folgende SLO-Beispiel geht davon aus, dass 99 % aller API-Anfragen an den my_database-Dienst in einem rollierenden Zeitraum von einer Stunde einen Totallatenzwert zwischen 0 und 100 ms haben:

{
  "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 ist eine hoch skalierbare NoSQL-Datenbank für Ihre Anwendungen. Cloud Datastore handhabt Fragmentierung und Replikation automatisch und bietet Ihnen eine robuste, hochverfügbare Datenbank, die entsprechend der Arbeitslast Ihrer Anwendungen automatisch skaliert.

Weitere Informationen finden Sie hier:

Verfügbarkeits-SLIs

Spanner schreibt Messwertdaten mit dem überwachten Ressourcentyp datastore_request und dem Messwerttyp api/request_count in Cloud Monitoring. Sie können die Daten nach dem Messwertlabel response_code filtern, um erfolgreiche und fehlgeschlagene API-Aufrufe zu zählen. Alternativ verwenden Sie das Messwertlabel api_method, um beispielsweise nur Dokumentlesevorgänge zu erfassen.

Zur Definition von anfragebasierten Verfügbarkeits-SLIs erstellen Sie eine TimeSeriesRatio-Struktur für das Verhältnis von erfolgreichen Anfragen zur Gesamtzahl der Anfragen, wie im folgenden Beispiel gezeigt:

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

Latenz-SLIs

Datastore bietet derzeit keinen Latenzmesswert. Informationen zu den verfügbaren Messwerten finden Sie unter datastore.googleapis.com Messwerttypen.