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.
- 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
- Smallest footprint
- 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.
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.
- 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)
- 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