Cette page présente les types d'équilibreurs de charge disponibles dans Cloud Load Balancing, et explique comment utiliser les métriques Cloud Monitoring qu'ils exposent en tant que SLI.
Les services Cloud Load Balancing fournissent souvent le premier point d'entrée des applications hébergées dans Google Cloud. Les équilibreurs de charge fournissent automatiquement des informations sur le trafic, la disponibilité et la latence des services Google Cloud qu'ils exposent. Ainsi, les équilibreurs de charge constituent souvent une excellente source de métriques SLI sans nécessiter l'instrumentation de l'application.
Au cours de la mise en route, vous pouvez choisir de vous concentrer sur la disponibilité et la latence en tant que dimensions principales de fiabilité, et créer des SLI et des SLO afin de mesurer ces dimensions et d'envoyer des alertes le cas échéant. Cette page fournit des exemples de mise en œuvre.
Pour en savoir plus, consultez les ressources suivantes:
- Concepts de surveillance des services
- Documentation de Cloud Load Balancing
- Liste des types de métriques
loadbalancing.googleapis.com
SLI et SLO de disponibilité
Pour les applications non UDP, le SLI de disponibilité basée sur une requête est le plus approprié, car les interactions de service s'intègrent parfaitement avec les requêtes.
Pour exprimer un SLI de disponibilité basé sur des requêtes, vous utilisez la structure TimeSeriesRatio pour configurer un ratio de bonnes requêtes par rapport au nombre total de requêtes, comme indiqué dans les exemples de disponibilité suivants.
Pour déterminer la valeur "good" ou "valide" que vous souhaitez, filtrez la métrique à l'aide des libellés disponibles.
Équilibreur de charge de couche 7 (HTTP/S) externe
Les équilibreurs de charge HTTP/S permettent d'exposer les applications accessibles via HTTP/S et de répartir le trafic vers les ressources situées dans plusieurs régions.
L'équilibreur de charge d'application externe écrit des données métriques dans Monitoring à l'aide du type https_lb_rule de ressource surveillée et des types de métriques avec le préfixe loadbalancing.googleapis.com. Le type de métrique le plus pertinent pour les SLO de disponibilité est https/request_count, que vous pouvez filtrer à l'aide du libellé de métrique response_code_class.
Si vous choisissez de ne pas comptabiliser les requêtes qui génèrent un code de réponse d'erreur 4xx comme "valide", car elles peuvent indiquer des erreurs client, plutôt que des erreurs de service ou d'application, vous pouvez écrire le filtre "total", comme cela:
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"!=\"400\"",
Vous devez également déterminer comment comptabiliser les requêtes "good". Par exemple, si vous choisissez de ne compter que celles qui renvoient un code de réponse d'état "200 OK", vous pouvez écrire le filtre "good" comme suit:
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"=\"200\"",
Vous pouvez ensuite exprimer un SLI basé sur des requêtes de la manière suivante:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"!=\"400\"",
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"=\"200\"",
}
}
},
Pour les applications où le trafic est diffusé par plusieurs backends, vous pouvez choisir de définir des SLI pour un backend spécifique. Pour créer un SLI de disponibilité pour un backend spécifique, utilisez la métrique https/backend_request_count avec le libellé de ressource backend_target_name dans vos filtres, comme indiqué ci-dessous dans cet exemple :
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/backend_request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
resource.label.\"backend_target_name\"=\"my-app-backend\"
metric.label.\"response_code_class\"!=\"400\"",
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/backend_request_count\"
resource.type=\"https_lb_rule\" resource.label.\"url_map_name\"=\"my-app-lb\"
resource.label.\"backend_target_name\"=\"my-app-backend\"
metric.label.\"response_code_class\"=\"200\"",
}
}
}
Équilibreur de charge de couche 7 (HTTP/S) interne
L'équilibreur de charge d'application interne écrit les données de métriques dans Monitoring à l'aide du type de ressource surveillée internal_http_lb_rule et des types de métriques avec le préfixe loadbalancing.googleapis.com. Le type de métrique le plus pertinent pour les SLO de disponibilité est https/internal_request_count, que vous pouvez filtrer à l'aide du libellé de métrique response_code_class.
Voici un exemple de SLI de disponibilité basé sur les requêtes:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/request_count\"
resource.type=\"internal_http_lb_rule\"
resource.label.\"url_map_name\"=\"my-internal-lb\"
metric.label.\"response_code_class\"!=\"400\"",
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/request_count\"
resource.type=\"internal_http_lb_rule\"
resource.label.\"url_map_name\"=\"my-internal-lb\"
metric.label.\"response_code_class\"=\"200\"",
}
}
},
Équilibreurs de charge de couche 3 (TCP)
Les équilibreurs de charge TCP ne fournissent pas de métriques de requête, car les applications qui les utilisent peuvent ne pas être basées sur le modèle de requête-réponse. Aucune des métriques loadbalancing.googleapis.com fournies par ces équilibreurs de charge ne procurent de bons SLI de disponibilité.
Pour créer des SLI de disponibilité pour ces équilibreurs de charge, vous devez créer des métriques personnalisées ou basées sur les journaux. Pour plus d'informations, consultez la section Utiliser des métriques personnalisées ou Utiliser des métriques basées sur les journaux.
SLI et SLO de latence
Pour les applications requête-réponse, il existe deux façons d'écrire les SLO de latence:
- En tant que SLO basés sur des requêtes.
- En tant que SLO basés sur des fenêtres.
SLO de latence basés sur des requêtes
Un SLO basé sur des requêtes applique un seuil de latence et compte la fraction des requêtes qui se terminent sous le seuil au cours d'une période de conformité donnée. Un exemple de SLO basé sur des requêtes est "99% des requêtes terminées en moins de 100 ms au cours d'une période d'une heure glissante".
Vous pouvez exprimer un SLI de latence basé sur les requêtes à l'aide d'une structure DistributionCut, comme illustré dans les exemples de latence suivants.
Un SLO basé sur des requêtes ne peut pas capturer à la fois les performances habituelles et la dégradation de l'expérience utilisateur, où les requêtes les plus lentes ou "tail" enregistrent des temps de réponse plus longs. Un SLO pour des performances typiques ne prend pas en charge la compréhension de la latence de queue. Pour en savoir plus sur la latence de queue, consultez la section "Worrying About Your Tail" (Prendre soin de la queue) dans le Chapitre 6: Surveillance des systèmes distribués de la documentation de l'équipe d'ingénierie en fiabilité des sites.
Pour atténuer cette limitation, vous pouvez écrire un second SLO qui se concentre spécifiquement sur la latence de queue, par exemple "99,9% des requêtes effectuées en moins de 1 000 ms sur une fenêtre glissante d'une heure". La combinaison des deux SLO révèle des dégradations de l'expérience utilisateur type et de la latence de queue.
SLO de latence basée sur la fenêtre
Un SLO basé sur des fenêtres définit un critère de satisfaction pour la période des mesures et calcule le rapport entre les intervalles satisfaisants et le nombre total d'intervalles. Voici un exemple de SLO basé sur des fenêtres : "La métrique de latence du 95e centile est inférieure à 100 ms pour au moins 99% des fenêtres d'une minute, sur une fenêtre glissante de 28 jours" :
- Une période de mesure "satisfaisante" est une période d'une minute pendant laquelle 95% des requêtes présentent une latence inférieure à 100 ms.
- La mesure de conformité correspond à la fraction de ces "bonnes" périodes. Le service est conforme si cette fraction est supérieure ou égale à 0,99 ,, calculée sur la période de conformité.
Vous devez utiliser un SLO basé sur des fenêtres si la métrique brute dont vous disposez est un centile de latence. c'est-à-dire lorsque les deux conditions suivantes sont remplies:
- Les données sont regroupées par périodes, par exemple en intervalles d'une minute.
- Les données sont exprimées en groupes de centiles (par exemple, p50, p90, p95, p99).
Pour ce type de données, chaque groupe de centiles indique la durée en divisant les groupes de données au-dessus et en dessous de ce centile. Par exemple, un intervalle d'une minute avec une métrique de latence p95 de 89 ms vous indique que, pour cette minute, le service a répondu à 95% des requêtes en 89 ms ou moins.
Équilibreur de charge d'application externe
Les équilibreurs de charge d'application externe utilisent les types de métriques principaux suivants pour capturer la latence:
https/total_latencies: Distribution de la latence calculée à partir de la réception de la requête par le proxy jusqu'à ce que celui-ci obtienne la confirmation de réception du client sur le dernier octet de réponse. À utiliser lorsque l'expérience utilisateur globale est d'importance principale.https/backend_latencies: Distribution de la latence calculée entre le moment où le proxy a envoyé la requête au backend et le moment où le proxy a reçu le dernier octet de réponse du backend. Permet de mesurer les latences de backends spécifiques diffusant le trafic derrière l'équilibreur de charge.
Ces métriques sont écrites par rapport au type de ressource surveillée https_lb_rule.
Latence totale
Dans cet exemple de SLO, on attend que 99% des requêtes tombent entre 0 et 100 ms de latence totale sur une période glissante d'une heure:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/total_latencies\"
resource.type=\"https_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Latence du backend
Cet exemple de SLO attend que 98% des requêtes adressées à la cible du backend "my-app-backend" tombe entre 0 et 100 ms de latence sur une période glissante d'une heure:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/backend_latencies\"
resource.type=\"https_lb_rule\"
resource.label.\"backend_target_name\"=\"my-app-backend\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.98,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Équilibreur de charge d'application interne
Les équilibreurs de charge d'application interne utilisent deux types de métriques principales pour capturer la latence:
https/internal/total_latencies: distribution de la latence calculée à partir de la réception de la requête par le proxy jusqu'à ce que celui-ci obtienne la confirmation de réception du client sur le dernier octet de réponse. À utiliser lorsque l'expérience utilisateur globale est d'importance principale.https/internal/backend_latencies: Distribution de la latence calculée entre le moment où le proxy a envoyé la requête au backend et le moment où le proxy a reçu le dernier octet de réponse du backend. Permet de mesurer les latences de backends spécifiques diffusant le trafic derrière l'équilibreur de charge.
Ces métriques sont écrites par rapport au type de ressource surveillée internal_http_lb_rule.
Latence totale
Dans cet exemple de SLO, on attend que 99% des requêtes tombent entre 0 et 100 ms de latence totale sur une période glissante d'une heure:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/total_latencies\"
resource.type=\"internal_http_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Dans cet exemple de SLO, on attend que 99% des requêtes tombent entre 0 et 100 ms de latence totale sur une période glissante d'une heure:
Latence du backend
Cet exemple de SLO attend que 98% des requêtes adressées à la cible du backend "my-internal-backend" tombe entre 0 et 100 ms de latence sur une période glissante d'une heure:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/backend_latencies\"
resource.type=\"https_lb_rule\"
resource.label.\"backend_target_name\"=\"my-internal-backend\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.98,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Équilibreur de charge externe de couche 3 (TCP)
Les équilibreurs de charge TCP externes utilisent un seul type de métrique, l3/external/rtt_latencies, qui enregistre la distribution du temps aller-retour sur les connexions TCP pour les flux d'équilibreur de charge externe.
Cette métrique est écrite par rapport à la ressource tcp_lb_rule.
Dans cet exemple de SLO, on attend que 99% des requêtes tombent entre 0 et 100 ms de latence totale sur une période glissante d'une heure:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/l3/external/rtt_latencies\"
resource.type=\"tcp_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Équilibreur de charge de couche 3 (TCP) interne
Les équilibreurs de charge TCP internes utilisent un seul type de métrique, l3/internal/rtt_latencies, qui enregistre la distribution du temps aller-retour sur les connexions TCP pour les flux de l'équilibreur de charge interne.
Cette métrique est écrite par rapport à la ressource internal_tcp_lb_rule.
Dans cet exemple de SLO, on attend que 99% des requêtes tombent entre 0 et 100 ms de latence totale sur une période glissante d'une heure:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/l3/internal/rtt_latencies\"
resource.type=\"internal_tcp_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}