Ein Anfrage-Antwort-Dienst ist ein Dienst, den ein Kunde ausdrücklich dazu auffordert, Aufgaben auszuführen, und dann wartet, bis diese Aufgaben erfolgreich abgeschlossen sind. Die häufigsten Beispiele für solche Dienste sind:
- Webanwendungen, mit denen menschliche Nutzer direkt über einen Browser interagieren.
- Mobile Apps, die aus einer Clientanwendung auf dem Smartphone eines Nutzers und einem API-Backend bestehen, mit dem der Client interagiert.
- API-Back-Ends, die von anderen Diensten (nicht von menschlichen Nutzern) verwendet werden.
Bei allen solchen Diensten besteht der übliche Ansatz darin, Verfügbarkeits- (Prozentsatz erfolgreicher Anfragen) und Latenz-SLIs zu messen (Prozentsatz der Anfragen, die unter einem Zeitschwellenwert abgeschlossen werden). Weitere Informationen zu Verfügbarkeits- und Latenz-SLIs finden Sie unter Service Monitoring-Konzepte.
Zur Erstellung von anfragebasierten Verfügbarkeits-SLIs nutzen Sie die TimeSeriesRatio-Struktur, um ein Verhältnis von fehlerfreien Anfragen zu Gesamtzahl der Anfragen einzurichten. Sie entscheiden, wie Sie den Messwert filtern. Hierzu verwenden Sie die verfügbaren Labels, um die Beurteilungen "gut" und "gültig" einzurichten.
Zur Erstellung von anfragebasierten Latenz-SLIs nutzen Sie eine DistributionCut-Struktur.
Cloud Endpoints
Cloud Endpoints ist ein Dienst zur Verwaltung von APIs. Dadurch können Sie eine vorhandene API mit Authentifizierung, Kontingenten und Monitoring verfügbar machen.
Endpoints wird als Proxy vor dem gRPC-Anwendungsserver implementiert. Wenn Sie die Messwerte am Proxy ermitteln, können Sie den Fall, dass keine Back-Ends verfügbar sind und Nutzern Fehler angezeigt werden, erfolgreich beheben.
Endpoints schreibt Daten in Messwerttypen, die mit dem Präfix serviceruntime.googleapis.com beginnen.
Hier finden Sie weitere Informationen:
- Dokumentation für Cloud Endpoints.
- Liste der
serviceruntime.googleapis.com-Messwerttypen.
Verfügbarkeits-SLIs
Cloud Endpoints schreibt Messwertdaten vom überwachten Ressourcentypsapi und vom Dienstlaufzeit-Messwerttyps
api/request_count in Cloud Monitoring. Sie können diese mit dem Messwertlabel response_code filtern, um die Werte für "gute" und die insgesamt gestellten Anfragen zu erfassen.
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=\"serviceruntime.googleapis.com/api/request_count\"
resource.type=\"api\"
metric.label.\"response_code_class\"!=\"4xx\"",
"goodServiceFilter":
"metric.type=\"serviceruntime.googleapis.com/api/request_count\"
resource.type=\"api\"
(metric.label.\"response_code_class\"=\"1xx\"" OR
metric.label.\"response_code_class\"=\"2xx\""),
}
}
}
Latenz-SLIs
Cloud Endpoints verwendet folgende primäre Messwerttypen, um die Latenz zu erfassen:
-
api/request_latencies: eine Verteilung von Latenzen in Sekunden für Nicht-Streaming-Anfragen. Verwenden Sie diese Option, wenn die allgemeine Nutzererfahrung von größter Bedeutung ist. -
api/request_latencies_backend: eine Verteilung von Backend-Latenzen in Sekunden für Nicht-Streaming-Anfragen. Verwenden Sie diese Option, um Backend-Latenzen direkt zu ermitteln. -
api/request_latencies_overhead: eine Verteilung der Anfragelatenzen in Sekunden für Nicht-Streaming-Anfragen, ohne das Backend. Verwenden Sie diese Option, um den vom Endpoints-Proxy eingeführten Overhead zu messen.
Beachten Sie, dass die gesamte Anfragelatenz die Summe der Back-End- und Overhead-Latenzen darstellt:
request_latencies = request_latencies_backend + request_latencies_overhead
Endpoints schreibt Messwertdaten unter Nutzung des überwachten Ressourcentyps api und einem der Anfragelatenz-Messwerttypen in Cloud Monitoring.
Keiner dieser Messwerttypen hat ein response_code- oder response_code_class-Label. Daher werden Latenzen für alle Anfragen gemeldet.
Sie geben anfragebasierte Latenz-SLIs mit einer DistributionCut-Struktur an, wie in folgenden Beispielen gezeigt.
Das folgende SLO-Beispiel geht davon aus, dass 99 % aller Anfragen im Projekt in einem gleitenden Zeitraum von einer Stunde einen Totallatenzwert zwischen 0 und 100 ms haben:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"serviceruntime.googleapis.com/ap/request_latencies\"
resource.type=\"api\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "99% requests under 100 ms"
}
Das folgende SLO-Beispiel geht davon aus, dass 98 % der Anfragen über einen rollierenden Zeitraum von einer Stunden eine Back-End-Latenz zwischen 0 und 100 ms haben:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"serviceruntime.googleapis.com/api/backend_latencies\"
resource.type=\"api\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.98,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Cloud Run
Cloud Run ist eine vollständig verwaltete Computing-Plattform für die schnelle und sichere Bereitstellung und Skalierung von containerisierten Anwendungen. Es will die Infrastrukturverwaltung unnötig machen, wozu es auf Änderungen im Traffic durch die fast augenblickliche automatisch Auf- und Abskalierung ab null reagiert. Dadurch werden Ihnen nur exakt die von Ihnen verwendeten Ressourcen berechnet.
Weitere Informationen zur Beobachtbarkeit von Cloud Run finden Sie hier:
- Dokumentation zu Cloud Run.
- Liste der
run.googleapis.com-Messwerttypen.
Verfügbarkeits-SLIs
Cloud Run schreibt Messwertdaten mit dem überwachten Ressourcentyp cloud_run_revision und dem Messwerttyp request_count in Cloud Monitoring. Sie können die Daten nach einem der Messwertlabel response_code oder response_code_class filtern, um "gute" Anfragen und die Gesamtzahl der Anfragen zu erfassen.
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=\"run.googleapis.com/request_count\"
resource.type=\"cloud_run_revision\"
metric.label.\"response_code_class\"!=\"4xx\"",
"goodServiceFilter":
"metric.type=\"run.googleapis.com/request_count\"
resource.type=\"cloud_run_revision\"
(metric.label.\"response_code_class\"=\"1xx\"" OR
metric.label.\"response_code_class\"=\"2xx\""),
}
}
}
Latenz-SLIs
Zur Messung der Latenz schreibt Cloud Run Messwertdaten in Cloud Monitoring. Verwendet werden dabei der überwachte Ressourcentyp cloud_run_revision und der Messwerttyp request_latencies. Die Daten zeigen eine Verteilung der Anfragelatenz in Millisekunden bei Erreichen der Revision. Sie können die Daten nach den Messwertlabels response_code oder response_code_class filtern, wenn Sie explizit die Latenz für alle Anfragen oder nur für erfolgreiche Anfragen messen müssen.
Zur Erstellung von anfragebasierten Latenz-SLIs nutzen Sie eine DistributionCut-Struktur. Das folgende 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=\"run.googleapis.com/request_latencies\"
resource.type=\"cloud_run_revision"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "99% requests under 100 ms"
}
Cloud Functions
Cloud Functions ist ein skalierbares "Pay as you go"-FaaS-Angebot (Function as a-Service), mit dem Ihr Code ausgeführt werden muss, ohne dass eine Infrastruktur verwaltet werden muss. Funktionen werden in vielen Architekturmustern verwendet, um beispielsweise Ereignisverarbeitung, Automatisierung und Bereitstellung von HTTP/S-Anfragen zu erledigen.
Informationen zur Beobachtbarkeit von Cloud Functions finden Sie hier:
- Dokumentation zu Cloud Functions.
- Liste der
run.googleapis.com-Messwerttypen.
Verfügbarkeits-SLIs
Cloud Functions schreibt Messwertdaten mit dem überwachten Ressourcentyp cloud_function und dem Messwerttyp function/execution_time in Cloud Monitoring.
Sie können die Daten nach dem Messwertlabel status filtern, um "gute" und die insgesamt erfolgten Ausführungen 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=\"cloudfunctions.googleapis.com/function/execution_count\"
resource.type=\"cloud_function\"",
"goodServiceFilter":
"metric.type=\"cloudfunctions.googleapis.com/function/execution_count\"
resource.type=\"cloud_function\
metric.label.\"status\"=\"ok\"",
}
}
}
Latenz-SLIs
Zur Messung der Latenz schreibt Cloud Functions Messwertdaten in Cloud Monitoring. Verwendet werden dabei der überwachte Ressourcentyp cloud_function und der Messwerttyp function/execution_times. Die Daten zeigen eine Verteilung der Ausführungszeiten von Funktionen in Nanosekunden.
Sie können die Daten mit status filtern, falls Sie explizit die Latenz aller Ausführungen oder nur der erfolgreichen Ausführungen messen müssen.
Zur Erstellung von anfragebasierten Latenz-SLIs nutzen Sie eine DistributionCut-Struktur. Das folgende SLO-Beispiel geht davon aus, dass 99 % aller Cloud Functions-Ausführungen innerhalb eines rollierenden Zeitraums von einer Stunde eine Gesamtlatenz zwischen 0 und 100 ms haben:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"cloudfunctions.googleapis.com/function/execution_times\"
resource.type=\"cloud_function\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "99% requests under 100 ms"
}
App Engine
App Engine bietet eine vollständig verwaltete, serverlose Plattform zum Erstellen und Ausführen von Anwendungen. Sie haben dabei die Wahl zwischen zwei Umgebungen, der Standard- oder der flexiblen Umgebung. Weitere Informationen finden Sie unter App Engine-Umgebungen auswählen.
Weitere Informationen zu App Engine finden Sie hier:
- Dokumentation zu App Engine.
- Liste der
appengine.googleapis.com-Messwerttypen.
Verfügbarkeits-SLIs
App Engine schreibt Messwertdaten mithilfe des Typs gae_app der überwachten Ressource und des http/server/response_count Messwerttyps in Cloud Monitoring..
Sie können die Daten nach dem Messwertlabel response_code filtern, um "gute" und die insgesamt erfolgten Antworten zu zählen.
Um einen anfragebasierten Verfügbarkeits-SLI für App Engine zu definieren erstellen Sie, wie im folgenden Beispiel gezeigt, eine TimeSeriesRatio-Struktur für das Verhältnis von fehlerfreien zu gesamten Anfragen:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"appengine.googleapis.com/http/server/response_count\"
resource.type=\"gae_app\"
metric.label.\"response_code\">\"499\"
metric.label.\"response_code\"<\"399\"",
"goodServiceFilter":
"metric.type=\"appengine.googleapis.com/http/server/response_count\"
resource.type=\"gae_app\"
metric.label.\"response_code\"<\"299\"",
}
}
}
Latenz-SLIs
Zur Messung der Latenz schreibt App Engine Messwertdaten mit dem überwachten Ressourcentyp gae_app und dem Messwerttyp http/server/response_latencies in Cloud Monitoring.
Sie können die Daten nach dem Messwertlabel response_code filtern, um "gute" und die insgesamt erfolgten Ausführungen zu zählen.
Sie geben einen anfragebasierten Latenz-SLI für App Engine mithilfe einer DistributionCut-Struktur aus. Das folgende SLO-Beispiel geht davon aus, dass 99 % aller Anfragen über einen rollierenden Zeitraum von einer Stunden eine Gesamtlatenz zwischen 0 und 100 ms haben:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"appengine.googleapis.com/http/server/response_latencies\"
resource.type=\"gae_app\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "99% requests under 100 ms"
}
GKE und Istio
Google Kubernetes Engine (GKE) ist der sichere und verwaltete Kubernetes-Dienst von Google mit Vier-Wege-Autoscaling und Multi-Cluster-Unterstützung. Istio ist ein Open Source-Service Mesh, mit dem Sie Dienste verbinden, sichern, steuern und überwachen können. Istio kann in GKE als Add-on (Cloud Service Mesh) oder vom Nutzer über das Open-Source-Projekt installiert werden. In beiden Fällen bietet Istio eine ausgezeichnete Telemetrie, einschließlich Informationen zu Traffic, Fehlern und Latenz für alle vom Mesh verwalteten Dienste.
Eine vollständige Liste der Istio-Messwerte finden Sie unter istio.ioMesswerttypen.
Verfügbarkeits-SLIs
Istio schreibt Messwertdaten in Cloud Monitoring. Dazu nutzt es den Messwerttyp service/server/request_count und einen der folgenden überwachten Ressourcentypen:
Sie können die Daten nach dem Messwertlabel response_code filtern, um "fehlerfreie" Anfragen und die "Gesamtzahl" der Anfragen zu erfassen. Sie können auch das Messwertlabel destination_service_name verwenden, um Anfragen für einen bestimmten Dienst zu erfassen.
Um anfragebasierte Verfügbarkeits-SLIs für auf vom Istio-Service Mesh verwalteten GKE laufenden Diensten zu definieren, 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=\"istio.io/service/server/request_count\"
resource.type=\"k8s_container\"
metric.label.\"destination_service_name\"=\"frontend\"",
"goodServiceFilter":
"metric.type=\istio.io/server/response_count\"
resource.type=\"k8s_container\"
metric.label.\"destination_service_name\"=\"frontend\"
metric.label.\"response_code\"<\"299\"",
}
}
}
Latenz-SLIs
Zur Messung der Latenz schreibt Istio Messwertdaten in Cloud Monitoring. Dazu nutzt es den Messwerttyp service/server/response_latencies und einen der folgenden überwachten Ressourcentypen:
Sie können die Daten nach dem Messwertlabel response_code filtern, um das Verhältnis des "good" and "total" requests. You can also use thedestination_service_name` zu den Anfragen für einen bestimmten Dienst zu erfassen.
Um anfragebasierte Latenz-SLIs für einen Dienst zu definieren, der auf einem vom Istio-Service Mesh verwalteten GKE ausgeführt wird, verwenden Sie eine DistributionCut-Struktur.
Das folgende SLO-Beispiel geht davon aus, dass 99 % aller Anfragenan den frontend-Dienst in einem gleitenden Zeitraum von einer Stunde eine Totallatenzwert zwischen 0 und 100 ms haben:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"istio.io/server/response_latencies\"
resource.type=\"k8s_container\"
metric.label.\"destination_service_name\"=\"frontend\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "99% requests under 100 ms"
}