OpenTelemetry
Send Windows logs to OpenTelemetry over OTLP/HTTP.
DPLens collects Windows Event Log, log files, file integrity, syslog and NetFlow on the Windows host, filters and masks them there, and delivers the result as OTLP log records to an OpenTelemetry Collector or any OTLP endpoint.
- OTLP over HTTP
- Protobuf encoding
- Port 4318
- Logs
In short
DPLens 1.0 can deliver Windows logs to an OpenTelemetry Collector or any OTLP endpoint, using OTLP over HTTP with protobuf encoding, conventionally on port 4318. Events are filtered, aggregated and masked on the Windows host before they are sent, so the Collector receives a smaller, cleaner stream it can route to any backend. It is a self-hosted agent with no vendor control plane, managed across your fleet with DPLens Manager.
Why OTLP
Why send Windows logs as OTLP?
DPLens is a UK-built, self-hosted log collection and security data pipeline agent for Windows. If your telemetry already flows through OpenTelemetry, the OpenTelemetry destination lets Windows logs join that pipeline instead of needing a separate path of their own.
01
A vendor-neutral pipeline
OTLP is an open protocol, not one vendor's input, so the choice of backend stays with you rather than with the agent you deployed.
02
The Collector as a routing hub
Many teams run an OpenTelemetry Collector as the one place telemetry is received, processed and exported. DPLens feeds it; the Collector decides where logs go next.
03
Backends that accept OTLP
Where your observability platform, log store or SIEM accepts OTLP, DPLens can deliver to it without a syslog or JSON step in between.
What DPLens sends
What arrives at the Collector?
Every source DPLens collects can go to the OpenTelemetry destination as OTLP log records: Windows Event Log channels (Security, System, Sysmon and custom channels), log files, file integrity monitoring (FIM) change events, and the syslog and NetFlow or IPFIX records its receivers take in from devices around the host.
Before anything is sent, the same seven stages run as for any other destination: filter, parse, aggregate, optimise, enrich, mask and rate limit. Masking runs before anything leaves the host, so a value a rule rewrites never reaches the Collector, and every drop and mask is counted against the rule that caused it.
Configuration
How do I point DPLens at an OpenTelemetry Collector?
Add a destination, choose the OpenTelemetry destination type, and give it the endpoint URL of your Collector's OTLP/HTTP receiver, conventionally on port 4318. Then attach the destination to a pipeline, as you would any other. One pipeline can deliver to several destinations at once, so the same processed events can go to the Collector and to an existing SIEM while you move between them.
On the Collector side, enable the HTTP protocol on the OTLP receiver. DPLens sends protobuf, the OTLP/HTTP default encoding, so a standard Collector configuration receives it as it stands.
With DPLens Manager, included in every subscription, you set the destination up once and roll it out to every agent from one place.
A typical architecture
DPLens on every Windows host, one Collector, any backend
Each agent delivers straight to your Collector. DPLens Manager, included in every subscription, gives you central configuration, fleet health monitoring, and deployment and upgrades for every agent, self-hosted and air-gap capable.
DPLens on each Windows host
Collects event logs, files, FIM, syslog and NetFlow; filters, aggregates and masks on the machine that produced the data.
OTLP over HTTP on 4318
Sends the reduced stream as OTLP log records, protobuf-encoded, to the Collector's OTLP/HTTP receiver.
OpenTelemetry Collector
Receives, batches and processes logs alongside your other telemetry, under your own Collector configuration.
Any backend
The Collector exports to whatever it is configured for: an observability platform, a log store, a SIEM or an archive.
Because reduction happens on the host, the Collector and every backend behind it handle only the events you chose to keep. See SIEM cost reduction for what to filter, and how DPLens works.
Performance
Will the agent keep up?
In our lab benchmark, with Snare, Splunk S2S and NDJSON output, DPLens delivered more than 30× the throughput of established Windows agents, at about a tenth of the CPU per event. Lab figures, not a guarantee. See how we measured, and the caveats.
Secure by design
An agent you can defend in a security review.
Related reading
Other destinations and comparisons
The pipeline stages that run before the OpenTelemetry destination are documented, as are the other destination types.
FAQ
Questions OpenTelemetry teams ask
Which OTLP protocol does DPLens use?
OTLP over HTTP with protobuf encoding, the OTLP/HTTP default, conventionally on port 4318. Enable the HTTP protocol on your Collector's OTLP receiver and point DPLens at it.
What does DPLens send over OTLP?
OTLP log records. Windows Event Log, log files, file integrity changes, and syslog and NetFlow records received from other devices all arrive at the Collector as logs, already filtered and masked on the host.
Can I send to an OpenTelemetry Collector and my existing SIEM at the same time?
Yes. One pipeline can deliver to several destinations at once, so the same filtered and masked events can go to a Collector over OTLP and to a SIEM over syslog, NDJSON or the Splunk protocols, which suits a gradual migration.
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.