Skip to main content

vast limits GmbH and uberAgent are now part of Citrix, a business unit of Cloud Software Group. Learn more at Citrix.com.


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

Data Distribution and Separation (Routing to Multiple Backends)

In some scenarios, it is necessary to distribute the data collected by uberAgent to different backend systems. Do you need to build an even more complex backend infrastructure for that? No, this can be achieved in an easy and straightforward way just by modifying the agent’s configuration.

Concept

uberAgent supports multiple data receivers per endpoint by default. Every timer and metric can be bound to one or multiple receivers. That architectural option gives you amazing flexibility out of the box.

The index name can be configured per receiver stanza as well. This makes it possible to configure the data retention per uberAgent metric based on the resulting index in the backend infrastructure.

Implementation

You can make use of this configuration as follows:

  • Create a second (, third, …) [Receiver] stanza.
  • Bind all [Timer] stanzas to the correct receiver based on your requirements.
  • Restart the uberAgent service.

Configuration Example

In this example, we are separating uberAgent’s inventory data by routing it to an additional Splunk environment.

Configure two [Receiver] stanzas like this:

[Receiver]
Name     = uberAgent
Type     = Splunk
Protocol = TCP
Index    = uberAgent
Servers  = Server_A:19500

[Receiver]
Name     = uberAgent_Inventory
Type     = Splunk
Protocol = TCP
Index    = uberAgent_Inventory
Servers  = Server_B:19500

Bind all [Timer] stanzas and the [OnDemand] stanza to the default receiver uberAgent like this:

############################################
# On-demand metrics
############################################
[OnDemand]
Receivers      = uberAgent
UA metric      = LogonDetail
UA metric      = LogonProcesses
UA metric      = BootDetail
UA metric      = ShutdownDetail
UA metric      = StandbyDetail
UA metric      = ProcessStartup
UA metric      = OutlookPerformanceEvents
UA metric      = ApplicationErrors
UA metric      = ApplicationUIDelay
############################################
# Timer 1
############################################
[Timer]
Receivers      = uberAgent
Name           = Default timer
Comment        = Metrics are placed here unless there is a reason to have them run at different frequencies or to isolate them
Interval       = 30000
UA metric      = ProcessDetailFull
UA metric      = ApplicationUsage
UA metric      = SessionCount
UA metric      = SessionDetail
UA metric      = SystemPerformanceSummary
UA metric      = SMBClientSharePerformance 

Configure only the inventory [Timer] stanza (default: Timer 6) to use the uberAgent_Inventory receiver:

############################################
# Timer 6
############################################
[Timer]
Receivers         = uberAgent_Inventory
Name              = Inventory
Comment           = Perform an inventory at a very low frequency
Interval          = 86400000
Start delay       = 6000
Persist interval  = true
Thread priority   = background
UA metric         = ApplicationInventory
UA metric         = SoftwareUpdateInventory
UA metric         = MachineInventory
UA metric         = CitrixADCInventory

Result

As described in this example, you have the ability to granularly route uberAgent’s data on a per-metric level to different backend systems. That can be very handy to separate and distribute a subset of data to a specific group or to implement a per-metric data retention policy.

Comments

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