Choosing a destination

DPLens delivers to four kinds of receiver. Which you choose is usually decided by what your SIEM accepts.

Choosing a transport

Why UDP is different

UDP has no acknowledgement. The agent hands the packet to the network and the network says nothing back, so DPLens cannot know whether it arrived and cannot retry it. If the receiver is down, restarting, or simply busy, those events are gone and nothing can tell you how many — there is no counter for a loss the machine never learns about.

The cache and failover settings still exist on a UDP destination, but they can only act on failures this machine can see — no route to the host, or the send itself failing. They cannot recover a packet lost in transit, which is the common case. The console shows no cache depth for a UDP destination and labels it Best effort — no delivery guarantee.

Use TCP or TLS wherever your receiver allows it.

What delivery gives you

On TCP and TLS destinations, where the transport tells DPLens whether the receiver took the events:

• A disk cache per destination. If the receiver is unreachable, events queue on disk rather than being dropped, and are delivered when it comes back.
• Failover. Give an ordered list of addresses and DPLens moves to the next when the current one stops accepting, then moves back when it has recovered and stayed healthy.
• Reconnection with backoff. A receiver that is down is not hammered; the interval grows up to a ceiling you can set.
• Counted losses. If the cache fills and your policy is to drop, the number is counted and shown. Nothing is discarded silently.

The one gap on plain TCP and TLS

TCP and TLS tell DPLens that the network accepted the bytes, not that your receiver durably stored them. So if a receiver crashes or hard-partitions in the moment a batch is in flight, that one batch can be lost even though DPLens counted it sent — the connection carried no application-level acknowledgement to say otherwise. It is bounded: at most the batch in flight at each connection drop, not a share of the outage. A receiver that simply stops accepting is handled by the cache and failover above without loss; this gap is only the batch already on the wire when the far end dies.

If you need a receiver-acknowledged guarantee, use the Splunk destinations: HTTP Event Collector and Splunk-to-Splunk both wait for the indexer's acknowledgement before an event is considered delivered, and re-send it otherwise. Turn acknowledgement on there when the events matter more than the throughput.

Sizing the cache

The cache is your outage budget. Ask how long an outage you want to survive, and let the console do the rest: when you set a size, it tells you how many hours of your measured traffic that holds.

Also set Keep free on the volume so a cache cannot fill the disk out from under the rest of the machine.

Sending to more than one place

Two common shapes:

• One pipeline, several destinations — the same processed events go to each. A hot SIEM and a cheap archive, for example.
• Several pipelines, one destination — different sources processed differently, converging on one queue.

Set both up on the Pipeline page.

Formats at a glance

If you have a choice, NDJSON preserves the most: parsing, enrichment and normalisation all survive as named fields rather than being flattened into a message string.