Recommended: Standalone

Applies to: Splunk and alternative backends

In this recommended configuration uberAgent talks directly to the backend servers. This has the advantage that the overall footprint on the monitored endpoints is smaller compared to architecture options that require Splunk Universal Forwarder.

Configuration highlights

• Communications: uberAgent sends data directly from the endpoint to the backend servers
• Splunk backends: on the indexers, either a TCP port is opened or HTTP Event Collector is configured
• Alternative backends: uberAgent makes use of the backend’s native REST API

Pros

• Smallest footprint

Cons

• uberAgent versions before version 6.2 don’t provide optional storage of collected data on disk before sending it to the backend. Starting with version 6.2 uberAgent comes with its own disk buffering feature, our persistent output queue.

Alternative: Standalone With Splunk’s Universal Forwarder

Applies to: Splunk backends only

Similar to Standalone mode, but uberAgent sends the data it collects to a locally installed Splunk Universal Forwarder. If you have deployed Universal Forwarder on your monitored endpoints anyway you might want the forwarder to handle all Splunk communications.

Configuration highlights

• Communications: uberAgent sends data to the local forwarder’s TCP port which in turn sends data to the Splunk indexers
• Splunk Universal Forwarder: a TCP port is opened on each endpoint (for local access only)

Pros

• All Splunk communications are handled by Splunk components
• Additional data can be collected via Universal Forwarder (log files, Windows event logs, scripts)
• Collected data can optionally be persisted to disk before sending off to Splunk

Cons

• Larger footprint than the recommended architecture