xymon rrd value different from reported value
Hi all,
I'm having a weird problem for which I can't seem to hunt down a cause/solution. I have a custom script that's using SPLITNCV to store data, but the data stored in the rrd files are different from those reported by the script. Below you'll notice that at 10:48:34 customer_info is reported at 1, but in the rrd file it's showing 10:50:00 and 8.8008800880e-04. Any ideas?
CLIENT VERSION: 4.3.5 SERVER VERSION: 4.3.5
CLIENT LAUNCH CONFIG: /home/xymon/client/etc/clientlaunch.cfg
The ad log analyzer
[log_ad] ENVFILE $XYMONCLIENTHOME/etc/xymonclient.cfg CMD $XYMONCLIENTHOME/ext/log_ad.sh LOGFILE $XYMONCLIENTHOME/logs/log_ad.log INTERVAL 5m
CLEINT SCRIPT LOG: /home/xymon/client/logs/log_ad.log ( This is an output of the MSG that's being sent to xymon )
Thu Jan 12 10:48:34 EST 2012 customer_info : 1 processing_error : 0
Thu Jan 12 10:53:36 EST 2012 customer_info : 0 processing_error : 0
Thu Jan 12 10:58:38 EST 2012 customer_info : 0 processing_error : 0
Thu Jan 12 11:03:40 EST 2012 customer_info : 0 processing_error : 0
Thu Jan 12 11:08:42 EST 2012 customer_info : 2 processing_error : 0
SERVER RRD FILE: /home/xymon/data/rrd/HOST/log_ad,customer_info.rrd
<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE rrd SYSTEM "http://oss.oetiker.ch/rrdtool/rrdtool.dtd"> <!-- Round Robin Database Dump --><rrd> <version> 0003 </version> <step> 300 </step> <!-- Seconds --> <lastupdate> 1326384533 </lastupdate> <!-- 2012-01-12 11:08:53 EST -->
<ds>
<name> lambda </name>
<type> DERIVE </type>
<minimal_heartbeat> 600 </minimal_heartbeat>
<min> NaN </min>
<max> NaN </max>
<!-- PDP Status -->
<last_ds> 0 </last_ds>
<value> 0.0000000000e+00 </value>
<unknown_sec> 0 </unknown_sec>
</ds><!-- Round Robin Archives --> <rra> <cf> AVERAGE </cf> <pdp_per_row> 1 </pdp_per_row> <!-- 300 seconds -->
<params>
<xff> 5.0000000000e-01 </xff>
</params>
<cdp_prep>
<ds>
<primary_value> 0.0000000000e+00 </primary_value>
<secondary_value> -2.2002200220e-05 </secondary_value>
<value> NaN </value>
<unknown_datapoints> 0 </unknown_datapoints>
</ds>
</cdp_prep>
<database>
<!-- 2012-01-10 11:10:00 EST / 1326211800 --> <row><v> NaN </v></row>
<!-- 2012-01-10 11:15:00 EST / 1326212100 --> <row><v> NaN </v></row>.... <!-- 2012-01-12 10:45:00 EST / 1326383100 --> <row><v> 0.0000000000e+00 </v></row> <!-- 2012-01-12 10:50:00 EST / 1326383400 --> <row><v> 8.8008800880e-04 </v></row> <!-- 2012-01-12 10:55:00 EST / 1326383700 --> <row><v> 1.6061606161e-03 </v></row> <!-- 2012-01-12 11:00:00 EST / 1326384000 --> <row><v> -2.4862486249e-03 </v></row> <!-- 2012-01-12 11:05:00 EST / 1326384300 --> <row><v> 0.0000000000e+00 </v></row> </database>
SERVER CONFIG: /home/xymon/server/etc/xymonserver.cfg
SPLITNCV_log_ad="customerinfo:GAUGE,processingerror:GAUGE"
Thanks,
Jeff Bender Lead Technical Support Engineer Mobile: (703) 615-5981
mPortal, Inc. [cid:image001.jpg at 01CCD11A.D7F2CBF0] <http://www.mportal.com/> [cid:image002.png at 01CCD11A.D7F2CBF0] <http://www.facebook.com/mPortalInc> [cid:image003.jpg at 01CCD11A.D7F2CBF0] <http://twitter.com/mportal>
On 12-01-2012 17:36, Jeff Bender wrote:
I’m having a weird problem for which I can’t seem to hunt down a cause/solution. I have a custom script that’s using SPLITNCV to store data, but the data stored in the rrd files are different from those reported by the script. Below you’ll notice that at 10:48:34 customer_info is reported at 1, but in the rrd file it’s showing 10:50:00 and 8.8008800880e-04. Any ideas?
That's how RRD works. Unless you fill in the data at *exactly* 300 second intervals, RRDtool will interpolate the data and calculate what it "should" have been, if you had been doing the update at the right time.
See the RRDtool documents for more details, e.g. the "Data resampling" section of the RRD tutorial at http://oss.oetiker.ch/rrdtool/tut/rrdtutorial.en.html
Regards, Henrik
Henrik Størner <henrik at ...> writes:
On 12-01-2012 17:36, Jeff Bender wrote:
I’m having a weird problem for which I can’t seem to hunt down a cause/solution. I have a custom script that’s using SPLITNCV to store data, but the data stored in the rrd files are different from those reported by the script. Below you’ll notice that at 10:48:34 customer_info is reported at 1, but in the rrd file it’s showing 10:50:00 and 8.8008800880e-04. Any ideas?
That's how RRD works. Unless you fill in the data at *exactly* 300 second intervals, RRDtool will interpolate the data and calculate what it "should" have been, if you had been doing the update at the right time.
See the RRDtool documents for more details, e.g. the "Data resampling" section of the RRD tutorial at http://oss.oetiker.ch/rrdtool/tut/rrdtutorial.en.html
Regards, Henrik
Henrik,
This make a little more sense now. I've only started using xymon in the past month or two. Do you have any suggestions on how to disable this feature or some kind of way to make it so that the data reported is the data stored? Since I'm new to this, I don't think I even know how to properly ask what to do :)
You may wonder why? It's because this check is looking for 'ERROR' in a log and reporting the count for the past 5 minutes. Since there are only 1 or 2 every couple of checks, it's making my graph fluctuate between positive and negative at the 0.* level.
Graph example: http://www.benderbytes.com/xymon_graph.jpg
Thanks,
Jeff
All,
I've figured out what the issue was. It appears that NCV and SPLITNCV behave differently. For example:
Data is delivered like this ( column = log_test ) :
Name_1 : 0 Name_2 : 0 Name_3 : 0
For NCV, you would make the following entry and everything would work perfectly:
NCV_log_test="Name1:GAUGE,Name2:GAUGE,Name3:GAUGE"
For SPLITNCV, you would assume it's the same, but it's not. When xymon creates the rrd file, it's creating it like this:
log_test,Name_1.rrd as opposed to the expected (log_test,Name1)
Since the file is being created with the '_', it seems that instead of picking up 'GAUGE' as the type, it's using the default 'DERIVE'. I would call this a bug, but I'll let someone with more experience open it if that's the case.
If you're having this problem, just skip using any special character since they will probably cause your more problems than they're worth.
Thanks,
Jeff
participants (2)
-
henrik＠hswn.dk
-
JBender＠mportal.com