Hi,
I'd appreciate someone putting me on the right track here. I'm having a hard time understanding certain aspects of the way that Cacti processes the results from the various SNMP queries before putting it into a graph. As a result some of the graphs I am creating do not work as expected. I've got a few questions really;
1) I understand that rrdtool performs a calculation along the lines of ((current value - previous value) / 300) to calculate the 'change per second'. However, this strikes me as only applicable to COUNTER type values, is that the case? If so, is any similar manipulation of the results from GAUGE queries done at all?
The above question comes about as one of the graphs I am creating is to monitor Current Disk Queue values from a Windows 2000 server. The results returned by the SNMP query are as expected - e.g usually 0, sometimes up to around 2 or 3. I've setup these data sources as GAUGE sources - which leads back to my previous question, is the processing described performed on GAUGE results - but graph's are still showing results of sub-zero values (as denoted with the m character). I can't see why it would do this. I'm getting the same results for IIS connections graphs which again should generally produce a result of 0 with occasional spikes.
Other data / graph templates configured similarly seem to be okay - eg. CPU Usage which is a GAUGE value and is displayed as I'd expect.
I've most likely misunderstood something - can anyone help?
Thanks
Lee
How data is processed
Moderators: Developers, Moderators
- gandalf
- Developer
- Posts: 22383
- Joined: Thu Dec 02, 2004 2:46 am
- Location: Muenster, Germany
- Contact:
Re: How data is processed
This depends on the method used to gather data. You may have a look at the script to see, what OIDs are used and poll them via snmpwalk manually. Slight misalignment may be due to rrdtools time correction that comes in when polling cycles do not _exactly_ match 300 sec.lee_evans wrote:1) I understand that rrdtool performs a calculation along the lines of ((current value - previous value) / 300) to calculate the 'change per second'. However, this strikes me as only applicable to COUNTER type values, is that the case? If so, is any similar manipulation of the results from GAUGE queries done at all?COUNTER works as descibed. No manipulation done for GAUGEs, but be sure that there isn't any CDEF applied to the Graph; that would make some calculations on its own.
The above question comes about as one of the graphs I am creating is to monitor Current Disk Queue values from a Windows 2000 server. The results returned by the SNMP query are as expected - e.g usually 0, sometimes up to around 2 or 3. I've setup these data sources as GAUGE sources - which leads back to my previous question, is the processing described performed on GAUGE results - but graph's are still showing results of sub-zero values (as denoted with the m character). I can't see why it would do this. I'm getting the same results for IIS connections graphs which again should generally produce a result of 0 with occasional spikes.
Reinhard
Thanks for your reply. I've been monitoring the same OIDs 'manually' using snmpwalk for most of the morning, to see if I can spot any problems from that angle. However, all the results I've received have been as expected. The following shows a brief example in the case of the DiskQueue OID:
INFORMANT-STD::lDiskAvgDiskQueueLength."C:" = Gauge32: 0
INFORMANT-STD::lDiskAvgDiskQueueLength."C:" = Gauge32: 2
INFORMANT-STD::lDiskAvgDiskQueueLength."C:" = Gauge32: 2
INFORMANT-STD::lDiskAvgDiskQueueLength."C:" = Gauge32: 1
INFORMANT-STD::lDiskAvgDiskQueueLength."C:" = Gauge32: 0
INFORMANT-STD::lDiskAvgDiskQueueLength."C:" = Gauge32: 0
The exact same results can be seen if in the cacti logs - so it's getting the same numbers, but it or rrdtool is obviously doing something to them along the way
thanks again
lee
INFORMANT-STD::lDiskAvgDiskQueueLength."C:" = Gauge32: 0
INFORMANT-STD::lDiskAvgDiskQueueLength."C:" = Gauge32: 2
INFORMANT-STD::lDiskAvgDiskQueueLength."C:" = Gauge32: 2
INFORMANT-STD::lDiskAvgDiskQueueLength."C:" = Gauge32: 1
INFORMANT-STD::lDiskAvgDiskQueueLength."C:" = Gauge32: 0
INFORMANT-STD::lDiskAvgDiskQueueLength."C:" = Gauge32: 0
The exact same results can be seen if in the cacti logs - so it's getting the same numbers, but it or rrdtool is obviously doing something to them along the way
thanks again
lee
-
- Posts: 49
- Joined: Tue Jan 18, 2005 7:50 am
It's to do with the poller interval not always being *exactly* 300 seconds.
One of the other departments we had here have this problem, they wanted to draw the graphs as normal but they also wrote something to retrieve values from the rrd file and display them (don't ask why ) - they didn't like the fact that the values were coming out as, for example, 3.045 etc .
It's to do with the way rrdtool averages out multiple updates within the 300 timestep period, or something along those lines.
We fixed it by editing their installation of cacti, in the poller.php we found where the timestamp value was generated that updated the rrd file and forced it to be the value of the last 5 minute period entry.
I can't remember where this was though, and do not have access to their system to check this ... but the calculation you'd need would be something like
$timestamp = $timestamp - ($timestamp % 300);
This should stop you from getting odd numbers for specific 5 minute intervals... But I wouldn't recommend doing this unless you *really* have to.
One of the other departments we had here have this problem, they wanted to draw the graphs as normal but they also wrote something to retrieve values from the rrd file and display them (don't ask why ) - they didn't like the fact that the values were coming out as, for example, 3.045 etc .
It's to do with the way rrdtool averages out multiple updates within the 300 timestep period, or something along those lines.
We fixed it by editing their installation of cacti, in the poller.php we found where the timestamp value was generated that updated the rrd file and forced it to be the value of the last 5 minute period entry.
I can't remember where this was though, and do not have access to their system to check this ... but the calculation you'd need would be something like
$timestamp = $timestamp - ($timestamp % 300);
This should stop you from getting odd numbers for specific 5 minute intervals... But I wouldn't recommend doing this unless you *really* have to.
Who is online
Users browsing this forum: manel and 1 guest