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
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