uberAgent

Data Distribution and Separation (Routing to Multiple Backends)

July 19, 2024

Contributed by:

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

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

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

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.

The official version of this content is in English. Some of the Cloud Software Group documentation content is machine translated for your convenience only. Cloud Software Group has no control over machine-translated content, which may contain errors, inaccuracies or unsuitable language. No warranty of any kind, either expressed or implied, is made as to the accuracy, reliability, suitability, or correctness of any translations made from the English original into any other language, or that your Cloud Software Group product or service conforms to any machine translated content, and any warranty provided under the applicable end user license agreement or terms of service, or any other agreement with Cloud Software Group, that the product or service conforms with any documentation shall not apply to the extent that such documentation has been machine translated. Cloud Software Group will not be held responsible for any damage or issues that may arise from using machine-translated content.

Was this helpful

Data Distribution and Separation (Routing to Multiple Backends)

July 19, 2024

Contributed by:

July 19, 2024

Contributed by:

Data Distribution and Separation (Routing to Multiple Backends)

Concept

Implementation

Configuration Example

Result

In this article