single "data template" multiple "graph templa

[mikee]

hi all...

I've been experimenting some with cacti and have gotten it to do some cool tricks. I got concerned that my script/probe was beating on the target a little more than I wanted, and so I was hoping to make my queries as "lean" as possible.

Rather than collecting data (through a private interface) multiple times (once for each graph) , I created a single "data template" that collects all the information in 1 shot.

The idea is that the various graphs I create afterwards should share the same RRD datasource/file, but just pull the different/appropriate pieces of data from it (all the data is in there already, so just pull the columns needed for that particular graphs). That way the graphs are all perfectly synchronized, and there is only a single data-poll operation for all the graphs...

--

Thats the plan, but reality shows that each graph seems to STILL create its own data-store, and calls the data collection script individually...

any thoughts or guidance is much appreciated.

thanks,

-- MikeE

[Linegod]

- Create with the graph template only once.
- Duplicate the graph from Graph Management
- Change the graph template on the copy
- Rinse, wash, repeat.

[mikee]

that appears to work... yet doesn't appear to be particularly scalable/manageable.. (it goes against the cacti templating concepts)

The problem is that if one needs to add a new device to monitor, you need to do the copy/clone/change game there too... (all manual, and prone to mistakes)

Is this a case where we're really dealing with a cacti RFE of some variety? (some new abstraction layer that allows multiple graph-templates to use a pre-existing data-store?)

It appears to be a bit of an edge case, but I would think that its more common than one might at 1st suspect. (essentially bulk-polling all the sensor data from a device once/into a single data-store, and then creating multiple graphs to display parts of that data. use bulk-polling instead of individual polls has many not just around efficiency, but also in terms of having all the data time-synced)

If other people are interested in this, perhaps we can document the requirement a bit better & see if we can get it onto the roadmap?

Kindly comment against this thread, I'll keep checking it to see if others are in the same boat.

thanks -- MikeE

[gandalf]

It's a known feature request (though I do not know if it's in the bug tracker). But no solution at the horizon, yet
Reinhard

[kuma3]

mikee,

I have the same concern when I first start using cacti. So our workaround for this is instead of cacti issuing the heavy snmp or nrpe checks directly, we have cronjobs that pulls the data and save the metric in plain text. Then data input method is just a call to cat the file.


mark

[terrymcg]

It appears to be a bit of an edge case, but I would think that its more common than one might at 1st suspect. (essentially bulk-polling all the sensor data from a device once/into a single data-store, and then creating multiple graphs to display parts of that data. use bulk-polling instead of individual polls has many not just around efficiency, but also in terms of having all the data time-synced)

If other people are interested in this, perhaps we can document the requirement a bit better & see if we can get it onto the roadmap?

Yes please!

I don't think it's that edgy... The filesystem stats supplied by Network Appliance filers contains percentage data, kb data, and counters. In a perfect world, one poll would gather all the data for each filesystem and plonk it into a single rrd, ready for use in multiple graphs ("% Used", "KB Used", etc.).

There's other stuff too - lmsensors data comes to mind, all those volts and temps...

I could get remstats to gather the data and feed it into Cacti, but it would be very nice to have a 'cacti-centric' solution (that didn't involve multiple polls/rrd files).

Cheers,
--
Terry McG

[YoMarK]

What would help a lot, is a "change data source, and delete old data source for graph" button.
RRDClean should do the rest.

I'm using a lot of graphs which use the same data source and script, but they create multiple data sources(with the same data).