Recommended: Standalone

In this recommended configuration uberAgent runs as its own Windows system service and talks directly to the Splunk servers. This has the advantage that the overall footprint on the monitored endpoints is smaller compared to architecture options that require Universal Forwarder.

Configuration highlights

• Monitored endpoints: uberAgent runs as a system service
• Splunk indexers: either a TCP port is opened or HTTP Event Collector is configured
• Communications: uberAgent sends data directly from the endpoint to the Splunk servers’ TCP port or HTTP Event Collector

Pros

• Smallest footprint

Cons

• No optional storage of collected data on disk before sending to Splunk

Alternative: Standalone With Splunk’s Universal Forwarder

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

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

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