All Apps and Add-ons

ta_nmon data collection frequency for different types of data

wyfwa4
Communicator

I currently use the TA_NMON add-on to collect data from various linux hosts. This works ok, but generates lots of data. The problem I have is that I want to have a high frequency for very dynamic data (such as CPU usage) which only generates a few events per collection, while reducing the frequency of fairly static data such as DF_Table DF_Inodes which generate large numbers of events per collection where large numbers of disks are installed. However for disk information, the data is fairly static and we can track the trends by only collecting this data once every 5 or 10 minutes. While for CPU usage, we would like to see every 30 or 60 seconds.

One option I have looked at, is to create two copies of the same app, but with different data collection frequencies, but this is challenging to set-up, due to the use of fixed var folders to store the collected data.

Any suggestions on how to set-up different schedules within TA_NMON?

0 Karma

guilmxm
Influencer

Hello @wyfwa4

Apologise for late replying to your question, but here we go 😉

Different collection schedules per type of metrics:

This is not technically possible due to the fact that the collection is achieved via a unique binary which owns his own collection cycle driven by the interval and the number of snapshots when the binary got started.

When the binary runs with a 60 sec interval, this is being applied for the collection of all metrics.

This works ok, but generates lots of data

This might seem to be lots of data, but in the end the daily volume per host is quite limited, an average raw indexing cost per day / per host is roughly 7-15 MB with a 60 sec interval, which for Splunk remains pretty small.

Restricting the metrics generated

You can deactivate the generation of each type of metrics, which you would achieve via creating your own copy of:

default/nmonparser_config.json

To a local/ version, then you can remove each type of metrics you do not need to generated.

On modern Linux OS, you can for example easily deactivate the DISK* metrics as there are advantageously replaced by the DG* metrics.
The DG* metrics are basically grouping the calculation of all devices per partitions, thus you cannot anymore go at the very low device level but you keep with a very good level of information about the disk statistics

One option I have looked at, is to create two copies of the same app

Yes ! Very smart you think about that, there is actually a script that was created for that purpose 😉

https://nmon-for-splunk.readthedocs.io/en/latest/Userguide.html?highlight=create_agent.py

Using the script will allow to create multiple copies of the TA, which you can then customise and deploy easily.
A use case is for example monitoring a non production environment with a much cheaper interval, say 2 or 5 min where you will use 30 or 60 sec for Production.

This script takes care of creating the tgz archive for you, so you reproduce the same steps for future updates as well.

I hope this replies to your questions, let me know otherwise.

Guilhem

0 Karma
Get Updates on the Splunk Community!

.conf24 | Registration Open!

Hello, hello! I come bearing good news: Registration for .conf24 is now open!   conf is Splunk’s rad annual ...

ICYMI - Check out the latest releases of Splunk Edge Processor

Splunk is pleased to announce the latest enhancements to Splunk Edge Processor.  HEC Receiver authorization ...

Introducing the 2024 SplunkTrust!

Hello, Splunk Community! We are beyond thrilled to announce our newest group of SplunkTrust members!  The ...