Didn't realize this until recently. One of our sites has a 5Mbps circuit, and our threshold there is set to go critical at 4M utilization. When we didn't get an alert after the circuit hit 4.9 I did some digging at it appears that it's because, to Nagios, 4.9M was still not above 4? I would think that even if it did ignore the decimal that we would get an alert after it hits 4M, but that doesn't appear to be the case. See below example (I adjusted it down to 3 since that's what the current utilization at this site is):
COMMAND: /usr/local/nagios/libexec/check_rrdtraf -f /var/lib/mrtg/xx.xx.xx.xx_2.rrd -w 3,3 -c 5,5 -l M
OUTPUT: OK - Current BW in: 3.88Mbps Out: 1.21Mbps|in=3.885375Mb/s;3;5 out=1.215272Mb/s;3;5
Shouldn't that be in Warning state? I tried this on 5 other routers as well and it's the same with all of them. It looks like it's rounding UP or something for these when it should be rounding DOWN, if anything. If the decimal values cannot be read (not a huge deal) then 4.9 should be viewed as 4 and should become a warning state.
I would completely agree that this should be a warning state! Could you do me two favors? 1) Create an issue on github (https://github.com/nagios-plugins/nagios-plugins/issues) and 2) either post the rrd here or email me a copy if it is too large. I am going to need something to test against, and it's likely going to be a ton easier to jump into an rrd with a known datapoint to test against.
Nagios-Plugins maintainer exclusively, unless you have other C language bugs with open-source nagios projects, then I am happy to help! Please pm or use other communication to alert me to issues as I no longer track the forum.
Pretty small RRD so that's attached. I will head over to guthub now and create an issue there. Thanks for checking on this, Spenser, it definitely seemed off to me that it was reporting that way. Just let me know if you need anything else!
You do not have the required permissions to view the files attached to this post.
Thanks for the rrd, I'll take a look into this saturday or sunday as time permits, and hopefully have a patch monday or tuesday for you!
Nagios-Plugins maintainer exclusively, unless you have other C language bugs with open-source nagios projects, then I am happy to help! Please pm or use other communication to alert me to issues as I no longer track the forum.
Any progress on this Spenser? I know you're busy, so no worries, just figured I'd pop in and see if you'd gotten anything on this yet. Also, I just realized that when I created a github account to make that bug report it somehow auto assigned my avatar to the greatest avatar I've ever used, haven't seen that one in awhile lol.
HA, yes I have been looking at it, and have a possible patch. Not quite ready for testing though. Hoping by the end of the week I'll have an updated revision for you.
Nagios-Plugins maintainer exclusively, unless you have other C language bugs with open-source nagios projects, then I am happy to help! Please pm or use other communication to alert me to issues as I no longer track the forum.
Well now I feel a bit silly. I just realized you meant rrdtraff not mrtgtraff(which needs it's own bit of work). rrdtraff is not a nagios-plugin, but is something we ship with XI if I recall correctly. I'll take a peek in the morning on what this is written in and what I\we can do.
Edit: Found the issue and working on a solution today!
Nagios-Plugins maintainer exclusively, unless you have other C language bugs with open-source nagios projects, then I am happy to help! Please pm or use other communication to alert me to issues as I no longer track the forum.
Sorry if I'm late on this one but this makes perfect sense. check_rrdtraf is a shell script and sh doesn't do floating point math. Is it possible to use the -l B switch?
-Labels and units for warning and critical values are determined by the -l argument (if specified):
B=bps; K=Kbps; M=Mbps; G=Gbps
-If the -l switch is specified, input values are assumed to be in the same units as specified in the -l switch
-If the -l switch is not specified, output values are scaled appropriately, and input values are assumed to be in Kbps