> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/learn-the-platform/de/modul-9-monitoring-und-fehlerbehebung/03-log-management.md). # Log-Verwaltung & Weiterleitung ## Die Rolle von Protokollen in den VergeOS-Betriebsabläufen Protokolle sind der Prüfpfad und das diagnostische Rückgrat jeder VergeOS-Umgebung. Sie zeichnen von Benutzern initiierte Aktionen, automatisierte Systemereignisse, Hardware-Sensorwerte und Replikationsaktivitäten auf -- und liefern damit die Nachweise, die Sie benötigen, um Probleme zu beheben, Compliance-Anforderungen zu erfüllen und nachzuvollziehen, was wann passiert ist. VergeOS ordnet Protokolle in drei unterschiedliche Kategorien ein, die jeweils einem anderen Zweck dienen und an einem anderen Ort gespeichert werden. Das Verständnis dieser Kategorien ist entscheidend, um zu wissen, wo man bei der Diagnose eines Problems nachsehen muss und wie eine langfristige Aufbewahrung sichergestellt wird. ```mermaid graph TB subgraph logTypes["VergeOS-Protokollkategorien"] direction TB SYS["Systemprotokolle
Benutzer- & automatisierte Aktivitäten
vSAN-, VM-, Netzwerkevents"] SYNC["Synchronisationsprotokolle
Aktivität der Site-Sync-Replikation
Start/Stopp, übertragene Daten"] SEL["Systemereignisprotokoll (SEL)
Hardware-IPMI-Ereignisse
Auf BMC-Hardware gespeichert"] end subgraph retention["Aufbewahrung"] UI["In der UI: 45 Tage"] HW["Auf Hardware: Begrenzte Kapazität"] EXT["Extern: Syslog-Weiterleitung"] end SYS --> UI SYNC --> UI SEL --> HW SYS --> EXT SEL --> EXT style logTypes fill:#f0f4ff,stroke:#336 style retention fill:#f0fff4,stroke:#363 ``` ## Protokolltypen im Detail ### Systemprotokolle Systemprotokolle sind die primäre Protokollkategorie in VergeOS. Sie erfassen Aktivitäten im Zusammenhang mit **vSAN-Vorgängen, VM-Lebenszyklusereignissen, Netzwerkänderungen, Benutzeranmeldungen, Konfigurationsänderungen**, und anderen systembezogenen Vorgängen. Diese Protokolle sind unerlässlich, um die detaillierten Abläufe und die Leistung der gesamten Umgebung zu verstehen. Beispiele für Einträge in Systemprotokollen sind: | Ereignistyp | Beispiel-Protokolleintrag | | ----------------------------- | ----------------------------------------------------------------------- | | **Benutzerauthentifizierung** | IP-Adresse, Benutzername, Anmeldezeitstempel | | **Passwortänderungen** | Welcher Benutzer welches Passwort von welcher Umgebung aus geändert hat | | **VM-Vorgänge** | VM gestartet, gestoppt, migriert, Snapshot erstellt | | **Speicherereignisse** | Laufwerkswarnungen, Änderungen des vSAN-Tier-Status, SMART-Warnungen | | **Netzwerkereignisse** | Netzwerk erstellt, Firewall-Regel geändert, NIC-Statusänderung | | **Systemvorgänge** | Update heruntergeladen, Knoten neu gestartet, Wartungsmodus aktiviert | Systemprotokolle sind zugänglich über das **Haupt-Dashboard** (am unteren Rand der Seite) oder durch Auswahl von **Protokolle** im oberen Menü. Jeder Protokolleintrag enthält ein **Level** (Kritisch, Fehler, Warnung oder Meldung), einen **Zeitstempel**, eine **source** (z. B. Knoten1, vSAN, Admin) und eine **Nachricht** , die das Ereignis beschreibt. ### Synchronisationsprotokolle Synchronisationsprotokolle beziehen sich speziell auf **Site-Sync (Replikation)** Vorgänge. Sie sind sowohl auf den Dashboards für eingehende als auch für ausgehende Synchronisierungen verfügbar und liefern detaillierte Statistiken für jeden Snapshot-Synchronisierungsauftrag: * **Start- und Stoppzeiten** für jeden Synchronisierungsvorgang * **Menge der geprüften Daten** -- insgesamt auf Änderungen geprüfte Daten * **Menge der gescannten Daten** -- während der Synchronisierung gelesene Daten * **Menge der gesendeten Daten** -- als übertragungsbedürftig identifizierte geänderte Daten (vor Komprimierung) * **Netto gesendete Daten** -- tatsächliche Bytes auf der Leitung (nach Komprimierung) * **Verzeichnis- und Dateizählungen** -- Umfang des Synchronisierungsvorgangs Synchronisationsprotokolle sind von unschätzbarem Wert, um den Zustand der Replikation zu überwachen, zu überprüfen, ob Disaster-Recovery-Aufträge planmäßig abgeschlossen werden, und um Bandbreiten- oder Leistungsprobleme bei der Site-zu-Site-Synchronisierung zu diagnostizieren. ### Systemereignisprotokoll (SEL) Das Systemereignisprotokoll (SEL) enthält Ereignisse aus der **Hardware-IPMI-Schnittstelle** (Intelligent Platform Management Interface). Anders als Systemprotokolle wird das SEL **direkt auf der BMC-Hardware des Servers gespeichert**, was bedeutet, dass es eine **begrenzte und feste Kapazität** hat. Sobald das SEL voll ist, können keine neuen Ereignisse mehr aufgezeichnet werden, bis es geleert wird. Das Knoten-Dashboard zeigt eine **Prozentanzeige** an, die angibt, wie viel SEL-Kapazität derzeit auf jedem Knoten verwendet wird. Zu den häufigen SEL-Einträgen gehören: * Überschreitungen von Temperaturgrenzwerten * Warnungen zur Lüfterdrehzahl * Ereignisse der Stromversorgung * ECC-Speicherfehler * Thermische Ereignisse des Prozessors * Hardware-Initialisierungsereignisse {% hint style="warning" %} **SEL-Kapazität ist begrenzt** Das SEL wird auf dem Baseboard Management Controller (BMC) des Servers gespeichert und hat eine begrenzte, feste Kapazität. Wenn das SEL vollständig voll ist, werden neue Hardwareereignisse stillschweigend verworfen. Überwachen Sie den SEL-Kapazitätsprozentsatz auf jedem Knoten-Dashboard und leeren Sie das SEL proaktiv. {% endhint %} ## Protokollaufbewahrung in der UI VergeOS bewahrt Systemprotokolle in der Benutzeroberfläche für maximal **45 Tage** auf. Danach werden die Protokolle automatisch aus der UI gelöscht. Dieses Aufbewahrungsfenster reicht für die tägliche Fehlersuche und kurzfristige Audits aus, aber Organisationen mit Compliance-Anforderungen (HIPAA, SOC 2, PCI-DSS usw.) müssen **Remote-Protokollweiterleitung** konfigurieren, um Protokolle länger aufzubewahren. ### Kontextbezogene Protokolle Eine der praktischsten Funktionen der Protokollierung in VergeOS ist **die kontextbezogene Protokollfilterung**. In vielen Bereichen der Plattform -- etwa auf dem Dashboard einer einzelnen VM, eines Netzwerks oder eines Mandanten -- gibt es eine **Protokolle** Schaltfläche, die nur die für dieses spezifische Objekt relevanten Protokolle anzeigt. Diese Eingrenzung macht es überflüssig, manuell durch Tausende von systemweiten Protokolleinträgen zu suchen. Zum Beispiel: * **VM-Dashboard → Protokolle** zeigt nur Ereignisse, die sich auf diese spezifische VM beziehen (Start, Stopp, Migration, Snapshot, Fehler) * **Netzwerk-Dashboard → Protokolle** zeigt nur netzwerkbezogene Ereignisse (Regeländerungen, Statusänderungen, Konnektivitätsereignisse) * **Mandanten-Dashboard → Protokolle** zeigt nur Ereignisse innerhalb des Umfangs dieses Mandanten Kontextbezogene Protokolle beschleunigen die Fehlersuche erheblich, indem sie das Signal-Rausch-Verhältnis genau auf das zu untersuchende Objekt eingrenzen. ## Remote-Syslog-Weiterleitung Für Organisationen, die eine längere Aufbewahrung als 45 Tage benötigen oder VergeOS-Protokolle in eine zentrale Log-Management-Plattform (Graylog, Splunk, Elastic Stack, Datadog usw.) integrieren müssen, unterstützt VergeOS **Remote-Syslog-Weiterleitung** über standardisierte Syslog-Protokolle. ### Konfigurationsschritte Die Remote-Syslog-Weiterleitung wird über **Erweiterte Einstellungen** in der VergeOS-UI konfiguriert: #### Schritt 1: Den Remote-Syslog-Server konfigurieren 1. Navigieren Sie zu **System → Einstellungen → Erweiterte Einstellungen** 2. Im **Einstellung** Spalte, geben Sie `syslog` und drücken Sie **ein** um zu suchen 3. Auswählen und bearbeiten **Remote syslog server (tcp: @@name/ip:port, udp: @name/ip:port)** 4. Geben Sie das Syslog-Ziel mit der passenden Syntax ein: | Protokoll | Syntax | Beispiel | Hinweise | | --------- | --------------- | ------------------- | ------------------------------------------ | | **TCP** | `@@:` | `@@10.10.10.10:514` | Zuverlässige Übertragung, empfohlen | | **UDP** | `@:` | `@10.10.10.10:514` | Geringerer Overhead, keine Zustellgarantie | 5. Klicken Sie auf **Senden** um zu speichern #### Schritt 2: Die Formatvorlage konfigurieren 1. Suchen Sie erneut nach `syslog` in den Erweiterten Einstellungen 2. Auswählen und bearbeiten **Vorlage, die für den Syslog-Server definiert werden soll (siehe rsyslog für das Format)** 3. Geben Sie ein Syslog-Vorlagenformat ein, das mit Ihrem Remote-Server kompatibel ist Für **Graylog** unter Verwendung des RFC-5424-Formats: ``` GRAYLOGRFC5424,"<%PRI%>%PROTOCOL-VERSION% %TIMESTAMP:::date-rfc3339% %HOSTNAME%.your-hostname-here %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\n" ``` {% hint style="success" %} **Vorlagenanpassung** Ersetzen Sie `your-hostname-here` durch Ihren tatsächlichen Hostnamen, damit Protokolleinträge in Ihrer zentralen Log-Plattform leicht identifizierbar sind. Die Vorlage folgt der rsyslog-Syntax -- siehe die [rsyslog-Dokumentation](https://www.rsyslog.com/doc/master/configuration/examples.html) für zusätzliche Formatoptionen. {% endhint %} 4. Klicken Sie auf **Senden** um zu speichern #### Schritt 3: Weiterleitung überprüfen Nach Abschluss der Konfiguration werden Protokolle an den angegebenen Syslog-Server weitergeleitet. Prüfen Sie die eingehenden Protokolle Ihres Remote-Servers, um zu bestätigen, dass VergeOS-Einträge erfolgreich empfangen werden. Häufige Prüfschritte: * Stellen Sie die Netzwerkkonnektivität zwischen VergeOS und dem Syslog-Server sicher (Port 514 oder benutzerdefinierter Port) * Verifizieren Sie, dass Firewall-Regeln Syslog-Verkehr in beide Richtungen zulassen * Prüfen Sie das Dashboard zur Protokollaufnahme des Remote-Servers auf eingehende Einträge * Erzeugen Sie ein Testereignis (z. B. An-/Abmeldung in der VergeOS-UI) und bestätigen Sie, dass es auf dem Remote-Server erscheint ### Voraussetzungen für die Syslog-Weiterleitung Bevor Sie die Remote-Protokollweiterleitung konfigurieren, stellen Sie Folgendes sicher: * **Netzwerkkonnektivität** zwischen dem VergeOS-System und dem Remote-Syslog-Server * **Firewall-Regeln** die Syslog-Verkehr zulassen (typischerweise TCP- oder UDP-Port 514 oder Ihr benutzerdefinierter Port) * **Zugriff auf die VergeOS-Systemeinstellungen** mit administrativen Rechten * Der Remote-Syslog-Server ist so konfiguriert, dass er **eingehende Verbindungen akzeptiert** aus dem VergeOS-IP-Bereich ## SEL-Verwaltung Da das SEL nur über eine begrenzte Hardwarekapazität verfügt, ist eine regelmäßige Wartung erforderlich, damit neue Ereignisse immer aufgezeichnet werden können. ### SEL-Kapazität überwachen Das **Knoten-Dashboard** zeigt eine Prozentanzeige, die die aktuelle SEL-Auslastung für jeden Knoten darstellt. Überwachen Sie diesen Indikator regelmäßig -- insbesondere bei älterer Hardware, die möglicherweise mehr IPMI-Ereignisse erzeugt. ### SEL leeren Wenn sich das SEL der vollen Kapazität nähert, leeren Sie es mit dem folgenden Verfahren: 1. Navigieren Sie zu **Infrastruktur → Knoten** 2. Doppelklicken Sie auf den gewünschten Knoten, um auf das **Knoten-Dashboard** 3. Klicken Sie auf **SEL löschen** im linken Menü 4. Klicken Sie auf **Ja** zu bestätigen {% hint style="success" %} **Proaktive SEL-Verwaltung** Erwägen Sie, einen regelmäßigen Zeitplan für das Leeren des SEL festzulegen -- zum Beispiel monatlich oder vierteljährlich --, um zu verhindern, dass es seine Kapazitätsgrenze erreicht. Exportieren Sie vor dem Leeren die SEL-Einträge an Ihren Remote-Syslog-Server oder dokumentieren Sie alle wichtigen Ereignisse für Ihre Aufzeichnungen. {% endhint %} ### Falschpositive SEL-Einträge filtern Einige Server-Hardware erzeugt repetitive oder unbedenkliche IPMI-Ereignisse, die das SEL und die Systemprotokolle überladen. Häufige Falschpositive sind: * Sensorwerte, die während der Startsequenz kurzzeitig Schwellenwerte überschreiten * Ereignisse der Stromversorgung während geplanter Wartungsfenster * Temperaturspitzen bei kurzen Lastspitzen, die sich sofort wieder normalisieren Für dauerhafte falschpositive Einträge unterstützt VergeOS das Filtern über einen hex-kodierten Syslog-Regex-Filter, der über die API konfiguriert wird. Starten Sie nach dem Anwenden des Filters den `openipmi` Dienst neu, um die Änderung zu aktivieren. Arbeiten Sie mit dem VergeOS-Support zusammen, um Hinweise zur Implementierung von SEL-Filtern zu erhalten, die speziell auf Ihre Hardwareplattform zugeschnitten sind. ## SMTP-Aktivitätsberichte Zusätzlich zu Systemprotokollen und Syslog-Weiterleitung bietet VergeOS **SMTP-Zustellungsberichte** über das SMTP-Dashboard (behandelt auf der [Abonnements & Warnungen](/learn-the-platform/de/modul-9-monitoring-und-fehlerbehebung/02-alerts.md) Seite). Diese Berichte bieten Einblick in die E-Mail-Zustellaktivitäten: * **Mail-Warteschlange** -- Ausstehende Nachrichten, Wiederholungsstatus und Zustellfehler anzeigen * **Mail-Protokoll** -- Prüfpfad aller gesendeten Abonnement-E-Mails mit Zeitstempeln und Zustellstatus * **Tägliche Zustellungszusammenfassungen** -- Verfolgen Sie die SMTP-Aktivität von gestern und heute, um zu bestätigen, dass Warnungen zugestellt werden SMTP-Aktivitätsberichte ergänzen das Protokollmanagement, indem sie einen sekundären Verifizierungskanal bereitstellen -- wenn Sie erwarten, eine Warnung zu erhalten, diese aber nicht eintrifft, kann das SMTP-Protokoll zeigen, ob die Nachricht in die Warteschlange gestellt, zugestellt oder abgelehnt wurde. ## Best Practices für das Protokollmanagement ### Protokolle extern weiterleiten Konfigurieren Sie von Anfang an eine Remote-Syslog-Weiterleitung. Die 45-tägige Aufbewahrung in der UI reicht für die meisten Compliance-Rahmenwerke nicht aus und schränkt die langfristige Trendanalyse ein. ### SEL-Kapazität überwachen Prüfen Sie regelmäßig die SEL-Prozentanzeige auf jedem Knoten-Dashboard. Leeren Sie das SEL, bevor es seine Kapazität erreicht, um den Verlust neuer Hardwareereignisse zu verhindern. ### Kontextbezogene Protokolle verwenden Wenn Sie eine bestimmte VM, ein Netzwerk oder einen Mandanten untersuchen, verwenden Sie auf dem Dashboard dieses Objekts die kontextbezogene Protokoll-Schaltfläche, um irrelevante Störungen herauszufiltern. ### Aufbewahrungsrichtlinien festlegen Definieren Sie die organisatorischen Aufbewahrungsanforderungen frühzeitig. Verwenden Sie Syslog-Weiterleitung zu einer zentralen Plattform für langfristige Speicherung, Suche und Compliance-Prüfung. {% hint style="info" %} **VMware Bridge** Kommen Sie von VMware? In VergeOS befinden sich Betriebs- und Prüfereignisse gemeinsam in einer einzigen filterbaren Systemprotokollansicht (Kritisch/Fehler/Warnung/Meldung), die in der UI 45 Tage lang aufbewahrt wird. Die Remote-Syslog-Weiterleitung wird einmal auf Systemebene über zwei Felder in den Erweiterten Einstellungen konfiguriert -- Syslog-Server und Vorlage -- statt pro Host. {% endhint %} {% hint style="info" %} **Nutanix Bridge** Kommen Sie von Nutanix? In VergeOS befinden sich Systemvorgänge und Prüfereignisse in einer Systemprotokollansicht (45-tägige Aufbewahrung in der UI); die Remote-Syslog-Weiterleitung wird einmal auf Systemebene konfiguriert. Hardwareereignisse bleiben im SEL mit derselben Anleitung zum proaktiven Leeren. {% endhint %} ## Wichtige Erkenntnisse ### Drei Protokolltypen **Systemprotokolle** für Betriebsereignisse, **Synchronisationsprotokolle** für Replikationsaktivitäten, und **SEL** für Hardware-IPMI-Ereignisse. Jeder dient einem eigenen Zweck bei der Fehlersuche. ### 45-tägige UI-Aufbewahrung VergeOS bewahrt Systemprotokolle 45 Tage lang in der UI auf. Konfigurieren Sie für längere Aufbewahrung und Compliance-Anforderungen die Remote-Syslog-Weiterleitung. ### Einfache Syslog-Einrichtung Zwei Felder in den Erweiterten Einstellungen -- Syslog-Serveradresse und Vorlagenformat -- konfigurieren die Protokollweiterleitung für die gesamte Umgebung. TCP (`@@`) für Zuverlässigkeit, UDP (`@`) für Leistung. ### SEL erfordert Wartung Das Hardware-SEL hat eine feste Kapazität. Überwachen Sie die Prozentanzeige auf jedem Knoten-Dashboard und leeren Sie das SEL proaktiv, um einen Verlust von Ereignissen zu verhindern. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.verge.io/learn-the-platform/de/modul-9-monitoring-und-fehlerbehebung/03-log-management.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.