Muster für Hybrid- und Multi-Cloud-Monitoring und -Logging

Last reviewed 2024-06-11 UTC

In diesem Dokument werden Monitoring- und Logging-Architekturen für Hybrid- und Multi-Cloud-Bereitstellungen sowie Best Practices für deren Implementierung mithilfe von Google Cloud erläutert. Mit diesem Dokument können Sie ermitteln, welche Muster und Produkte sich am besten für Ihre Umgebungen eignen.

Da das Spektrum an Anwendungsarbeitslasten in jedem Unternehmen anders ist, gelten auch für die Architektur einer Hybrid- oder Multi-Cloud-Konfiguration spezielle Anforderungen und Einschränkungen. Sie müssen Ihr Architekturdesign zwar auf diese Einschränkungen und Anforderungen zuschneiden, können aber auf verschiedenen gängigen Mustern aufbauen.

Die in diesem Dokument beschriebenen Muster lassen sich in zwei Kategorien unterteilen:

  • In einer umfassenden Architektur auf einen Blick sind alle Monitoring- und Logging-Funktionen zentralisiert, um für einen zentralen Zugriffs- und Steuerungspunkt zu sorgen.
  • In einer Architektur mit separaten Anwendungen und Vorgängen werden sensible Anwendungsdaten von weniger vertraulichen Vorgangsdaten getrennt, um die Complianceanforderungen für sensible Daten zu erfüllen.

Architekturmuster auswählen

Sie können den Entscheidungsbaum im folgenden Diagramm verwenden, um die beste Architektur für Ihren Anwendungsfall zu ermitteln.

Entscheidungsbaum zur Auswahl einer Monitoring- und Logging-Architektur

Einzelheiten zu den Architekturen werden in diesem Dokument ausführlicher erläutert. Im Allgemeinen haben Sie jedoch folgende Möglichkeiten:

  • Aus Monitoring in die Legacy-Lösung exportieren
  • Direkt in die Legacy-Lösung exportieren
  • Monitoring mit Prometheus und Fluentd oder Fluent Bit verwenden.
  • Monitoring mit BindPlane von observIQ verwenden.

Umfassende Architektur auf einen Blick

Bei einem Hybridsystem besteht das Ziel üblicherweise darin, Monitoring- und Logging-Informationen aus verschiedenen Quellen mehrerer Anwendungen und Umgebungen in eine einzige Ansicht einzubinden. Diese Art von Ansicht wird als Bereich bezeichnet, in dem alles auf einen Blick zu finden ist.

Das folgende Diagramm veranschaulicht dieses Muster, bei dem das Monitoring und Logging von Daten aus allen Anwendungen, sowohl lokalen Daten als auch Daten in der Cloud, in einem einzigen, in der Cloud gehosteten Repository zentralisiert ist.

Allgemeine Architektur für Monitoring und Logging

Diese Architektur bietet folgende Vorteile:

  • Sie haben eine einheitliche Ansicht für alle Monitoring- und Logging-Vorgänge.
  • Sie können die Datenspeicherung und -aufbewahrung zentral verwalten.
  • Zugriffssteuerung und Auditing sind zentralisiert. Sie müssen jedoch weiterhin die Sicherheit der Daten bei der Übertragung an das zentrale Repository gewährleisten.

Monitoring als zentrale Übersicht

Cloud Monitoring ist eine von Google verwaltete Monitoring- und Verwaltungslösung für Dienste, Container, Anwendungen und Infrastruktur. Verwenden Sie Google Cloud Observability, um einen zentralen Überblick zu erhalten und eine robuste Speicherlösung für Messwerte, Logs, Traces und Ereignisse zu erhalten. Die Suite bietet außerdem ein komplettes Paket an Tools für die Beobachtbarkeit, z. B. Dashboards, Berichte und Benachrichtigungen.

Alle Google Cloud-Produkte und -Dienste unterstützen die Integration in Monitoring. Darüber hinaus gibt es mehrere eingebundene Tools, mit denen Sie das Monitoring auf Hybrid- und lokale Ressourcen erweitern können.

Die folgenden Best Practices gelten für alle Architekturen, bei denen Monitoring als Lösung für einen zentralen Überblick zum Einsatz kommt:

Hybridmonitoring und Logging mit Monitoring und BindPlane von observIQ

Mit BindPlane von Googles Partner observIQ können Sie Monitoring- und Logging-Daten von lokalen VMs und anderen Cloudanbietern wie Amazon Web Services (AWS), Microsoft Azure, Alibaba Cloud und IBM Cloud in Google Cloud importieren. Das folgende Diagramm zeigt, wie Monitoring und BindPlane einen zentralen Überblick für eine Hybrid-Cloud bieten können.

Allgemeine Architektur für das Monitoring und Logging mit BindPlane und Monitoring

Diese Architektur bietet folgende Vorteile:

Weitere Informationen zur Implementierung dieses Musters finden Sie unter Logging und Monitoring von lokalen Ressourcen mit BindPlane.

Hybridmonitoring von Google Kubernetes Engine mit Prometheus und Monitoring

Mit Google Cloud Managed Service for Prometheus, einer beliebten Open-Source-Monitoring-Lösung, die vollständig von Google Cloud verwaltet wird, können Sie mit Monitoring Anwendungen überwachen, die auf mehreren Kubernetes-Clustern ausgeführt werden. Diese Architektur ist hilfreich, wenn Sie Kubernetes-Arbeitslasten ausführen, die auf Google Kubernetes Engine (GKE) in Google Cloud und Google Distributed Cloud in Ihrem lokalen Rechenzentrum verteilt sind, da sie eine einheitliche Oberfläche für beides bietet. Das folgende Diagramm zeigt, wie Prometheus und die Monitoring-Collectors zur Datenerfassung verwendet werden.

Allgemeine Architektur für das GKE-Monitoring mit Prometheus und Monitoring

Diese Architektur bietet folgende Vorteile:

  • Konsistente Kubernetes-Messwerte in Cloud-Umgebungen und lokalen Umgebungen
  • Damit können Sie Ihre Arbeitslasten global mit Prometheus überwachen und melden, ohne Prometheus manuell in großem Umfang verwalten und betreiben zu müssen.
  • Für die Verwendung von Prometheus fallen keine zusätzlichen Lizenzkosten an. Prometheus-Messwerte werden in Monitoring importiert. Die Importe sind kostenpflichtig und werden nach der Anzahl der aufgenommenen Stichproben berechnet.

Diese Architektur hat folgende Nachteile:

  • Da Prometheus nur das Monitoring unterstützt, muss das Logging separat konfiguriert werden. Im folgenden Abschnitt wird eine gängige Option für das Logging mit Fluentd oder Fluent Bit erläutert.

Wir empfehlen als Best Practice Folgendes:

  • Standardmäßig erfasst Prometheus alle verfügbaren Messwerte. Diese werden alle zu einem kostenpflichtigen Messwert. Um unerwartete Kosten zu vermeiden, sollten Sie Kostenkontrollen für das Monitoring implementieren.

GKE-Hybrid-Logging mit Fluentd oder Fluent Bit und Cloud Logging

Mit Fluentd oder Fluent Bit, einem beliebten Open-Source-Logging-Agent, können Sie in Cloud Logging Logs von Anwendungen aufnehmen, die auf mehreren GKE-Clustern ausgeführt werden. Diese Architektur ist hilfreich, wenn Sie Kubernetes-Arbeitslasten ausführen, die auf Google Kubernetes Engine (GKE) in Google Cloud und Google Distributed Cloud in Ihrem lokalen Rechenzentrum verteilt sind, da sie eine einheitliche Oberfläche für beides bietet. Das folgende Diagramm veranschaulicht den Ablauf von Logs.

Allgemeine Architektur für das GKE-Monitoring mit Fluentd oder Fluent Bit, Monitoring und Logging.

Diese Architektur bietet folgende Vorteile:

  • Sie können ein konsistentes Kubernetes-Logging für Cloud-Umgebungen und lokale Umgebungen verwenden.
  • Sie können Logging so anpassen, dass vertrauliche Informationen herausgefiltert werden.
  • Für die Verwendung von Fluentd oder Fluent Bit fallen keine zusätzlichen Lizenzkosten an. Logs, die mit Fluentd oder Fluent Bit in Logging importiert werden, sind kostenpflichtig.

Diese Architektur hat folgende Nachteile:

  • Da Fluentd und Fluent Bit nur Logging unterstützen, muss das Monitoring separat konfiguriert werden. Im vorherigen Abschnitt ist eine häufige Option für das Monitoring mit Prometheus beschrieben.

Weitere Informationen zum Implementieren dieses Musters finden Sie unter Fluent Bit für Logs der Google Kubernetes Engine anpassen

Partnerdienste als zentrale Übersicht

Wenn Sie bereits den Monitoring- oder Logging-Dienst eines Drittanbieters verwenden, z. B. Datadog oder Splunk, möchten Sie möglicherweise nicht zu Logging wechseln. In diesem Fall können Sie Daten aus Google Cloud in viele gängige Monitoring- und Logging-Dienste exportieren. Sie können einen eingebundenen Monitoring- und Logging-Dienst verwenden oder separate Monitoring- und Logging-Dienste auswählen, die Ihren Anforderungen am besten entsprechen.

Aus Logging zu Partnerdiensten exportieren

In diesem Muster autorisieren Sie den Monitoring-Dienst des Partners, z. B. Datadog, eine Verbindung zur Cloud Monitoring API herzustellen. Durch diese Autorisierung kann der Dienst alle Messwerte aufnehmen, die Logging zur Verfügung stehen, sodass Datadog einen zentralen Überblick über das Monitoring bieten kann.

Für Logging-Daten bietet Logging Exporte (Logsenken) nach Pub/Sub. Diese Exporte sind für Logging-Dienste von Partnern, z. B. Elastic und Splunk, eine leistungsstarke und robuste Methode, um in Echtzeit große Logvolumen aus Logging aufzunehmen. So können die Partnerdienste für einen zentralen Überblick über die Logs sorgen.

Die kombinierte Architektur für Logging und Monitoring ist im folgenden Diagramm dargestellt.

Allgemeine Architektur zum Exportieren von Monitoring- und Logging-Daten zu Partnerdiensten

Diese Architektur bietet folgende Vorteile:

  • Sie können weiterhin die vorhandenen Tools verwenden, mit denen Sie vertraut sind.
  • Der Google Cloud-Support hat für die Fehlerbehebung weiterhin Zugriff auf Logging-Logs.

Diese Architektur hat folgende Nachteile:

  • Partnerlösungen werden normalerweise extern gehostet. Das bedeutet, dass sie möglicherweise nicht verfügbar sind oder keine Daten erfassen, wenn Netzwerkverbindungen unterbrochen werden. Manchmal können Sie dieses Risiko durch Selbsthosting vermindern. Allerdings müssen Sie dann selbst die Infrastruktur für die Lösung pflegen.
  • Extern gehostete Dashboards stehen dem Google Cloud-Support nicht direkt zur Verfügung. Dadurch können sich Fehlerbehebung und Abhilfe verlangsamen.
  • Bei Lösungen für kommerzielle Partner können höhere Lizenzgebühren anfallen.

Hier einige ausführliche Beispiele für Integrationen:

Messwerte aus Prometheus und Logging mit Grafana analysieren

Grafana ist ein beliebtes Open-Source-Monitoring-Tool, das häufig zusammen mit Prometheus zum Erfassen von Messwerten verwendet wird. In dieser Architektur verwenden Sie Prometheus als lokale Erfassungsebene und Grafana als Lösung für einen zentralen Überblick über Google Cloud und lokale Ressourcen. Das folgende Diagramm zeigt eine Beispielarchitektur, in der Messwerte aus Google Cloud und lokalen Ressourcen analysiert werden.

Allgemeine Architektur für das Monitoring mit Grafana als Lösung für einen zentralen Überblick

Diese Architektur bietet folgende Vorteile:

  • Sie eignet sich für Hybridumgebungen mit VMs und Containern.
  • Wenn Ihre Organisation bereits Prometheus und Grafana verwendet, können Ihre Nutzer sie weiterhin verwenden.

Diese Architektur hat folgende Nachteile:

Weitere Informationen finden Sie unter Bessere Fehlerbehebung mit einem Cloud Logging-Plug-in für Grafana.

Logs mit Fluentd exportieren

Ein früheres Muster behandelte die Verwendung von Fluentd oder Fluent Bit als Log-Collector für Logging. Die gleiche grundlegende Architektur kann auch für andere Logging- oder Datenanalysesysteme verwendet werden, die Fluentd oder Fluent Bit unterstützen, einschließlich BigQuery, Elastic und Splunk. Das folgende Diagramm veranschaulicht dieses Muster.

Allgemeine Architektur zum direkten Exportieren von Logs aus Fluentd oder Fluent Bit.

Diese Architektur bietet folgende Vorteile:

  • Sie eignet sich für Hybridumgebungen mit VMs und Containern.
  • Fluentd kann aus vielen Datenquellen lesen, einschließlich Systemlogs.
  • Fluentd bietet Ausgabe-Plug-ins für viele beliebte Logging- und Datenanalysesysteme von Drittanbietern.
  • Fluent Bit kann auch aus vielen Eingaben lesen, einschließlich Systemlogs.
  • Fluent Bit bietet Ausgaben für viele beliebte Logging- und Datenanalysesysteme von Drittanbietern.

Diese Architektur hat folgende Nachteile:

  • Da Fluentd und Fluent Bit nur Logs unterstützen, muss das Monitoring separat konfiguriert werden. Im vorherigen Abschnitt finden Sie eine Beschreibung gängiger Optionen für das Monitoring mit Prometheus und Grafana.
  • Fluentd und Fluent Bit sind Tools von Drittanbietern und keine offiziellen Google-Produkte. Google bietet keinen Support für diese.
  • Exportierte Logs stehen dem Google Cloud-Support für die Fehlerbehebung nicht zur Verfügung. Insbesondere bietet Google keine Unterstützung für Google Distributed Cloud-Cluster ohne aktiviertes Logging.

Anwendungs- und Vorgangsdaten trennen

Umfassende Architekturen auf einen Blick erfordern das Streamen von Monitoring- und Logging-Anwendungsdaten in die Cloud. Möglicherweise bestehen für Sie jedoch rechtliche Bestimmungen oder Complianceanforderungen, die entweder die Aufbewahrung von Kundendaten vor Ort erfordern oder strenge Einschränkungen für das Speichern von Daten in der öffentlichen Cloud vorsehen.

Ein nützliches Muster für diese Hybridumgebungen besteht darin, sensible Anwendungsdaten wie im folgenden Diagramm dargestellt von Vorgangsdaten mit geringerem Risiko zu trennen.

Allgemeine Architektur zum Trennen von Anwendungs- und Vorgangsdaten

Anwendungs- und Systemdaten mit GKE Enterprise trennen

GKE Enterprise auf VMware, ein Teil der GKE Enterprise-Suite, bietet für das Monitoring lokaler Cluster Grafana. Darüber hinaus können Sie für das Logging eine Partnerlösung wie Elastic Stack oder Splunk installieren. Mit diesen Lösungen können Sie vertrauliche Anwendungsdaten vollständig lokal aufnehmen und aufrufen und gleichzeitig weiterhin Systemdaten nach Logging in Google Cloud exportieren. Diese Architektur wird im folgenden Diagramm veranschaulicht.

Anwendungs- und Systemdaten mit GKE Enterprise trennen

Diese Architektur bietet folgende Vorteile:

  • Vertrauliche Anwendungsdaten werden vollständig lokal gespeichert.
  • Beim lokalen Monitoring und Logging bestehen keine Cloud-Abhängigkeiten. Selbst wenn die Netzwerkverbindung unterbrochen wird, stehen sie weiterhin zur Verfügung.
  • Alle GKE-Systemdaten, sowohl lokale Daten als auch in Google Cloud gespeicherte Daten, werden in Logging zentralisiert und stehen dem Google Cloud-Support bei Bedarf zur Verfügung.

Eine Beispielimplementierung mit Elastic Stack als Partnerlösung finden Sie unter GKE Enterprise mit Elastic Stack überwachen.

Nächste Schritte