Syslog, Snare and NDJSON
Forward Windows logs to any receiver that takes syslog, Snare or JSON lines.
rsyslog, syslog-ng, an existing Snare receiver, a SIEM's syslog collector, or a JSON collector in front of a data lake. DPLens speaks each receiver's format, over TLS where it can, with a disk cache for when the receiver cannot be reached.
- RFC 5424
- RFC 3164
- Snare
- NDJSON
- Raw relay
In short
DPLens forwards Windows logs to any receiver that accepts syslog (RFC 5424 or RFC 3164), Snare records or newline-delimited JSON. Choose RFC 5424 over TLS where the receiver supports it, Snare where an existing parser expects Snare records, and NDJSON where you want fields kept intact. On TCP and TLS each destination has its own disk cache and failover list.
Choosing
Which format should I send?
DPLens is a UK-built, self-hosted log collection and security data pipeline agent for Windows. Choose the format by what your receiver parses; if you have a choice, NDJSON preserves the most.
| Format | Shape | Choose it when |
|---|---|---|
| RFC 5424 syslog | Structured syslog: precise timestamp with offset, structured data | Most current SIEMs and syslog servers. Prefer this |
| RFC 3164 syslog | The classic syslog line | The receiver requires it |
| Snare | Snare's tab-separated fields | A collector already parses Snare records |
| Snare inside syslog | The same Snare fields inside an RFC 3164 syslog line | The collector expects a syslog wrapper; the console's Snare preset selects this |
| NDJSON | One JSON object per line; the default | You want parsing, enrichment and normalised names kept as fields |
| Raw | The original record, unwrapped | Relaying data, such as syslog DPLens received from other devices, untouched |
Transport
RFC 5424 over TLS or RFC 3164 over UDP?
The console's two syslog presets are Syslog SIEM, modern (TLS, RFC 5424, port 6514) and Syslog, legacy (UDP) (UDP, RFC 3164, port 514). Choose the modern preset wherever your receiver supports it.
Over TLS or TCP, the connection tells DPLens when the receiver stops accepting. That gives each destination a disk cache, automatic reconnection, an ordered failover list, and counted drops if the cache fills and your policy is to drop. UDP is there for receivers that expect it.
TLS encrypts the stream and validates the receiver's certificate by default, against the Windows trust store or a CA you supply, with mutual TLS where the receiver asks for a client certificate. Use plain TCP on networks you control.
Receivers
Notes for common receivers
On a stream, the receiver must know where one message ends. Octet-counted framing prefixes each message with its length, so a message containing a newline cannot be split; newline framing separates them with a line feed. If events arrive truncated or run together, this is almost always the setting to change.
rsyslog
Its TCP input accepts both octet-counted and newline-framed syslog, and it can receive over TLS. Send RFC 5424 syslog with octet-counted framing.
syslog-ng
Its syslog() source is built for RFC 5424 with octet-counted framing, and its network() source for newline-separated messages. Set DPLens's framing to match the source you configured.
SIEM syslog collectors
Other SIEMs with a syslog listener receive DPLens as they would any syslog sender. Check which parser your SIEM applies to Windows events in the format you choose.
JSON collectors and data lakes
Any collector with a TCP JSON-lines input can take NDJSON and write it wherever your data lake lives. Each record carries source_id and a source_seq sequence number, so gaps and duplicates are detectable downstream.
Snare format
Can I keep my Snare receiver and its parser?
Yes. If a collector already parses Snare records, DPLens can send them, usually over TCP on 514, or TLS where the collector supports it. The category column comes from the event's task display name, so set message rendering on the Windows Event Log source to the Snare option and the column is filled. You set severity, hostname, criticality and, for Snare inside syslog, the syslog facility. The replacement procedure is on Snare agent replacement, and DPLens vs Snare compares the two agents.
Header fields
Syslog header settings worth checking
| Setting | What to set |
|---|---|
| Facility | What your receiver routes on; 13 (log audit) is common for security data |
| Severity | 0 to 7, to suit your receiver's routing |
| Hostname | This machine's name by default; many receivers identify the sender by it |
| Application name | The value your receiver routes or tags on |
| Enterprise ID | Your organisation's own IANA number, if your receiver keys on it |
Secure by design
An agent you can defend in a security review.
How to do it
In the documentation
FAQ
Questions engineers ask
My receiver shows events run together or cut off. What is wrong?
Almost always framing. Switch between octet-counted and newline framing to match what the receiver expects, and watch Live stream to see the exact bytes sent.
Can DPLens relay syslog from firewalls and other devices?
Yes. Its syslog receiver accepts RFC 3164 and 5424 over UDP or TCP from the addresses you allow, and can forward those events in any format, including raw. In NDJSON, relayed events keep the identity of the device that produced them. Each enabled receiver uses one licence seat, however many devices send to it: see the licensing model.
See it on your own logs
Try DPLens on one Windows server before you talk to anyone.
Book a demo, or request an evaluation licence and install it on a test host. The documentation covers everything from requirements to Group Policy rollout.