Skip to main content

This documentation does not apply to the most recent version of uberAgent. Click here for the latest version.

Architecture Options

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


  • Smallest footprint


  • 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


  • 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


  • Larger footprint than the recommended architecture


Your email address will not be published. Required fields are marked *