Einheit 7.2: Beobachtbarkeit und Betrieb

Einführung

Beobachtbarkeit bei IONOS ist nicht ein einzelnes Produkt. Es handelt sich um vier separate Ebenen, jede mit einem festen Umfang, ihrem eigenen Aufnahmepfad und ihrem eigenen Aufbewahrungsmodell. Die architektonische Arbeit besteht nicht darin, "Überwachung einschalten" zu können, sondern darin zu entscheiden, welches Signal in welche Ebene gelangt, wo die Nähte zwischen den Ebenen sind und wie man ein einziges operatives Bild über sie und über Verträge hinweg erstellt.

FinCorp, unser deutsches Finanzdienstleistungsunternehmen unter GDPR und BSI-Vorschriften, benötigt eine audit-gerechte operative Ansicht, die sich über ein reguliertes Workload-Kernsystem, eine Managed Kubernetes-Plattform und ein dediziertes VMware-Anwesen erstreckt, das jede Naht in dem Telemetrie-Modell der Plattform offenlegt. Diese Einheit behandelt die vier Ebenen, benennt die Lücken ehrlich, baut eine Metriken-Pipeline mit einer Warnung und einem Fluss-Log in dem Data Center Designer und schließt mit dem Fan-in-Muster ab, das FinCorp einen Ort gibt, an dem es korrelieren kann.

1. Die Vier Telemetrie-Ebenen und ihre Festen Bereiche

Die Plattform teilt das operationale Signal in vier Produkte auf. Keines von ihnen ist eine Obermenge der anderen, und die Grenzen sind hart, nicht konventionell.

Metriken (Monitoring Service). Ein pro-Vertrag, pro-Region-Service, der Metriken im Prometheus-Format (Zähler, Messgerät, Histogramm, Zusammenfassung) aufnimmt, mit einer JSON-Alternative, die mithilfe von Snappy komprimiert werden muss. Metriken werden von einem Agenten übertragen: Prometheus, Grafana-Agent, OpenTelemetry oder Fluent Bit, bei einem Standard-Übertragungsintervall von 1 Minute, das konfigurierbar ist. Hinter dem Endpunkt landen die Daten in Grafana Mimir und werden in einer gemanagten Grafana-Instanz pro Vertrag und pro Region visualisiert. Sie können bis zu 10 Pipelines pro Vertrag ausführen.

Protokolle (Logging Service). Ein pro-Vertrag, pro-Region-Service, der Protokollströme aus einer festen Quellensammlung aufnimmt: Kubernetes, Docker, Linux Systemd, HTTP (eine JSON-REST-API), und Generic. Der Transport erfolgt über TLS, entweder über TCP (Fluent Bit-Weiterleitung, Port 9000) oder HTTPS (Port 443). Jede Pipeline kann bis zu 5 Protokollströme aufnehmen, Sie können bis zu 10 Pipelines pro Vertrag ausführen, und die Aufbewahrungsfrist pro Stream beträgt 7, 14, 30 Tage oder unbegrenzt (Standard 30 Tage). Protokolle werden im gleichen gemanagten Grafana-System angezeigt, aber das Grafana-Abfragefenster beträgt 30 Tage; alles, was unter unbegrenzter Aufbewahrungsfrist aufbewahrt wird, kann durch eine Supportanfrage abgerufen werden, nicht im Dashboard.

Audit (Activity Logs). Der Kontroll-Flug-Audit-Trail: Wer hat was mit welcher Ressource gemacht. Er zeichnet Benutzeranmeldungen, Ressourcenbereitstellung, Konfigurationsänderungen, Datenzugriff und Ressourcenabruf, -änderung und -löschung auf. Er ist aus Sicherheitsgründen schreibgeschützt, jeder Aufruf ist ein GET gegen https://api.ionos.com/activitylog/v1, und die Aufbewahrungsfrist beträgt 35 Tage. Dies ist eine Governance-Ebene, die in Einheit 2.3 ausführlich behandelt wird; hier ist sie wichtig, weil ihr kurzes Fenster eine Exportdisziplin erzwingt, die die Metriken- und Protokolle-Ebenen nicht haben.

Netzwerkfluss (Flow Logs). Pro-Fluss-Verbindungsdatensätze (5-Tupel plus Paket- und Bytezählungen, plus ein action-Feld von ACCEPT oder REJECT, das das Firewall-Urteil zeigt) werden an einen kundenverwalteten Object Storage-Bucket als gzip-komprimierter Text emittiert, der alle 10 Minuten rotiert wird. Flow Logs-Daten werden an eine VM-Netzwerkkarte, ein Managed Network Load Balancer, ein Managed Application Load Balancer oder ein Managed NAT Gateway angehängt und erfassen IPv4- und IPv6-Daten. Diese Ebene wird in Einheit 3.2 als Firewall-Verifizierungstool aufgebaut; sie erscheint hier als Netzwerkschicht des operationellen Bildes.

Die einheitliche Oberfläche ist Grafana: Metriken und Protokolle sind beide über eine gemanagte Grafana-Instanz pro Vertrag pro Region abfragbar. Der bewusste Entwurfsaspekt ist, dass Audit- und Netzwerkflussdaten vollständig außerhalb dieses Panels leben, im Activity Log API und in Object Storage jeweils. Ein vollständiges operationelles Bild ist etwas, das Sie zusammenstellen, nicht etwas, das die Konsole Ihnen an die Hand gibt.

2. Die Lücken, um die herum zu entwerfen

Drei Grenzen sind diejenigen, die in der Produktion beißen. Jede ist ein Entwurfsinput und kein Defekt, und jede hat eine native Zusammensetzung um sie herum.

Kubernetes-Steuerungsebenen-Ereignisse fließen nicht durch die Logging Service. Die Logging Service listet Kubernetes als unterstützte Quelle, aber das bedeutet Workload- und Node-Protokolle, die Sie aus dem Cluster verschiffen, nicht die gemanagte Steuerungsebene. Der IONOS-Managed Kubernetes-SLA umfasst nur die Kubernetes-API-Ebene der Steuerungsebene, und Steuerungsebenen-Ereignisse werden nicht in Ihre Logging Service-Pipeline emittiert. Die Cluster bietet jedoch einen separaten "Protokollierung zu S3"-Schalter, der Cluster-Protokoll-Daten in einen Object Storage-Bucket schreibt; behandeln Sie dies als einen separaten, eigenständig aktivierten Pfad und nicht als Steuerungsebenen-Sichtbarkeit in Ihrem Grafana. Für Workload-Beobachtbarkeit deployen Sie einen im-Cluster-Agenten (Fluent Bit für Protokolle, ein Prometheus-kompatibler Exporteur für Metriken), der zu Ihren Logging- und Monitoring-Pipelines pushen kann. Die Nahtstelle ist die Linie zwischen der gemanagten Steuerungsebene und Ihren Workloads: Sie instrumentieren die letzteren, IONOS betreibt die ersteren.

Es gibt keine cross-vertragliche Aggregation. Monitoring- und Logging-Pipelines sind pro-Vertrag und pro-Region, und das Aktivitätsprotokoll ist pro-Vertrag mit keinem Push- und keinem Aggregations-Endpunkt. Wenn FinCorp die Produktion, Nicht-Produktion und eine Compliance-isolierte Workload über separate Verträge aufteilt (die Grenzdisziplin aus Einheit 2.1), gibt es kein natives Pane, das ihre Telemetrie vereint. Aggregation ist etwas, das Sie bauen, indem Sie jedes Vertrags-Signal in einen externen Sammler (Abschnitt 5) leiten.

Das Aktivitätsprotokoll-Aufbewahrungsfenster beträgt 35 Tage. Das ist das harte Löschhorizont für die Audit-Spur. Für ein reguliertes Unternehmen, dessen Aufbewahrungsverpflichtungen Jahre umfassen, ist das 35-Tage-Fenster ein Export-Deadline und keine Aufbewahrungsrichtlinie. Das dokumentierte Muster für die langfristige Aufbewahrung ist, Aktivitätsprotokoll-Daten auf einem Zeitplan herunterzuladen und auf einem anderen Speichermedium zu speichern, wobei IONOS Cloud Object Storage als explizit empfohlenes Ziel dient, idealerweise unter Objekt-Sperre für ein manipulationsfestes Archiv (Einheit 2.3, Einheit 5.2). Wenn Sie das Fenster verpassen, ist die Aufzeichnung weg.

3. Zentrales Logging und Hybrid-vCenter-Beobachtbarkeit

3.1 Zentrales Logging für produkteinleitendes Weiterleiten

Standardmäßig übermitteln Sie die Protokolle selbst, indem Sie einen Agenten auf einen Pipeline-Endpunkt verweisen. Zentrales Logging ist der vertragsbasierte, pro-Region-Schalter, der es integrierten IONOS Cloud-Produkten ermöglicht, ihre eigenen Protokolle an das Logging Service in Ihrem Namen weiterzuleiten, das in demselben gemanagten Grafana angezeigt wird, ohne dass jedes Produkt einen separaten Ingestions-Stack ausführt. Ein Managed Network Load Balancer, beispielsweise, sendet seine Zugriffsprotokolle an Ihr Logging Service, sobald das zentrale Logging aktiviert ist. Das gleiche Modell gilt auch für das zentrale Monitoring für das Monitoring Service.

Das zentrale Logging muss vor der Ingestion durch ein Produkt auf Ihrem Namen aktiviert werden, da es sowohl Ihre betriebliche Sicht als auch Ihre Abrechnung beeinflusst. Die Aktivierung erfolgt pro Region, und nur Vertragsadministratoren, Besitzer und Benutzer mit dem Privileg "Zugriff und Verwaltung des Logging Service" können es umschalten. Es kann über das DCD (ein pro-Region-Schalter in der zentralen Logging-Ansicht des Logging Service) aktiviert werden, über das Logging-API oder durch ein integriertes Produkt in Ihrem Namen. Welche Produkte integriert werden, wird durch Ihren Account-Manager oder den IONOS Cloud-Support bestätigt und nicht als statische Liste veröffentlicht, sodass Sie die unterstützte Menge als etwas betrachten sollten, das pro Engagement zu überprüfen ist.

3.2 vCenter-Beobachtbarkeit für das dedizierte-VMware-Anwesen

FinCorps regulierter Kern läuft auf IONOS Private Cloud, dem dedizierten gemanagten VMware SDDC (Einheit 4.4). Seine Telemetrie fließt nicht in die vier Plattformebenen. Stattdessen ist die Beobachtbarkeit für dieses Anwesen die native VMware-Tooling, die mit dem dedizierten Stack ausgeliefert wird: vCenter Server 8.0 für Host-, Cluster- und VM-Leistungsdiagramme, Ereignisse und Alarme sowie vSAN-Gesundheits- und Kapazitätsüberwachung, die im Cloud-Panel für die Speicherschicht angezeigt werden. Der vSphere-REST-API (rate-begrenzt auf 100 Anfragen pro Sekunde) ist die programmatische Naht, wenn Sie diese Daten nach außen ziehen möchten.

Nennen Sie nur, was die Matrix hier unterstützt: die dedizierte-VMware-Beobachtbarkeitsfläche ist vCenter und vSAN. Nehmen Sie nicht an, dass eine gemanagte Quer-Plattform-Brücke vorhanden ist, die vCenter-Alarme in das Logging Service einzieht; keine ist dokumentiert. Für ein Hybrid-Anwesen ist das ehrliche Modell, dass zwei Beobachtbarkeitsbereiche nebeneinander laufen, die vier Plattformebenen für cloud-native Ressourcen und vCenter/vSAN für den dedizierten VMware-Kern, die nur dort versöhnt werden, wo Sie beide absichtlich in einen gemeinsamen externen Sammler weiterleiten.

4. DCD Implementierung Schritt-für-Schritt

Sie werden den Metriken-Teil von FinCorps operativer Sicht und den Netzwerk-Fluss-Teil aufbauen: eine Metriken-Pipeline mit einer Warnung und einem Fluss-Log auf dem Rand Load Balancer. Dies realisiert zwei der vier Ebenen aus Abschnitt 1 und gibt Ihnen konkrete Ingestions-Endpunkte, auf die Sie Agenten verweisen können. Der dritte Teil, Logs, folgt dem identischen Pipeline-Muster in der DCD.

Ziel: Erstellen Sie eine Metriken-Pipeline mit einer Warnung und aktivieren Sie Flow Logs.

Voraussetzungen. Ein vorhandener Object Storage-Bucket in der Ziel-Region, den Sie besitzen (das Ziel des Fluss-Logs muss ein benutzerdefinierter Bucket sein). Das Privileg "Erstellen von Flow Logs" für die Fluss-Log-Arbeit und das Privileg "Zugriff und Verwaltung von Überwachung" für die Metriken-Pipeline. Ausgehender HTTPS auf Port 443 von überall, wo Ihre Metrik-Agenten ausgeführt werden.

Teil A: die Metriken-Pipeline (Monitoring Service). Beachten Sie eine wichtige Plattform-Grenze: die Monitoring Service-Metriken-Pipeline wird über die Monitoring Service-API erstellt, nicht über ein DCD-Erstellungsformular. Der Lebenszyklus der Pipeline (Erstellen, Abrufen, Modifizieren, Löschen) ist derzeit nur über die API-Oberfläche möglich; die DCD-Oberfläche dient zum Zugriff auf die resultierende Grafana und nicht zum Bereitstellen der Pipeline. Behandeln Sie die folgenden Schritte als den API-Ebene-Erstellungsprozess und wechseln Sie dann zu Grafana für die Warnung.

1. Wählen Sie den regionalen Endpunkt, der Ihrer Datenplatzierung entspricht, beispielsweise https://monitoring.de-txl.ionos.com/pipelines für Berlin. Die Region bestimmt, wo Metriken verarbeitet und gespeichert werden, daher sollten Sie sie konsistent mit der Workload-Residenzentscheidung halten.
2. Erstellen Sie die Pipeline mit einem PUT (oder POST) an diesen Endpunkt, der ein properties.name enthält, authentifiziert mit einem Bearer-Token. Die Antwort enthält einen einmaligen key in den Metadaten und ein grafanaEndpoint. Speichern Sie den Schlüssel bei der Erstellung; aus Sicherheitsgründen wird er nicht erneut zurückgegeben, und Sie können ohne ihn keine Metriken übertragen.
3. Konfigurieren Sie einen Metrik-Agenten (Prometheus, Grafana-Agent, OpenTelemetry oder Fluent Bit), um an den Endpunkt der Pipeline mit api/v1/push anzuhängen, und senden Sie den gespeicherten Schlüssel als Bearer-Autorisierungs-Header über Port 443. Metriken werden im Standardintervall von 1 Minute übertragen, es sei denn, Sie ändern es.
4. Öffnen Sie die verwaltete Grafana unter dem zurückgegebenen grafanaEndpoint und bestätigen Sie, dass die Metriken abfragbar sind, was die Ingestion von Ende zu Ende verifiziert.
5. Erstellen Sie die Warnung innerhalb von Grafana: Definieren Sie eine Warnungsregel für die Metrik, die Sie interessiert (für FinCorps staatlose App-Ebene eine CPU-Auslastungsschwelle, die einer Auto-Skalierungs-Aktion vorausgehen sollte), und fügen Sie einen Kontakt-Punkt hinzu, damit die Regel den Bereitschafts-Kanal benachrichtigt. Die Grafana-Warnung ist die Warnungsoberfläche; es gibt kein separates IONOS-Warnobjekt für die Metriken-Ebene.

Ein kurzer illustrativer Erstellungsauftrag (der architektonische Punkt ist, dass diese Ebene über die API und nicht über die Konsole bereitgestellt wird):

curl --location --request POST 'https://monitoring.de-txl.ionos.com/pipelines' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer $TOKEN' \
  --data '{ "properties": { "name": "fincorp-app-metrics" } }'

Teil B: Der Flow-Log (DCD). Dieses Segment ist ein echter DCD-Build, der an eine Ressource angehängt ist, die Sie bereits aus Modul 3 haben.

6. Im DCD öffnen Sie das Rechenzentrum, wählen die Edge-Ressource aus, deren Datenverkehr Sie aufzeichnen möchten. Für einen Server oder Cube öffnen Sie die Netzwerk-Registerkarte und die Eigenschaften des Netzwerk-Controllers (NIC); für ein Managed Network Load Balancer, Managed Application Load Balancer oder Managed NAT Gateway öffnen Sie die Einstellungs-Registerkarte im Inspector-Fenster.
7. Öffnen Sie das Flow-Log-Drop-down-Menü und erstellen Sie eine Regel. Legen Sie einen Namen fest (der auch zum ersten Teil des Object Storage-Objekt-Namen-Präfix wird), sodass Sie ihn nach der Ressource und der Umgebung benennen.
8. Legen Sie die Richtung auf Ingress, Egress oder Bidirektional und die Aktion auf Abgelehnt, Akzeptiert oder Beliebig fest. Für eine Sicherheits-Untersuchungs-Postur zeigt Bidirektional plus Abgelehnt, was der Firewall blockiert; für Kapazitäts- und Verbindungs-Analysen ist Akzeptiert die nützliche Menge.
9. Legen Sie das Ziel-Object Storage-Bucket auf Ihr bestehendes benutzerdefiniertes Bucket in der Region fest. Speichern Sie. Die Aufzeichnungen beginnen, als .log.gz-Objekte zu landen, die alle 10 Minuten rotiert werden.
10. Wenden Sie eine Lebenszyklus-Richtlinie auf das Bucket an, um die Flow-Log-Objekte zu alterieren, da Flow Logs keine integrierte Aufbewahrung haben: Die Aufbewahrung wird vollständig vom Kunden durch eine Object Storage-Lebenszyklus-Richtlinie oder manuelle Löschung gemanagt.

Häufige Fehler:

• Erwartung eines "Erstellen Sie eine Pipeline"-Buttons für Metriken im DCD. Die Monitoring Service-Pipeline ist API-provisioniert; nur der Grafana-Zugriff landet in der DCD-Oberfläche. Planen Sie den Metriken-Build als einen API-Schritt und nicht als Konsole-Klick.
• Nicht speichern des Überwachungspipeline-Schlüssels bei der Erstellung. Der Schlüssel wird einmal zurückgegeben und nie wieder. Verlieren Sie ihn und Sie müssen die Pipeline neu erstellen. Die gleiche Einmal-Schlüssel-Regel gilt für eine Logging Service-Pipeline.
• Behandeln von "Kubernetes" in der Logging Service-Quellliste als Kontroll-Flugzeug-Sichtbarkeit. Es handelt sich um Ihre in-Cluster-Workload-Protokolle nur; Kontroll-Flugzeug-Ereignisse kommen nie dorthin. Stellen Sie einen in-Cluster-Agenten bereit und warten Sie nicht auf Ereignisse, die nie eintreten werden.
• Annahme, dass die Flow-Log-Aufbewahrung für Sie gemanagt wird. Das Löschen der Flow-Log-Regel löscht nicht die bereits geschriebenen Objekte, und es gibt keine automatische Ablaufzeit. Ohne eine Bucket-Lebenszyklus-Richtlinie wächst das Archiv und wird für immer berechnet.
• Einrichten eines Flow-Logs auf ein Bucket, das Sie nicht besitzen oder in der falschen Region. Das Ziel muss ein benutzerdefiniertes Bucket sein; Fehlziele liefern die Aufzeichnungen stillschweigend nicht.
• Einlassen eines Leerlaufs einer Pipeline. Eine Logging- oder Monitoring-Pipeline wird von der Erstellung bis zur Löschung berechnet, unabhängig davon, ob Daten fließen; das Stoppen des Agents stoppt die Berechnung nicht. Löschen Sie Pipelines, die Sie nicht verwenden.
• Vergessen des 35-Tage-Fensters des Activity-Logs. Es handelt sich nicht um eine Aufbewahrung, sondern um ein Löschungshorizont. Planen Sie den Export zu Object Storage vor dem 35. Tag, oder die Prüfungs-Aufzeichnung ist nicht wiederherstellbar.

5. Fan-In zu einem externen SIEM

Für ein Unternehmen wie FinCorp produziert das vertragliche, regionale, vierstufige Modell nicht die einzelne korrelierte Ansicht, die ein Sicherheits-Operations-Team und ein Auditor benötigen. Das Unternehmensmuster ist Fan-in: Jede Ebene aus jedem Vertrag fließt in ein externes SIEM ein, das zum System der Aufzeichnungen für Korrelation, langfristige Aufbewahrung und Alarmierung im gesamten Besitztum wird. Die Plattform bietet Ihnen die Möglichkeiten, dies ohne einen gemanagten Forwarder zu tun:

• Protokolle und Metriken: Richten Sie Ihre Agenten (oder die produktinitiierten Forwarder von Central Logging) auf die IONOS-Pipelines für die Plattform-Grafana aus, und leiten Sie parallel die gleichen Streams von Ihren Agenten an den SIEM-Sammler weiter. Die Logging Service gibt auch ein schreibgeschütztes Telemetrie-API (/api/v1/query, /api/v1/query_range, /api/v1/series, authentifiziert mit dem gleichen Cloud-API-Token) aus, das ein SIEM abfragen kann, obwohl die agentenseitige doppelte Versandung der direktere Weg ist.
• Netzwerkfluss: Flow Logs landen bereits als gzip-Text in Object Storage; das SIEM verarbeitet sie aus dem Bucket, das auch als dauerhaftes Archiv dient.
• Prüfung: Ein geplanter Job zieht die Aktivitätsprotokolle über ihre GET-only-API vor dem Ende des 35-Tage-Fensters und leitet die Aufzeichnungen in das SIEM weiter, wodurch gleichzeitig die langfristige Aufbewahrung und die korrelierte Verarbeitung über Verträge hinweg erfüllt werden.
• Hybride VMware: Die vSphere-REST-API und vCenter-Alarmanlagen werden aus dem dedizierten Besitztum in das gleiche SIEM weitergeleitet, wodurch die beiden Überwachungsbereiche an dem einen Punkt zusammengeführt werden, an dem die Vereinigung sinnvoll ist.

Dies ist die gleiche Kompositionslehre, die die Plattform an anderer Stelle wiederholt: Es gibt kein gemanagtes Produkt für die vertragsübergreifende Aggregation, also komponieren Sie es selbst. Object Storage ist das dauerhafte Zentrum, das SIEM ist das Korrelationshirn und die Endpunkte der einzelnen Ebenen sind die Zapfsäulen.

Zusammenfassung

IONOS-Beobachtbarkeit umfasst vier feste Bereiche (Metriken über das Monitoring Service, Protokolle über das Logging Service, Prüfung über das Activity Logs und Netzwerkfluss über das Flow Logs), die nur teilweise in Grafana vereinigt sind, wobei Prüfungs- und Flussdaten absichtlich außerhalb dieses Bereichs liegen. Die tragende operationale Arbeit besteht darin, jedes Signal bewusst zu leiten, um die drei Lücken zu überbrücken (keine Steuerungs-Pläne-Ereignisse in der Protokoll-Ebene, keine cross-vertragliche Aggregation, ein 35-Tage-Prüfungsfenster), unter Verwendung von Central Logging für das produkteinleitende Weiterleiten, unter Behandlung des dedizierten VMware-Anwesens als separates vCenter/vSAN-Beobachtbarkeitsdomäne und unter Weiterleitung aller Daten in ein externes SIEM, wo Korrelation und langfristige Aufbewahrung tatsächlich stattfinden.

Wichtige Punkte:

• Vier Bereiche, feste Bereiche: Monitoring Service (Prometheus-Metriken, push-basiert, Grafana Mimir), Logging Service (fünf Quelltypen, 5 Streams pro Pipeline, 7/14/30/unbegrenzte Aufbewahrung), Activity Logs (nur lesender GET, 35-Tage-Fenster), Flow Logs (5-Tupel-Aufzeichnungen zu einem benutzerdefinierten Object Storage-Bucket, kundenseitig verwaltete Aufbewahrung).
• Die Monitoring Service-Metrik-Pipeline ist API-bereitgestellt, nicht ein DCD-Erstellungsformular; der einmalige Pipeline-Schlüssel muss bei der Erstellung gespeichert werden, und inaktive Pipelines werden immer noch berechnet.
• Kubernetes-Steuerungs-Pläne-Ereignisse erreichen nie das Logging Service; instrumentieren Sie die Workloads mit einem im Cluster-Agenten und behandeln Sie Cluster "Protokollierung zu S3" als separaten Pfad.
• Es gibt keine cross-vertragliche Aggregation und die Prüfungs-Spur löscht sich nach 35 Tagen, sodass Aggregation und langfristige Aufbewahrung extern aufgebaut werden, mit Object Storage als dauerhaftem Hub und einem SIEM als Korrelationspunkt.
• Central Logging ist ein pro Region, vertragsbezogener Schalter (administrator-gesteuert), der es integrierten IONOS-Cloud-Produkten ermöglicht, Protokolle für Sie weiterzuleiten; das dedizierte VMware-Anwesen wird durch vCenter 8.0 und vSAN beobachtet, eine separate Domäne, die nur im SIEM ausgleicht.

Wichtige Begriffe:

• Telemetrie-Ebene: eine der vier festen Bereiche der Beobachtbarkeitsprodukte (Metriken, Protokolle, Prüfung, Netzwerkfluss), jede mit ihrem eigenen Aufnahmepfad und Aufbewahrungsmodell.
• Central Logging: eine vertragsbezogene, pro-Region-Fähigkeit, die es integrierten IONOS-Cloud-Produkten ermöglicht, ihre Protokolle zum Logging Service auf Ihre Veranlassung hin weiterzuleiten, in der verwalteten Grafana dargestellt.
• Fluss-Protokoll: eine pro-Ressourcen-Regel, die 5-Tupel-Verbindungs-Aufzeichnungen mit dem Firewall-Urteil ACCEPT/REJECT zu einem kundeneigenen Object Storage-Bucket ausgibt, alle 10 Minuten rotiert.
• Fan-in: das Unternehmens-Aggregationsmuster, alle Ebenen von jedem Vertrag in ein externes SIEM für cross-vertragliche Korrelation und langfristige Aufbewahrung weiterzuleiten.

Weitere Lektüre

• Einheit 2.3: Activity Logs und die Audit-Trail (die Audit-Ebene und die Export-Frist)
• Einheit 3.2: Netzwerksicherheit: Firewall und Sicherheitsgruppen (Flow Logs als Firewall-Verifizierungstool)
• Einheit 4.4: Private Cloud (Dedicated VMware) (das dedizierte Anwesen über vCenter und vSAN beobachtet)
• Einheit 6.1: Kubernetes-Plattform-Design (warum Control-Plane-Ereignisse außerhalb der Logging-Ebene liegen)
• IONOS Cloud Architecture Center