Wolkengucker

von Dr. Guido Söldner

Beim Betrieb von Infrastruktur und Anwendungen ist Monitoring für einen Einblick in den Zustand der jeweiligen Komponenten unabkömmlich. Dies gilt nicht nur für lokale Umgebungen, sondern auch für die Public Cloud. Der folgende Artikel gibt eine Einführung in die Überwachung der Google Cloud Platform. Dabei gehen wir unter anderem auf das Monitoring von virtuellen Maschinen, das Einrichten von Warnungen, die Nutzung von Dashboards und das Setzen von Service Level Objectives ein.

Google ist mit seiner Google Cloud Platform (GCP) neben AWS und Microsoft Azure einer der drei großen Public-Cloud-Anbieter. In den letzten Jahren konnte Google gerade bei den Themen Maschinelles Lernen und Big Data ein beträchtliches Wachstum verzeichnen. Aber auch im klassischen IaaS-Bereich braucht sich GCP vor seinen Mitbewerbern nicht zu verstecken. Um eine Cloudinfrastruktur richtig betreiben zu können, spielt Monitoring eine zentrale Rolle. Bei Google hieß die Cloud Operations Suite, die die Themen Monitoring, Logging, Tracing, Debugging, Profiling und Auditing adressiert, bis vor zwei Jahren Stackdriver. Mittlerweile verwendet Google diesen Namen nicht mehr, sondern spricht einfach nur von der Operations Suite.

Um im laufenden Betrieb ein funktionierendes Monitoring zu gewährleisten, ist es notwendig, entsprechend Daten aus den Quellsystemen in Form von Signalen zu empfangen. Beim Monitoring sind dies entsprechend Metriken. Diese können von IaaS-Komponenten wie virtuellen Maschinen, von höherwertigen Services wie gemanagten Datenbanken, von Plattformen wie Kubernetes, von Microservices, aber auch von Applikationen selbst ausgehen. Zusätzlich ist es notwendig, Incidents im Auge zu behalten, egal ob in Form von Alerts, Fehlerberichten oder auch Service Level Objectives. Mit der Operations Suite lassen sich all diese Daten zusammenführen, genauer betrachten, visualisieren und zur Fehlersuche benutzen.

Der Zugriff auf Monitoringdaten kann bei GCP sowohl zentral als dezentral erfolgen. In der Google-Cloud sind alle Ressourcen Projekten zugeordnet. In der Operations Suite kann jedes Projekt für sich die Daten allein sammeln und auswerten. Wollen Sie jedoch über die ganze Organisation hinweg den Überblick über alle Systeme behalten, dann sollten Sie mehrere Projekte zu einem Monitoring Workspace hinzufügen.

In GCP eingeloggt, wechseln Sie dazu zuerst in das Monitoringtool, indem Sie oben mittig in der Suchleiste den Begriff "Monitoring" eingeben und dann den ersten Punkt in der Ergebnisleiste auswählen. Alternativ klicken Sie direkt links in der Menüleiste auf die Punkte "Operations / Monitoring / Overview". Anschließend können Sie oben links bei "Metrics Scope" weitere Projekte auswählen und einem Workspace hinzufügen.

Monitoring von virtuellen Maschinen

Eine weitere Möglichkeit, um sich Monitoringdaten anzusehen, besteht darin, in der GCP-GUI die Ressource direkt anzuwählen. Im Fall von virtuellen Maschinen klicken Sie einfach auf die einzelne VM und wechseln dann auf den Observability-Tab. Sie gelangen daraufhin auf ein Dashboard, das die wichtigsten Metriken anzeigt. Für VMs sind dies die CPU-Auslastung, diverse Werte zum Netzwerkverkehr wie die Menge der empfangenen und versandter Pakete, blockierte Pakete der Firewall, aber auch Festplattenkennzahlen wie IOPS-Vorgänge oder Datendurchsatz.

Darüber hinaus können Sie sich noch weitreichendere Metriken zur Speicher- und Festplattenauslastung anzeigen lassen. Dazu müssen Sie jedoch den Ops-Agenten in die betreffenden VMs installieren. Glücklicherweise zeigt die GUI auch gleich die Installationsanleitung dazu und fordert dazu auf, die im Listing-Kasten "Installation des Ops-Agenten" aufgeführten Befehle auszuführen.

Der Ops-Agent basiert übrigens auf dem OpenTelemetry-Standard, einem Projekt der Cloud Native Computing Foundation. Es handelt sich also nicht um einen proprietären Standard. Dadurch ist sichergestellt, dass der Ops-Agent mit allen Monitoringtools, die den Standard beherrschen, zusammenarbeitet.

Einrichten von Uptime-Checks

Neben dem Abfragen von Basismetriken ist die Definition von Uptime-Checks eine der grundlegenden Aufgaben im Monitoring. Eine klassische Methode zur Implementierung besteht darin, einen HTTP-Endpunkt aufzurufen und den HTTP-Antwortstatus zu überprüfen. Im Fall einer virtuellen Maschine können Sie dies leicht am Beispiel eines Apache-Webservers ausprobieren. Verwenden Sie etwa Debian, installieren Sie zunächst den Apache-Server wie folgt:

Die Konfiguration des Uptime-Checks erfolgt dann in der Operations Suite. Dazu wählen Sie links im Menü den Punkt "Operations / Monitoring / Uptime Checks" aus und klicken im Anschluss auf "[+ CREATE UPTIME CHECK]", um mit der Konfiguration zu beginnen. Auf der linken Seite des Bildschirms sehen Sie anschließend den Assistenten. Der erste Schritt ist einfach: Geben Sie einen Namen für den Uptime-Check an und klicken Sie anschließend auf "Next". Im nächsten Schritt bestimmen Sie das zu überprüfende Ziel. Neben URLs können Sie mittlerweile auch Kubernetes-Loadbalancer, App-Engine-Instanzen, VM-Instanzen, aber auch AWS-Elastic-Loadbalancer auswählen. In unserem Fall sieht die Konfiguration wie folgt aus:

- Instance: <Name der VM>

- Check Frequencey: 1 minute

An dieser Stelle soll nur kurz erwähnt sein, dass natürlich entsprechende Firewallregeln für die VM eingerichtet sein müssen, sodass Port 80 auch erreichbar ist. Die anderen Konfigurationswerte belassen Sie so, wie sie sind, und gehen zum nächsten Schritt. Unter dem Menüpunkt "Response Validation" bleibt der "Re-sponse Timeout" bei 10 Sekunden und die Checkbox "Log check failures" aktiviert, um im Fehlerfall auch mitzuloggen.

Klicken Sie ein weiteres Mal auf "Next", um zum letzten Schritt im Assistenten zu gelangen – dem Konfigurieren von Alarmen und Benachrichtigungen. Dort lassen Sie den Schalter "Create an alert" aktiviert und ändern gegebenenfalls den Namen des Alerts. Den "Notification Channel" lassen Sie leer – falls erwünscht, wäre es hier aber möglich, Alarme zu versenden. Dabei unterstützt Google mobile Endgeräte wie Smartphones, PagerDuty Services, PagerDuty Sync, Slack, Webhooks, E-Mail, SMS und den internen Messaging-Dienst Pub/Sub. Nach dem Abschluss des Assistenten dauert es noch ein paar Minuten, bis die ersten Daten in der Operations Suite sichtbar sind.

Setzen von Warnungen

Die Operations Suite erlaubt auch die Definition von Warnungen. Diese sind an Bedingungen geknüpft und können bei Bedarf Benachrichtigungen versenden. In GCP richten Sie diese Warnungen ein, indem Sie in der Navigationsleiste den Menüpunkt "Operations / Monitoring / Alerting" anwählen. Das Anlegen eines Alerts starten Sie durch einen Klick oben auf den Link "[+ CREATE POLICY]".

Als Erstes definieren Sie eine Bedingung und klicken dazu auf "[ADD CONDITION]". Daraufhin öffnet sich ein Fenster, in dem Sie einen Namen für die Bedingung sowie eine entsprechende Metrik auswählen. Für unser Szenario legen wir als Ressourcentyp "VM Instance" fest und als Metrik den Netzwerkverkehr. Tippen Sie "Network" ein, erscheint eine Liste von möglichen Metriken: Wir wählen "agent. googleapis.com/interface/traffic" aus. Unter Configuration setzen wir die folgenden Werte:

- Condition: is above

Anschließend klicken Sie auf "Add" und auf "Next". Nun können Sie die Benachrichtigungen konfigurieren. Bei "Notification Channels" entscheiden Sie sich für "Manage Notification Channels" und hinterlegen in dem sich öffnenden Fenster Ihre E-Mail-Adresse. Sobald Sie diesen Vorgang abgeschlossen haben, können Sie im ursprünglichen Fenster die definierte E-Mail-Adresse auswählen und auf "OK" klicken.

Mit "Next" gelangen Sie in den letzten Schritt. Dort hinterlegen Sie einen Alert-Namen – also beispielsweise "Inbound Traffic Alert". Optional können Sie noch einen Text angeben, den Sie der E-Mail hinzufügen wollen. Mit "Save" schließen Sie den Vorgang ab. Nach wenigen Minuten sollte sich anschließend tatsächlich ein Alert einstellen, den Sie sich im Dashboard auch anzeigen lassen können.

Erzeugen von Dashboards

Die Google Cloud Platform liefert beim Monitoring bereits eine große Menge von Dashboards mit. Nichtsdestotrotz kann der Wunsch entstehen, eigene Dashboards zu erstellen. Dazu wechseln Sie auf die Seite "Operations / Monitoring / Dashboards". Die Startseite zeigt alle vorhandenen Dashboards. Außerdem existiert unter der Registrierkarte "SAMPLE LIBRARY" eine große Bibliothek an Beispiel-Templates, die Sie als Inspiration nehmen können.

Um ein eigenes Dashboard zu schaffen, klicken Sie auf "[Create Dashboard]" und vergeben anschließend einen Namen. Nun wählen Sie aus der Liste der Charts Elemente aus, die Sie auf dem Dashboard platzieren möchten. Die Auswahlliste ist dabei recht umfangreich. Neben Liniendiagrammen gibt es gestapelte Flächen- und Säulendiagramme, Heatmaps, Tabellen, Gauge-Diagramme, Scorecards, Texte und Warnungen.

So könnten Sie beispielsweise damit anfangen, ein Liniendiagramm als Element hinzuzufügen, und es mit "CPU-Auslastung" betiteln. Als Resourcentyp wählen wir "VM Instance" aus und setzen die Metrik auf "CPU load (1m)". Nun können Sie auch noch ein zweites Diagramm hinzufügen, indem Sie oben auf "[ADD CHART]" klicken. Auch diesmal wählen wir wieder ein Liniendiagramm. Als Bezeichnung geben wir "Empfangene Pakete" an, der Resourcentyp wird wiederum "VM Instance" und die Metrik diesmal "Received packets (gce instance)".

Monitoring von Diensten

Klassisches Monitoring konzentriert sich oft auf Messwerte auf Ebene der Ressourcen. In unserem Fall waren dies Informationen wie zum Beispiel die CPU-Auslastung, die übertragenen Netzwerkpakete oder aber die Speicherauslastung. Moderne Applikationen bestehen jedoch aus einer großen Menge von Einzelkomponenten, sodass es sehr mühselig ist, eine sehr große Menge an Metriken alle einzeln zu betrachten. Aus diesem Grund kann es vorteilhaft sein, die Applikation als Ganzes zu betrachten und insbesondere deren wichtigsten Werte – die Verfügbarkeit und die Latenz – zu messen. Um dies zu erklären, wollen wir im Folgenden eine Beispielapplikation auf Basis des Google-Dienstes App Engine bereitstellen, die öffentlich auf GitHub zur Verfügung steht. Um sie zu deployen, öffnen Sie in der GCP-Konsole die Cloud-Shell und klonen das Repository wie folgt:

Anschließend stellen Sie die Anwendung mit den folgenden Befehlen bereit:

Der Deployment-Vorgang dauert anschließend rund ein bis zwei Minuten und nach dessen Abschluss sehen Sie dann in der Shell-Ausgabe die URL der Anwendung. Beim Öffnen der Webseite gibt es keine großen Überraschungen: Es erscheint nur ein "Hello World!"-Text. Nun gilt es, mit folgendem Code-Snippet etwas Last auf der Anwendung zu generieren:

Die Cloud-Shell erzeugt nun unentwegt Logausgaben, die Sie aber ignorieren können. Um nun den Service zu überwachen, müssen Sie sich mit den Definitionen von Service Level Indicators (SLI) und Service Level Objectives (SLO) vertraut machen. Bei SLIs handelt es sich um Metriken, die die Verlässlichkeit eines Services messen. Sie wählen dazu eine Metrik aus und dividieren dann die positiven Ereignisse durch die Anzahl der Gesamtereignisse und multiplizieren mal 100:

Klassische SLI-Werte sind dabei die Verfügbarkeit (Availability) oder Latenzwerte, die einen gewissen Grenzwert nicht überschreiten sollten. Darauf basierend definieren Sie SLOs. Hierbei handelt es sich um eine Vereinbarung über die Einhaltung gewisser Metrikwerte. Die SLOs sollten messbare Metriken sein, die dokumentiert und zwischen den Interessensgruppen ausgetauscht worden sind. SLOs sind darüber hinaus oft Teil eines Service Level Agreements (SLA), die Key-Performance-Indikatoren (KPI) dokumentieren, die der Kunde von einem Anbieter erwartet.

SLO erstellen

Bei der für diesen Workshop bereitgestellten App-Engine-Anwendung mündet etwa jeder 1000. Aufruf in einem Fehler. Um nun hierfür ein Service-Monitoring einzurichten, wechseln Sie in der GPC-GUI im Menü links auf die Seite "Operations / Monitoring / Services". Sofort fällt auf, dass die App-Engine-Applikation schon auf dem Dashboard auftaucht. Sobald Sie auf den "Default"-Link klicken, sehen Sie Einzelheiten zum Dienst und können mit der Erstellung eines SLOs beginnen. Dazu klicken Sie auf "[+CREATE SLO]" auf der rechten Seite, woraufhin sich wiederum ein Assistent öffnet:

1. Im ersten Schritt wählen Sie als Metrik "Availabiliy". Die Checkbox "Request-based" lassen Sie unten markiert. Dies bedeutet, dass die Verfügbarkeit über den gesamten Zeitraum berechnet wird – unabhängig, wie die Last war. Mit "Continue" gelangen Sie zur nächsten Seite.

2. Hier überprüfen Sie die SLI-Einstellungen. Wenn Sie etwas warten, sehen Sie eine Vorschau der Requests.

3. Auf der dritten Seite konfigurieren Sie schließlich den SLO. Als "Period Type" legen Sie "Rolling" und als "Period Length" sieben Tage fest. Für das Ziel nehmen wir uns 99,5 Prozent vor. Mit "Continue" kommen wir im Assistenten einen Schritt weiter.

4. Die letzte Seite gibt abschließend einen Überblick mit der Möglichkeit, die erstellte Konfiguration als JSON einzusehen. Mit "[CREATE SLO]" schließen Sie den Assistenten ab.

Beim Betrachten des SLOs fällt auf, dass alles im grünen Bereich zu liegen scheint. Sowohl der Service Level Indicator als auch das Error Budget sowie die Alerts passen. Die Begrifflichkeit des Error Budget stammt von Google. Sie beschreibt eine messbare Zahl, wieviel Fehler beziehungsweise wieviel Prozent der Zeit ein Service nicht verfügbar sein darf und dennoch als gültiges SLO gilt. In unserem Beispiel sind dies 100 Prozent minus 99,5 Prozent, also 0,5 Prozent. Ein Produktteam kann das aktuelle Error Budget nutzen, um etwa Wartungsarbeiten vorzunehmen. Ist das Budget erschöpft, müssen die Arbeiten warten, bis das Error Budget sich wieder erholt hat.

Unabhängig von den genannten Werten kann der Wunsch bestehen, Warnungen zu versenden, wenn ein SLO nicht erreicht wird. Dazu klicken Sie auf dem SLO den Link "[CREATE SLO ALERT]" an. Dabei müssen Sie wieder eine Reihe von Parametern konfigurieren:

- Lookback Duration: Dieser Wert bestimmt, über welchen Zeitraum Sie die Werte betrachten wollen. Längere Werte sind insbesondere für die Einhaltung der Compliance interessant, bei kürzeren Werten erhalten Sie schneller eine Warnung, falls Fehler auftreten. Für unser Beispiel nehmen wir einfach "10".

- Burn Rate Threshold: Mit diesem Wert bestimmen Sie, wie schnell das Error Budget verbraucht werden darf. Ein Wert von "1" auf einen Zeitraum gibt an, dass das Error Budget in einem Zeitraum genau aufgebraucht wird. Wir konfigurieren hier 1,5.

Die nächsten Schritte hinsichtlich des Notification Channels sollten bekannt sein, sodass Sie den Assistenten schnell abschließen können.

Wollen Sie mehr Fehler produzieren, können Sie die Anwendung entsprechend abändern. Wenn Sie in der Cloud-Shell die Dateien "index.js" öffnen und dort nach "random-error" suchen, können Sie in dieser Zeile durch Heruntersetzen der Zahl "1000" auf einen niedrigeren Wert, zum Beispiel "20", die Anzahl der Fehler massiv erhöhen. Mit gcloud app deploy deployen Sie die Anwendung anschließend neu. Sobald Sie die Applikation wieder aufrufen, sollten sich nun die SLO-Werte zügig vermindern.

Netzwerkmonitoring mit VPC Flow Logs

Neben dem Überwachen von einzelnen Ressourcen gehört das Netzwerkmonitoring zu dem Grundaufgaben des IT-Betriebs. Für diesen Zweck stellt Google VPC Flow Logs zur Verfügung, die sich auf jedem Subnetz aktivieren lassen und Informationen über versendete und empfangene Netzwerkpakete protokollieren. Dies sind erst einmal reine Logdaten. Dennoch kann es für viele Anwendungsfälle interessant sein, auf Basis dieser Logs eigene Metriken zu erstellen – etwa wie oft in einem Netzwerk Pakete zurückgewiesen wurden.

VPC Flow Logs lassen sich einfach aktivieren. Dazu wechseln Sie im Navigationsmenü links auf "Networking / VPC network / VPC networks" und klicken das zu konfigurierende Subnetz an. Dort wechseln Sie zuerst oben in den Edit-Modus und aktivieren dann unten die Flow Logs. Sobald Sie "On" auswählen, können Sie den Aggregations-Zeitraum sowie die Sample-Rate festlegen. Für die meisten Szenarien passen die Standardeinstellungen von fünf Sekunden für die Aggregation und die Sample-Rate von 50. Letztere definiert, wie viel Werte an Logs weitergeleitet werden. Interessant ist auch die Schätzung unten, wie viel MByte am Tag für das Subnetz zusammenkommen. Die einzelnen Daten selbst sind im Logging-Bereich einsehbar.

Um die Logs zu selektieren, wählen Sie links bei "Resource Type" "Subnetwork" aus, selektieren als Logname "compute. googleapis.com/vpc_flows" und filtern anschließend nach dem gewünschten Subnetz. Wollen Sie die Daten mihilfe von SQL-Befehlen auswerten, müssen Sie im Logging in den Legacy-Modus wechseln und anschließend eine "Log-Sink" einrichten. Als Ziel konfigurieren Sie dann "BigQuery" – das Serverless Data Warehouse von GCP. Natürlich können Sie auch mit logbasierten Metriken arbeiten. Dies gelingt, indem Sie links im Menü die Seite "Logs-based Metrics" anwählen und dann für den gewünschten Filter eine Metrik einrichten.

Fazit

Google bietet in seiner GCP-Plattform ein umfangreiches Set an Werkzeugen zum Monitoring, die mittlerweile einen hohen Reifegrad erreicht haben. Damit lässt sich auch ohne die Nutzung von Drittanbieter-Tools ein effizientes Monitoring für die Public Cloud einrichten.

Monitoring in der Google Cloud Platform