> 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-uberwachung-and-fehlerbehebung/03-log-management.md).

# Protokollverwaltung & Weiterleitung

VergeOS-Protokolltypen, 45-tägige Aufbewahrung in der Benutzeroberfläche, kontextbezogene Protokolle, Konfiguration der Weiterleitung an Remote-Syslog, SEL-Verwaltung und SMTP-Aktivitätsberichte.

## Die Rolle von Logs im Betrieb von VergeOS

Logs sind die Audit-Trail- und Diagnosegrundlage jeder VergeOS-Umgebung. Sie protokollieren vom Benutzer ausgelöste Aktionen, automatisierte Systemereignisse, Hardware-Sensorwerte und Replikationsaktivitäten -- und liefern damit den Nachweis, den Sie benötigen, um Probleme zu beheben, Compliance-Anforderungen zu erfüllen und zu verstehen, was wann passiert ist.

VergeOS ordnet Logs 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-Log-Kategorien"]
        direction TB
        SYS["System-Logs<br/>Aktivitäten von Benutzern und automatisch<br/>vSAN-, VM- und Netzwerkereignisse"]
        SYNC["Synchronisierungs-Logs<br/>Replikationsaktivität der Standort-Synchronisierung<br/>Start/Stopp, übertragene Daten"]
        SEL["Systemereignisprotokoll (SEL)<br/>Hardware-IPMI-Ereignisse<br/>Auf BMC-Hardware gespeichert"]
    end

    subgraph retention["Aufbewahrung"]
        UI["Im UI: 45 Tage"]
        HW["Auf der 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
```

## Log-Typen im Detail

### System-Logs

System-Logs sind die primäre Log-Kategorie in VergeOS. Sie erfassen Aktivitäten im Zusammenhang mit **vSAN-Operationen, VM-Lebenszyklusereignissen, Netzwerkänderungen, Benutzeranmeldungen, Konfigurationsänderungen**, und anderen systembezogenen Vorgängen. Diese Logs sind unerlässlich, um den detaillierten Betrieb und die Leistung der gesamten Umgebung zu verstehen.

Beispiele für System-Logeinträge sind:

| Ereignistyp                   | Beispiel-Logeintrag                                                     |
| ----------------------------- | ----------------------------------------------------------------------- |
| **Benutzerauthentifizierung** | IP-Adresse, Benutzername, Anmeldezeitpunkt                              |
| **Passwortänderungen**        | Welcher Benutzer welches Passwort von welcher Umgebung aus geändert hat |
| **VM-Operationen**            | VM gestartet, gestoppt, migriert, Snapshot erstellt                     |
| **Speicherereignisse**        | Laufwerkswarnungen, Statusänderungen der vSAN-Ebene, SMART-Warnungen    |
| **Netzwerkereignisse**        | Netzwerk erstellt, Firewall-Regel geändert, NIC-Statusänderung          |
| **Systemoperationen**         | Update heruntergeladen, Knoten neu gestartet, Wartungsmodus aktiviert   |

System-Logs sind über das **Haupt-Dashboard** (am unteren Rand der Seite) zugänglich oder durch Auswahl von **Logs** im oberen Menü. Jeder Logeintrag enthält ein **Level** (Kritisch, Fehler, Warnung oder Meldung), einen **Zeitstempel**, eine **Quelle** (z. B. node1, vSAN, Admin) und eine **Meldung** mit der Beschreibung des Ereignisses.

### Synchronisierungs-Logs

Synchronisierungs-Logs beziehen sich speziell auf **Standort-Synchronisierung (Replikation)** Operationen. Sie sind sowohl auf den Dashboards für eingehende als auch ausgehende Synchronisierung verfügbar und bieten detaillierte Statistiken für jeden Snapshot-Synchronisierungsauftrag:

* **Start- und Stoppzeiten** für jede Synchronisierungsoperation
* **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 der Komprimierung)
* **Netto gesendete Daten** -- tatsächliche Bytes auf der Leitung (nach der Komprimierung)
* **Verzeichnis- und Dateianzahl** -- Umfang der Synchronisierungsoperation

Synchronisierungs-Logs sind unschätzbar für die Überwachung des Replikationszustands, die Verifizierung, dass Disaster-Recovery-Aufträge planmäßig abgeschlossen werden, und die Diagnose von Bandbreiten- oder Leistungsproblemen bei der Standort-zu-Standort-Synchronisierung.

### Systemereignisprotokoll (SEL)

Das Systemereignisprotokoll (SEL) enthält Ereignisse aus der **Hardware-IPMI-Schnittstelle** (Intelligent Platform Management Interface). Im Gegensatz zu System-Logs 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 Node-Dashboard zeigt eine **Prozentleiste** an, die angibt, wie viel SEL-Kapazität derzeit auf jedem Knoten genutzt wird. Zu den häufigen SEL-Einträgen gehören:

* Überschreitungen von Temperaturschwellen
* Warnungen zur Lüftergeschwindigkeit
* Ereignisse der Stromversorgung
* ECC-Fehler im Speicher
* Thermische Ereignisse des Prozessors
* Hardware-Initialisierungsereignisse

{% hint style="warning" %}
**Die SEL-Kapazität ist begrenzt**

Das SEL wird auf dem Baseboard Management Controller (BMC) des Servers gespeichert und verfügt über eine begrenzte, feste Kapazität. Wenn das SEL vollständig voll ist, werden neue Hardwareereignisse stillschweigend verworfen. Überwachen Sie auf jedem Node-Dashboard den Prozentsatz der SEL-Kapazität und leeren Sie das SEL proaktiv.
{% endhint %}

## Log-Aufbewahrung im UI

VergeOS bewahrt System-Logs in der Benutzeroberfläche maximal **45 Tage**lang auf. Nach diesem Zeitraum werden Logs automatisch aus dem 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 **die Weiterleitung externer Logs** konfigurieren, um Logs länger aufzubewahren.

### Kontextspezifische Logs

Eines der praktischsten Merkmale des VergeOS-Loggings ist **die kontextspezifische Log-Filterung**. In vielen Bereichen der Plattform -- etwa auf dem Dashboard einer einzelnen VM, eines Netzwerks oder eines Mandanten -- gibt es eine **Logs** Schaltfläche, die nur die für dieses spezifische Objekt relevanten Logs anzeigt.

Diese Eingrenzung macht es überflüssig, manuell durch Tausende systemweiter Logeinträge zu suchen. Zum Beispiel:

* **VM-Dashboard → Logs** zeigt nur Ereignisse an, die diese spezifische VM betreffen (Start, Stopp, Migration, Snapshot, Fehler)
* **Netzwerk-Dashboard → Logs** zeigt nur netzwerkbezogene Ereignisse an (Regeländerungen, Statusänderungen, Konnektivitätsereignisse)
* **Mandanten-Dashboard → Logs** zeigt nur Ereignisse innerhalb des Geltungsbereichs dieses Mandanten an

Kontextspezifische Logs beschleunigen die Fehlersuche erheblich, indem das Signal-Rausch-Verhältnis genau auf das untersuchte Objekt eingegrenzt wird.

## Externe Syslog-Weiterleitung

Für Organisationen, die eine Log-Aufbewahrung über 45 Tage hinaus benötigen oder VergeOS-Logs in eine zentrale Log-Management-Plattform (Graylog, Splunk, Elastic Stack, Datadog usw.) integrieren müssen, unterstützt VergeOS **die externe Syslog-Weiterleitung** über standardmäßige Syslog-Protokolle.

### Konfigurationsschritte

Die externe Syslog-Weiterleitung wird über **Erweiterte Einstellungen** in der VergeOS-UI konfiguriert:

#### Schritt 1: Den externen Syslog-Server konfigurieren

1. Navigieren Sie zu **System → Einstellungen → Erweiterte Einstellungen**
2. In der **Spalte** , geben Sie `syslog` ein und drücken Sie **Eingabe** zum Suchen
3. Auswählen und bearbeiten **Externer Syslog-Server (tcp: @@name/ip:port, udp: @name/ip:port)**
4. Geben Sie das Syslog-Ziel unter Verwendung der passenden Syntax ein:

| Protokoll | Syntax          | Beispiel            | Hinweise                                       |
| --------- | --------------- | ------------------- | ---------------------------------------------- |
| **TCP**   | `@@<ip>:<port>` | `@@10.10.10.10:514` | Zuverlässige Zustellung, empfohlen             |
| **UDP**   | `@<ip>:<port>`  | `@10.10.10.10:514`  | Geringerer Overhead, keine Zustellungsgarantie |

5. Klicken Sie auf **Senden** zum 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%>1 %TIMESTAMP:::date-rfc3339% %HOSTNAME%.your-hostname-here %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\\n\"
```

{% hint style="warning" %}
Verwenden Sie das Literal `1` nach `<%PRI%>` — es ist das Versionsfeld von RFC 5424. Verwenden Sie nicht `%PROTOCOL-VERSION%`: Es wird auf der Leitung als `0` ausgegeben, und strenge RFC-5424-Collector (Promtail/Loki, Fluent Bit, moderne Graylog-Versionen) lehnen Version 0 mit Parse-Fehlern ab.
{% endhint %}

{% hint style="success" %}
**Anpassung der Vorlage**

Ersetzen Sie `your-hostname-here` durch Ihren tatsächlichen Hostnamen, damit Logeinträge in Ihrer zentralen Log-Plattform leicht identifizierbar sind. Die Vorlage folgt der rsyslog-Syntax -- konsultieren Sie die [rsyslog-Dokumentation](https://www.rsyslog.com/doc/master/configuration/examples.html) für weitere Formatoptionen.
{% endhint %}

4. Klicken Sie auf **Senden** zum Speichern

#### Schritt 3: Die Weiterleitung überprüfen

Nach Abschluss der Konfiguration werden Logs an den angegebenen Syslog-Server weitergeleitet. Überprüfen Sie die eingehenden Logs Ihres Remote-Servers, um zu bestätigen, dass VergeOS-Einträge erfolgreich empfangen werden. Häufige Überprüfungsschritte:

* Stellen Sie die Netzwerkkonnektivität zwischen VergeOS und dem Syslog-Server sicher (Port 514 oder benutzerdefinierter Port)
* Vergewissern Sie sich, dass die Firewall-Regeln Syslog-Verkehr in beide Richtungen zulassen
* Prüfen Sie das Log-Ingest-Dashboard des Remote-Servers auf eingehende Einträge
* Erzeugen Sie ein Testereignis (z. B. An- und Abmeldung an der VergeOS-UI) und bestätigen Sie, dass es auf dem Remote-Server angezeigt wird

### Voraussetzungen für die Syslog-Weiterleitung

Stellen Sie vor der Konfiguration der externen Log-Weiterleitung sicher, dass Folgendes erfüllt ist:

* **Netzwerkkonnektivität** zwischen dem VergeOS-System und dem externen Syslog-Server
* **Firewall-Regeln** die Syslog-Verkehr zulassen (typischerweise TCP- oder UDP-Port 514 oder Ihr benutzerdefinierter Port)
* **Zugriff auf die VergeOS-Systemeinstellungen** mit Administratorrechten
* Der externe Syslog-Server ist so konfiguriert, dass er **eingehende Verbindungen akzeptiert** aus dem VergeOS-IP-Bereich

## SEL-Verwaltung

Da das SEL eine begrenzte Hardwarekapazität hat, erfordert es regelmäßige Wartung, um sicherzustellen, dass neue Ereignisse stets aufgezeichnet werden können.

### SEL-Kapazität überwachen

Das **Node-Dashboard** zeigt eine Prozentleiste an, die die aktuelle SEL-Auslastung für jeden Knoten anzeigt. Überwachen Sie diesen Indikator regelmäßig -- insbesondere bei älterer Hardware, die möglicherweise mehr IPMI-Ereignisse erzeugt.

### Das SEL leeren

Wenn sich das SEL seiner 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 **Node-Dashboard**
3. Klicken Sie auf **SEL leeren** im linken Menü zuzugreifen
4. Klicken Sie auf **Ja** zur Bestätigung

{% hint style="success" %}
**Proaktive SEL-Verwaltung**

Erwägen Sie, einen regelmäßigen Zeitplan zum Leeren des SEL festzulegen -- zum Beispiel monatlich oder vierteljährlich --, um zu verhindern, dass es die Kapazität erreicht. Exportieren Sie vor dem Leeren die SEL-Einträge auf Ihren externen Syslog-Server oder dokumentieren Sie alle wichtigen Ereignisse für Ihre Unterlagen.
{% endhint %}

### Falsch-positive SEL-Einträge filtern

Einige Server-Hardware erzeugt wiederkehrende oder unkritische IPMI-Ereignisse, die das SEL und die System-Logs überladen. Häufige Fehlalarme 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 falsch-positive 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 Anleitungen zur Implementierung von SEL-Filtern zu erhalten, die speziell für Ihre Hardwareplattform gelten.

## SMTP-Aktivitätsberichte

Zusätzlich zu System-Logs und Syslog-Weiterleitung bietet VergeOS **SMTP-Zustellungsberichte** über das SMTP-Dashboard (behandelt auf der [Abonnements & Warnungen](/learn-the-platform/de/modul-9-uberwachung-and-fehlerbehebung/02-alerts.md) Seite). Diese Berichte bieten Einblick in die E-Mail-Zustellungsaktivität:

* **Mail-Warteschlange** -- Anzeigen ausstehender Nachrichten, Wiederholungsstatus und Zustellungsfehler
* **Mail-Log** -- Audit-Trail aller gesendeten Abonnement-E-Mails mit Zeitstempeln und Zustellungsstatus
* **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 Log-Management, indem sie einen sekundären Verifizierungskanal bereitstellen -- wenn Sie erwarten, eine Warnung zu erhalten, dies aber nicht geschieht, kann das SMTP-Log aufzeigen, ob die Nachricht in die Warteschlange gestellt, zugestellt oder abgelehnt wurde.

## Best Practices für das Log-Management

### Logs extern weiterleiten

Konfigurieren Sie die externe Syslog-Weiterleitung von Anfang an. Die 45-tägige Aufbewahrung im 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-Prozentleiste auf jedem Node-Dashboard. Leeren Sie das SEL, bevor es die Kapazität erreicht, um den Verlust neuer Hardwareereignisse zu verhindern.

### Kontextspezifische Logs verwenden

Wenn Sie eine bestimmte VM, ein Netzwerk oder einen Mandanten analysieren, verwenden Sie die kontextspezifische Schaltfläche Logs auf dem Dashboard dieses Objekts, um irrelevante Störmeldungen auszublenden.

### Aufbewahrungsrichtlinien festlegen

Definieren Sie frühzeitig die organisatorischen Anforderungen an die Aufbewahrung. Nutzen Sie die Syslog-Weiterleitung zu einer zentralen Plattform für langfristige Speicherung, Suche und Compliance-Prüfungen.

{% hint style="info" %}
**VMware-Brücke**

Kommt von VMware? In VergeOS leben operative und Audit-Ereignisse zusammen in einer einzigen filterbaren System-Logs-Ansicht (Kritisch/Fehler/Warnung/Meldung), die 45 Tage lang im UI aufbewahrt wird. Die externe Syslog-Weiterleitung wird einmal systemweit über zwei Felder in den Erweiterten Einstellungen konfiguriert -- Syslog-Server und Vorlage -- statt pro Host.
{% endhint %}

{% hint style="info" %}
**Nutanix-Brücke**

Kommt von Nutanix? In VergeOS leben Systemoperationen und Audit-Ereignisse in einer System-Logs-Ansicht (45-tägige Aufbewahrung im UI); die externe Syslog-Weiterleitung wird einmal systemweit konfiguriert. Hardwareereignisse bleiben im SEL mit derselben Empfehlung zur proaktiven Leerung.
{% endhint %}

## Wichtige Erkenntnisse

### Drei Log-Typen

**System-Logs** für Betriebsereignisse, **Synchronisierungs-Logs** für Replikationsaktivitäten, und **SEL** für Hardware-IPMI-Ereignisse. Jeder dient einem anderen Zweck bei der Fehlersuche.

### 45-tägige UI-Aufbewahrung

VergeOS bewahrt System-Logs 45 Tage lang im UI auf. Konfigurieren Sie die externe Syslog-Weiterleitung für längere Aufbewahrung und Compliance-Anforderungen.

### Einfache Syslog-Einrichtung

Zwei Felder der Erweiterten Einstellungen -- Syslog-Serveradresse und Vorlagenformat -- konfigurieren die Log-Weiterleitung 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 Prozentleiste auf jedem Node-Dashboard und leeren Sie das SEL proaktiv, um Ereignisverlust 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-uberwachung-and-fehlerbehebung/03-log-management.md?ask=<question>&goal=<endgoal>
```

`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.
