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.
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.
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:
- Richten Sie Logsenken für Ihre Organisation ein, um die Complianceanforderungen für die Logaufbewahrung zu erfüllen.
- Richten Sie für eine schnelle Analyse von Logereignissen Logexporte nach BigQuery für Sicherheits- und Zugriffsanalysen ein.
- Führen Sie SQL-Abfragen über Log Analytics aus, um Logs zu analysieren, die in Ihrem Log-Bucket gespeichert sind.
- Bei Projekten, die sensible Daten enthalten, sollten Sie Audit-Logs zum Datenzugriff aktivieren, damit Sie nachverfolgen können, wer auf die Daten zugegriffen hat.
- Sie können Logdaten filtern, um vertrauliche Informationen wie Sozialversicherungsnummern, Kreditkartennummern und E-Mail-Adressen zu entfernen. Sie können mit einer benutzerdefinierten Fluentd-Konfiguration, einer benutzerdefinierten Fluent Bit-Konfiguration oder einer Aufnahme mit Logausschlüssen filtern. Sie können auch ungefilterte Logs separat exportieren, um die Complianceanforderungen zu erfüllen.
- Analysieren Sie Ihre Monitoring- und Logging-Nutzung und implementieren Sie Kostenkontrollen, um Ihre Kosten zu optimieren. Monitoring und Logging sind verwaltete Dienste mit volumenbasierten Gebühren für Logs und Messwerte.
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.
Diese Architektur bietet folgende Vorteile:
- Neben dem Monitoring von Ressourcen wie VMs verfügt BindPlane über eine eingebundene umfassende Integration für über 50 beliebte Datenquellen.
- Für die Verwendung von BindPlane fallen keine zusätzlichen Lizenzkosten an. BindPlane-Messwerte werden als benutzerdefinierte Messwerte in Monitoring importiert, die kostenpflichtig sind. Ebenso werden BindPlane-Logs zum gleichen Preis wie andere Logging-Logs abgerechnet.
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 auf GKE on VMware 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.
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 finden Sie eine gängige Option für das Logging mit Fluentd oder Fluent Bit.
Wir empfehlen als Best Practice Folgendes:
- Standardmäßig erfasst Prometheus alle verfügbaren Messwerte. Diese werden alle zu einem kostenpflichtigen Messwert. Implementieren Sie Kostenkontrollen für Monitoring, um unerwartete Kosten zu vermeiden.
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 auf GKE on VMware in Ihrem lokalen Rechenzentrum verteilt sind, da sie eine einheitliche Oberfläche für beides bietet. Das folgende Diagramm veranschaulicht den Ablauf von Logs.
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 mithilfe von 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 zur Implementierung dieses Musters finden Sie unter Logging-Logs für Google Kubernetes Engine mit Fluentd anpassen oder Logging-Logs für Google Kubernetes Engine mit Fluent Bit 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.
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:
- Datadog: Compute Engine-Messwerte im Blick behalten und Logging-Logs erfassen
- Elastic: Logging-Logs nach Elastic Cloud exportieren
- Splunk: Szenarien für den Logging-Export
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, mit der Messwerte aus Google Cloud und lokal analysiert werden.
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:
- Da Prometheus nur das Monitoring unterstützt, muss das Logging separat konfiguriert werden, z. B. mit Fluentd oder dem Cloud Logging-Plug-in für Grafana.
- Prometheus ist ein Open-Source-Tool und erweiterbar, unterstützt jedoch nur eine begrenzte Anzahl an Integrationen von Unternehmenssoftware.
- Prometheus und Grafana sind Tools von Drittanbietern und keine offiziellen Google-Produkte. Google bietet keinen Support für Prometheus oder Grafana.
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.
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 GKE on VMware 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.
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.
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
- Weitere Informationen zu Best Practices für Hybrid- und Multi-Cloud-Lösungen finden Sie in der Reihe Muster und Praktiken für Hybrid- und Multi-Clouds, einschließlich Architekturmustern und sichere Netzwerkarchitekturmuster.
- Melden Sie sich für die Aufgabenreihe für Best Practices zu Cloud Kubernetes an, um praxisorientierte Übungen zur Beobachtbarkeit zu erhalten und mehr über GKE zu erfahren.
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center