> For the complete documentation index, see [llms.txt](https://docs.enginsight.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.enginsight.com/docs/knowledge-base/troubleshooting/in-meinem-enginsight-event-relay-kommen-keine-logs-an-was-kann-ich-tun.md).

# In meinem Enginsight Event-Relay kommen keine Logs an. Was kann ich tun?

Die Einrichtung von [Event-Relays](https://docs.enginsight.com/docs/manual/bedienung-der-plattform/siem/allgemeine-kollektoren/event-relay) bietet dir die Möglichkeit, den Enginsight Agenten Pulsar als Syslog-Relay einzusetzen, der Syslog-Daten von Quellen empfängt, auf denen kein Pulsar installiert werden kann (z.B. Firewalls wie Fortigate, Cisco, Sophos, oder generische Syslog-Sender), sie verarbeitet und an das Enginsight SIEM weiterleitet.

Wenn Logs zwischen einer Quelle und einem Event-Relay nicht ankommen und damit auch nicht im [Data Lake](https://docs.enginsight.com/docs/manual/bedienung-der-plattform/siem/data-lake) erscheinen, liegt dies häufig an einer Nichtübereinstimmung des Syslog-Formats zwischen Quelle (Sender) und Event-Relay (Empfänger).

***

Nimm folgende Schritte vor, um zu überprüfen, ob die eingestellten Syslog-Formate übereinstimmen.

{% stepper %}
{% step %}

### Bestätigen, dass der Pulsar auf dem richtigen Port lauscht

Bestätige mit folgenden Befehlen, dass der Pulsar auf dem richtigen Port lauscht:

* **Für UDP**:

```
ss -uapn | grep :5140
```

Die erwartete Ausgabe ist beispielsweise folgende:

```
UNCONN 0 0 0.0.0.0:5140 0.0.0.0:* users:(("ngs-pulsar",pid=1552167,fd=9))
```

* **Für TCP entsprechend**:

```
ss -tapn | grep :5140
```

Wenn hier nichts ausgegeben wird, liegt das Problem nicht beim verwendeten Syslog-Format, sondern bei der Konfiguration des Kollektors.
{% endstep %}

{% step %}

### Gesendete Pakete mit `tcpdump` mitschneiden

Schneide nun gesendete Pakete mit folgendem Befehl mit:

* **Für UDP**:

```
sudo tcpdump -ni <Interface> port 5140 -A
```

{% hint style="info" %}
Vergiss dabei nicht, `<Interface>` mit dem entsprechenden Netzwerkadapter zu ersetzen, z.B. `enp1s0`, `eth0` oder `any`.
{% endhint %}

* **Für TCP**:

```
sudo tcpdump -ni <Interface> tcp port 5140 -A
```

{% hint style="info" %}
Optional kannst du den Befehlen zudem den Parameter `-c 20` hinzufügen. Dies begrenzt den tcpdump auf 20 Pakete, danach wird er automatisch beendet.
{% endhint %}
{% endstep %}

{% step %}

### Das verwendete Syslog-Format herausfinden

Ein typischer mitgeschnittener Payload sieht wie folgt aus:

```
15:16:30.208451 IP 10.10.10.100.25000 > 10.10.42.254.5140: UDP, length 657
E....+..?..w<189>date=2026-05-27 time=15:16:30 devname="GATE01" ...
```

{% hint style="info" %}
Du kannst hier die Header-Bytes (`E....+..?..w`) ignorieren. Dies sind IP/UDP-Header in ASCII-Repräsentation. Relevant ist der Payload ab dem Zeichen `<`.
{% endhint %}

#### RFC 3164 (BSD) oder RFC 5424

Die Syslog-Standards **RFC 3164 (BSD)** und **RFC 5424** beginnen beide mit dem Priority-Feld `<PRI>` in spitzen Klammern. Im obigen Payload entspricht dies `<189>`.

Danach unterscheiden sich die Syslog-Standards wie folgt:

* **RFC 3164 (BSD)**: Es folgt direkt ein Datum im Klartext, ein Monatsname oder ein Schlüssel-Wert-Paar, z.B. `<189>date=2026-05-27 time=15:16:30 devname="GATE01"`&#x20;
* **RFC 5424**: Es folgt eine `1` (dies entspricht der Versionsnummer des Standards), gefolgt von einem Leerzeichen und einem ISO-8601-Zeitstempel, z.B. `<189>1 2026-05-27T15:16:30.000Z`

#### RFC 6587

Wenn die Logs per TCP gesendet werden und das Paket mit einer Zahl gefolgt von einem Leerzeichen beginnt (`657 <189>...`), liegt **Octet-Counting Framing** nach **RFC 6587** vor.&#x20;

Die Zahl gibt dabei die Länge der folgenden Nachricht an. Dies ist im Prinzip kein eigener Inhalts-Standard, sondern ein Transport-Wrapper um RFC 3164 oder 5424, sollte aber auch zu den Einstellungen des Event-Relays passen.
{% endstep %}

{% step %}

### Mit der Konfiguration des Event-Relays in Enginsight abgleichen

1. Navigiere in der Enginsight-Plattform zu **SIEM** → **Allgemeine Kollektoren** → [Event-Relays](https://docs.enginsight.com/docs/manual/bedienung-der-plattform/siem/allgemeine-kollektoren/event-relay) und klicke auf das betroffene Event-Relay, um es zu bearbeiten.
2. Überprüfe, welches Syslog-Format du im Feld **Format** angegeben hast und ob es mit dem Format des Senders, das du [zuvor ermittelt hast](#das-verwendete-syslog-format-herausfinden), übereinstimmt.
3. Ändere das Format bei Nichtübereinstimmung entsprechend ab.
4. Klicke auf **Änderungen speichern**.
5. Warte 5 bis 10 Minuten und prüfe, ob die gewünschten Logs nun unter **SIEM** → [Data Lake](https://docs.enginsight.com/docs/manual/bedienung-der-plattform/siem/data-lake) angezeigt werden.&#x20;
   {% endstep %}
   {% endstepper %}

***

## Weitere Hinweise

**CEF ist kein Syslog-Format**

* Wenn der Sender auf CEF (Common Event Format) umgestellt wird, ändert dies den Payload-Inhalt, jedoch nicht das Syslog-Format. Dies bleibt typischerweise RFC 3164. In Enginsight muss dann zusätzlich ein passender [Extraktor](https://docs.enginsight.com/docs/manual/bedienung-der-plattform/siem/erweiterte-einstellungen/extraktoren) konfiguriert werden.

**Verwendung von TLS über Port 6514**

* Bei der Nutzung von TLS über Port 6514 hilft der Befehl `tcpdump -A` nicht, da der Payload verschlüsselt ist. In diesem Fall muss das verwendete Syslog-Format auf dem Sender direkt überprüft werden.

***