Les services de données Google Cloud décrits sur cette page incluent ceux qui stockent et fournissent des données en réponse à une requête. Les SLI de ces services sont semblables aux SLI pour les services de requête-réponse, décrits dans la section Services de requête-réponse, en accordant une accent sur la disponibilité et la latence. Notez que la latence, en particulier lors de la mesure du temps de réponse d'une requête de base de données, est souvent un facteur de quantité de données récupérées et qui peut varier en fonction de la charge de travail de l'application.
Vous pouvez exprimer un SLI de disponibilité basé sur les requêtes en utilisant la structure TimeSeriesRatio pour définir un ratio de "bonnes" requêtes par rapport au nombre total de requêtes. Vous décidez de la manière de filtrer la métrique à l'aide de ses étiquettes disponibles afin d'obtenir votre détermination de "bonne" ou "valide".
Vous pouvez exprimer un SLI de latence basé sur les requêtes à l'aide d'une structure DistributionCut.
Cloud Storage
Cloud Storage est le magasin d'objets durable de Google Cloud pour le monde entier. Cloud Storage est disponible dans plusieurs classes de stockage, qui vous permettent de déterminer le coût et le modèle de récupération appropriés pour votre service ou cas d'utilisation.
Pour en savoir plus, consultez les ressources suivantes:
- Documentation pour Cloud Storage.
- Liste des types de métriques
storage.googleapis.com.
SLI de disponibilité
Cloud Storage écrit des données de métriques dans Cloud Monitoring à l'aide du type de ressource surveillée gcs_bucket et du type de métrique api/request_count. Vous pouvez filtrer les données à l'aide du libellé de métrique response_code pour comptabiliser les requêtes "bonne". Vous pouvez également utiliser le libellé de métrique method pour mesurer la disponibilité d'une méthode d'API spécifique, telle que ReadObject.
Vous pouvez exprimer un SLI de disponibilité basé sur des requêtes pour lire des objets à partir d'un bucket Cloud Storage à l'aide d'un ratio, TimeSeriesRatio, de requêtes satisfaisantes par rapport au nombre total de requêtes, comme illustré dans l'exemple suivant:
"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 de latence
Cloud Storage ne fournit pas de métrique de latence. Si la latence pose problème, envisagez d'instrumenter votre service pour collecter ces informations sur le client.
Bigtable
Bigtable est un service de base de données NoSQL entièrement géré et évolutif, pour les charges de travail analytiques et opérationnelles d'envergure. Bigtable est idéal pour stocker de très grandes quantités de données dans un magasin de paires clé/valeur. Bigtable prend également en charge un débit de lecture et d'écriture élevé avec une faible latence, offrant un accès rapide à de grandes quantités de données.
Pour en savoir plus, consultez les ressources suivantes:
- Documentation de Bigtable
- Liste des types de métriques
bigtable.googleapis.com.
SLI de disponibilité
Bigtable écrit des données de métrique dans Cloud Monitoring à l'aide du type de ressource surveillée bigtable_table et des types de métriques suivants :
-
server/request_count, qui compte le nombre total de requêtes. -
server/error_count, qui compte le nombre total de requêtes ayant échoué.
Vous pouvez exprimer un SLI de disponibilité basé sur des requêtes pour lire des objets à partir d'un bucket Cloud Storage à l'aide d'un ratio, TimeSeriesRatio, de requêtes "bad" par rapport au nombre total de requêtes, comme illustré dans l'exemple suivant :
Vous pouvez utiliser ces deux métriques pour exprimer un SLI de disponibilité basé sur les requêtes en créant une structure TimeSeriesRatio pour les requêtes ayant échoué par rapport aux requêtes totales, comme illustré dans l'exemple ci-dessous :
"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 de latence
Pour mesurer la latence, Bigtable écrit des données de métrique dans Cloud Monitoring à l'aide du type de ressource surveillée bigtable_table et du type de métrique server/latencies. Vous pouvez filtrer les données à l'aide du libellé de métrique method pour mesurer les latences de méthodes spécifiques.
Vous pouvez exprimer un SLI de latence basé sur les requêtes à l'aide d'une structure DistributionCut.
L'exemple de SLO suivant attend que 99% de toutes les requêtes adressées à la table my_table du cluster my_cluster tombent entre 0 et 100 ms de latence totale sur une période glissante d'une heure:
{
"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 est un service de base de données relationnelle entièrement géré, qui est conçu pour offrir une cohérence transactionnelle à l'échelle mondiale. Il fournit des schémas, SQL (ANSI 2011 avec extensions) et une réplication synchrone automatique pour garantir une haute disponibilité.
Pour en savoir plus, consultez les ressources suivantes:
- Documentation de Spanner
- Liste des types de métriques
spanner.googleapis.com.
SLI de disponibilité
Spanner écrit les données de métrique dans Cloud Monitoring à l'aide du type de ressource surveillée spanner_instance et du type de métrique query_count. Vous pouvez filtrer les données à l'aide du libellé de métrique status pour compter les requêtes de base de données ayant abouti et échoué.
Vous pouvez exprimer un SLI de disponibilité basé sur les requêtes en créant une structure TimeSeriesRatio pour les requêtes "satisfaisantes" par rapport au nombre total de requêtes, comme indiqué dans l'exemple suivant :
"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 de latence
Pour mesurer la latence, Bigtable écrit des données de métrique dans Cloud Monitoring à l'aide du type de ressource surveillée spanner_instance et du type de métrique api/request_latencies. Vous pouvez filtrer les données à l'aide du libellé de métrique method pour mesurer les latences de méthodes spécifiques. Les données incluent des latences non seulement pour les requêtes mais également pour d'autres appels d'API Spanner.
Vous pouvez exprimer un SLI de latence basé sur les requêtes à l'aide d'une structure DistributionCut.
L'exemple de SLO suivant attend que 99 % de toutes les requêtes adressées à la base de données my_database tombent entre 0 et 100 ms de latence totale sur une période glissante d'une heure :
{
"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 est une base de données NoSQL qui offre une grande évolutivité pour vos applications. Cet outil gère automatiquement la segmentation et la réplication des données. Vous disposez ainsi d'une base de données durable et à disponibilité élevée, capable d'évoluer de manière dynamique pour absorber la charge de vos applications.
Pour en savoir plus, consultez les ressources suivantes:
- Documentation pour Datastore.
- Liste des types de métriques
datastore.googleapis.com.
SLI de disponibilité
Datastore écrit les données de métrique dans Cloud Monitoring à l'aide du type de ressource surveillée datastore_request et du type de métrique api/request_count. Vous pouvez filtrer les données à l'aide du libellé de métrique response_code pour compter les appels d'API réussis et échoués. Vous pouvez également utiliser le libellé de métrique api_method pour, par exemple, ne mesurer que les lectures de documents.
Pour exprimer un SLI de disponibilité basé sur des requêtes, créez une structure TimeSeriesRatio pour les requêtes réussies par rapport au nombre total de requêtes, comme indiqué dans l'exemple suivant :
"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 de latence
Actuellement, Datastore ne fournit pas de métrique de latence.
Pour consulter les métriques disponibles, consultez la page Types de métriques datastore.googleapis.com.