Auf dieser Seite werden die Load-Balancer-Typen erläutert, die über Cloud Load Balancing verfügbar sind. Außerdem wird beschrieben, wie Sie die von ihnen als SLIs bereitgestellten Cloud Monitoring-Messwerte verwenden.
Cloud Load Balancing-Dienste stellen häufig den Ersteinstiegspunkt für Anwendungen dar, die in Google Cloud gehostet werden. Load-Balancer werden automatisch instrumentiert, um Informationen über Traffic, Verfügbarkeit und Latenz der dabei bereitgestellten Google Cloud-Dienste bereitzustellen. Daher sind Load-Balancer häufig ausgezeichnete Quelle für SLI-Messwerte, ohne dass eine Anwendunginstrumentierung erforderlich ist.
Zu Beginn können Sie sich auf die Verfügbarkeit und Latenz als primäre Zuverlässigkeitsdimension konzentrieren und SLIs und SLOs erstellen, um diese Dimensionen zu messen und zu melden. Diese Seite enthält Implementierungsbeispiele.
Weitere Informationen finden Sie hier:
- Konzepte im Service Monitoring
- Dokumentation zum Cloud-Load-Balancing
- Liste der
loadbalancing.googleapis.com-Messwerttypen.
Verfügbarkeits-SLIs und -SLOs
Für Nicht-UDP-Anwendungen ist die anfragebasierte Verfügbarkeits-SLI am besten geeignet, da die Dienstinteraktionen direkt den Anfragen zugeordnet werden können.
Zur Definition von anfragebasierten Verfügbarkeits-SLIs nutzen Sie die TimeSeriesRatio-Struktur, um ein Verhältnis von guten Anfragen zu allen Anfragen einzurichten, wie in folgenden Verfügbarkeitsbeispielen gezeigt.
Filtern Sie den Messwert unter Verwendung der verfügbaren Labels, um die Einstufungen "gut" und "gültig" nach Ihren Wünschen einzurichten.
Externer Layer-7-Load-Balancer (HTTP/S)
HTTP/S-Load-Balancer werden verwendet, um Anwendungen zugänglich zu machen, auf die über HTTP/S zugegriffen wird, und um Traffic auf Ressourcen in mehreren Regionen zu verteilen.
Externe Anwendungs-Load-Balancer schreiben Messwertdaten über den überwachten Ressourcentyp https_lb_rule und Messwerttypen mit dem Präfix
loadbalancing.googleapis.com in Monitoring. Der für die Verfügbarkeits-SLOs relevanteste Messwerttyp ist https/request_count. Diesen können Sie mit dem Messwertlabel response_code_class filtern.
Wenn Sie nicht möchten, dass Anfragen gezählt werden, die den Fehlercode 4xx als "gültig" zurückgeben, da dies auf Clientfehler statt auf Dienst- oder Anwendungsfehler hinweisen könnte, können Sie den Filter für "Summe" so schreiben:
"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\"",
Sie müssen auch festlegen, wie "gute" Anfragen gezählt werden sollen. Wenn Sie beispielsweise nur diejenigen zählen möchten, die den Statuscode "200 OK" zurückgeben, können Sie den Filter für "gut" so schreiben:
"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\"",
Sie können dann einen anfragebasierten SLI so definieren:
"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\"",
}
}
},
Für Anwendungen, bei denen der Traffic von mehreren Backends bereitgestellt wird, können Sie SLIs für ein bestimmtes Backend definieren. Verwenden Sie den Messwert https/backend_request_count mit dem Ressourcenlabel backend_target_name, um einen Verfügbarkeits-SLI für ein bestimmtes Backend zu erstellen, wie in diesem Beispiel gezeigt:
"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\"",
}
}
}
Interner Layer-7-Load-Balancer (HTTP/S)
Interne Anwendungs-Load-Balancer schreiben Messwertdaten in Monitoring. Dazu verwenden sie den überwachten Ressourcentyp internal_http_lb_rule und Messwerttypen mit dem Präfix loadbalancing.googleapis.com. Der für die Verfügbarkeits-SLOs relevanteste Messwerttyp ist https/internal_request_count. Diesen können Sie mit dem Messwertlabel response_code_class filtern.
Das folgende Beispiel zeigt einen anfragebasierten Verfügbarkeits-SLI:
"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\"",
}
}
},
Layer-3-Load-Balancer (TCP)
TCP-Load-Balancer stellen keine Anfragemesswerte bereit, da die Anwendungen, die diese verwenden, nicht unbedingt auf dem Anfrage-Antwort-Modell basieren. Keiner der loadbalancing.googleapis.com-Messwerte, die von diesen Load-Balancern bereitgestellt werden, sind als SLIs für eine gute Verfügbarkeit geeignet.
Wenn Sie Verfügbarkeits-SLIs für diese Load Balancer erstellen möchten, müssen Sie benutzerdefinierte oder logbasierte Messwerte erstellen. Weitere Informationen finden Sie unter Benutzerdefinierte Messwerte verwenden oder Logbasierte Messwerte verwenden.
Latenz-SLIs und -SLOs
Für Anwendungen mit Anfrage-/Antwortantworten gibt es zwei Möglichkeiten, Latenz-SLOs zu schreiben:
- Als anfragebasierte SLOs.
- Als zeitfensterbasierte SLOs.
Anfragebasierte SLOs für die Latenz
Ein anfragebasiertes SLO wendet einen Latenzschwellenwert an und zählt den Anteil der Anfragen, die innerhalb eines bestimmten Compliance-Zeitraums unter dem Schwellenwert abgeschlossen wurden. Ein Beispiel für ein anfragebasiertes SLO ist "99 % der Anfragen in unter 100 ms innerhalb eines rollierenden einstündigen Fensters abgeschlossen".
Sie geben anfragebasierte Latenz-SLIs mit einer DistributionCut-Struktur an, wie in folgenden Latenzbeispielen gezeigt.
Ein auf einer Einzelanfrage basiertes SLO kann nicht sowohl die typische Leistung als auch die Beeinträchtigung der Nutzererfahrung erfassen, wobei die "Tails", also die langsamsten Anfragen, stetig längere Antwortzeiten haben. Ein SLO für die typische Leistung unterstützt nicht das Verständnis der "Tail"-Latenz. Eine Diskussion der "Tail"-Latenz finden Sie im Abschnitt "Worrying About Your Tail" inKapitel 6: Monitoring Distributed Systems von Site Reliability Engineering.
Um dieses Problem zu umgehen, können Sie ein zweites SLO schreiben, das sich auf die "Tail"-Latenz konzentriert, z. B. "99,9 % der Anfragen in weniger als 1.000 ms über ein rollierendes Zeitfenster von 1 Stunde". Durch die Kombination der beiden SLOs wird die Beeinträchtigung der Nutzererfahrung sowie die"Tail"-Latenz erfasst.
Zeitfensterbasierte Latenz-SLOs
Ein zeitfensterbasiertes SLO legt ein Qualitätskriterium für den Messzeitraum fest und berechnet das Verhältnis von "guten" Intervallen zur Gesamtzahl der Intervalle. Ein Beispiel für ein zeitfensterbasiertes SLO ist: "Der 95. Perzentil des Latenzmesswerts ist für mindestens 99 % der ein-Minuten-Zeitfenster in einem 28-tägigen rollierenden Fenster kleiner als 100 ms":
- Ein "guter" Messzeitraum ist dann eine Minute, in der 95 % der Anfragen eine Latenz von weniger als 100 ms haben.
- Das Maß der Compliance ist der Anteil an solchen fehlerfreien Zeiträumen. Der Dienst wird den Vorgaben gerecht, wenn dieser Anteil für den Compliancezeitraum mindestens 0,99 beträgt.
Sie müssen ein zeitfensterbasiertes SLO verwenden, wenn der Ihnen zur Verfügung stehende unbearbeitete Messwert ein Latenzperzentil ist, also wenn beide der folgenden Bedingungen zutreffen:
- Die Daten werden in Zeiträume unterteilt, z. B. in Intervallen von einer Minute.
- Die Daten werden in Perzentilgruppen ausgedrückt (z. B. p50, p90, p95, p99).
Bei dieser Art Daten gibt jede Perzentilgruppe einen Anteil an, der die Datengruppen über und unter dieses Perzentil teilt. Beispiel: Ein Intervall von einer Minute mit einem p95-Latenzmesswert von 89 ms meldet, dass der Dienst in dieser Minute 95 % der Anfragen innerhalb von maximal 89 ms beantwortet hat.
Externer Application Load Balancer
Externe Application Load Balancer verwenden die folgenden primären Messwerttypen, um die Latenz zu erfassen:
https/total_latencies: Eine Verteilung der Latenz ab dem Zeitpunkt, an dem die Anfrage vom Proxy empfangen wurde, bis der Proxy vom Client mit dem letzten Antwortbyte ACK erhalten hat. Verwenden Sie diese Option, wenn die allgemeine Nutzererfahrung von größter Bedeutung ist.https/backend_latencies: Eine Verteilung der Latenz ab dem Zeitpunkt, an dem die Anfrage vom Proxy an das Back-End gesendet wurde, bis der Proxy das letzte Byte der Antwort vom Back-End erhalten hat. Dient zum Messen von Latenzen bestimmter Back-Ends, die Traffic hinter dem Load-Balancer bereitstellen.
Diese Messwerte werden dem überwachten Ressourcentyp https_lb_rule zugeordnet.
Gesamtlatenz
Dieses SLO-Beispiel geht davon aus, dass 99 % der Anfragen über einen rollierenden Zeitraum von einer Stunden eine Gesamtlatenz zwischen 0 und 100 ms haben:
{
"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"
}
Backend-Latenz
Dieses SLO-Beispiel geht davon aus, dass 98 % der Anfragen an das Backend-Ziel "my-app-backend" über einen rollierenden Zeitraum von einer Stunde eine Latenz zwischen 0 und 100 ms haben:
{
"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"
}
Interner Application Load Balancer
Interne Application Load Balancer verwenden zwei primäre Messwerttypen, um die Latenz zu erfassen:
https/internal/total_latencies: Eine Verteilung der Latenz ab dem Zeitpunkt, an dem die Anfrage vom Proxy empfangen wurde, bis der Proxy vom Client mit dem letzten Antwortbyte ACK erhalten hat. Verwenden Sie diese Option, wenn die allgemeine Nutzererfahrung von größter Bedeutung ist.https/internal/backend_latencies: Eine Verteilung der Latenz ab dem Zeitpunkt, an dem die Anfrage vom Proxy an das Back-End gesendet wurde, bis der Proxy das letzte Byte der Antwort vom Back-End erhalten hat. Dient zum Messen von Latenzen bestimmter Back-Ends, die Traffic hinter dem Load-Balancer bereitstellen.
Diese Messwerte werden dem überwachten Ressourcentyp internal_http_lb_rule zugeordnet.
Gesamtlatenz
Dieses SLO-Beispiel geht davon aus, dass 99 % der Anfragen über einen rollierenden Zeitraum von einer Stunden eine Gesamtlatenz zwischen 0 und 100 ms haben:
{
"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"
}
Dieses SLO-Beispiel geht davon aus, dass 99 % der Anfragen über einen rollierenden Zeitraum von einer Stunden eine Gesamtlatenz zwischen 0 und 100 ms haben:
Backend-Latenz
Dieses SLO-Beispiel geht davon aus, dass 98 % der Anfragen an das Back-End-Ziel "my-internal-backend" über einen rollierenden Zeitraum von einer Stunde eine Latenz zwischen 0 und 100 ms haben:
{
"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"
}
Externer Layer-3-Load-Balancer (TCP)
Externe TCP-Load-Balancer nutzen nur den Messwerttyp l3/external/rtt_latencies. Dieser erfasst die Umlaufzeit, die über TCP-Verbindungen für externe Load-Balancer-Abläufe gemessen wird.
Dieser Messwert wird der Ressource tcp_lb_rule zugeordnet.
Dieses SLO-Beispiel geht davon aus, dass 99 % der Anfragen über einen rollierenden Zeitraum von einer Stunden eine Gesamtlatenz zwischen 0 und 100 ms haben:
{
"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"
}
Interner Layer-3-Load-Balancer (TCP)
Interne TCP-Load-Balancer nutzen nur den Messwerttyp l3/internal/rtt_latencies. Dieser erfasst die Umlaufzeit, die über TCP-Verbindungen für interne Load-Balancer-Abläufe gemessen wird.
Dieser Messwert wird der Ressource internal_tcp_lb_rule zugeordnet.
Dieses SLO-Beispiel geht davon aus, dass 99 % der Anfragen über einen rollierenden Zeitraum von einer Stunden eine Gesamtlatenz zwischen 0 und 100 ms haben:
{
"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"
}