check_local_mrtgtraf bandwidth question

[Pikmin]

From the Nagios Documentation (http://nagios.sourceforge.net/docs/3_0/ ... uters.html)

Monitoring Bandwidth / Traffic Rate

If you're monitoring bandwidth usage on your switches or routers using MRTG, you can have Nagios alert you when traffic rates exceed thresholds you specify. The check_mrtgtraf plugin (which is included in the Nagios plugins distribution) allows you to do this.

You'll need to let the check_mrtgtraf plugin know what log file the MRTG data is being stored in, along with thresholds, etc. In my example, I'm monitoring one of the ports on a Linksys switch. The MRTG log file is stored in /var/lib/mrtg/192.168.1.253_1.log. Here's the service definition I use to monitor the bandwidth data that's stored in the log file...

define service{
use generic-service ; Inherit values from a template
host_name linksys-srw224p
service_description Port 1 Bandwidth Usage
check_command check_local_mrtgtraf!/var/lib/mrtg/192.168.1.253_1.log!AVG!1000000,2000000!5000000,5000000!10
}

In the example above, the "/var/lib/mrtg/192.168.1.253_1.log" option that gets passed to the check_local_mrtgtraf command tells the plugin which MRTG log file to read from. The "AVG" option tells it that it should use average bandwidth statistics. The "1000000,2000000" options are the warning thresholds (in bytes) for incoming traffic rates. The "5000000,5000000" are critical thresholds (in bytes) for outgoing traffic rates. The "10" option causes the plugin to return a CRITICAL state if the MRTG log file is older than 10 minutes (it should be updated every 5 minutes).

Save the file.

I am having troubles understanding this part:
The "1000000,2000000" options are the warning thresholds (in bytes) for incoming traffic rates. The "5000000,5000000" are critical thresholds (in bytes) for outgoing traffic rates.

10 0000, 20 00000 WARNING for incoming traffic?
50 0000, 50 00000 CRITICAL for outgoing traffic?

The actual help file from check_mtrgtraf
Usage check_mrtgtraf -F <log_file> -a <AVG | MAX> -w <warning_pair>
-c <critical_pair> [-e expire_minutes]

Options:
-h, --help
Print detailed help screen
-V, --version
Print version information
-F, --filename=STRING
File to read log from
-e, --expires=INTEGER
Minutes after which log expires
-a, --aggregation=(AVG|MAX)
Test average or maximum
-w, --warning
Warning threshold pair <incoming>,<outgoing>
-c, --critical
Critical threshold pair <incoming>,<outgoing>

So shouldn't it actually be !1000000(IN WARNING),2000000(OUT WARNING)!5000000(IN CRITICAL),5000000(OUT CRITICAL)!

Thanks

Another question, if I have a gigabit interface

MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 1000Mb/s

Could I use this to get a Warning for 80% and CRITICAL for 100% or is my math wrong as usual
check_local_mrtgtraf!/var/www/mrtg/192.168.x.x_1.log!AVG!80000000,80000000!100000000,100000000!10

[jdalrymple]

Hi Pikmin,

I understand what you're saying and you are correct, the documentation and the usage info are in conflict. I suspect that the usage info is the correct representation. I will verify that and we will update the documentation or usage (whichever the case may be) accordingly.

Regarding your second question, I think you're missing one zero in each threshold (warning at 8%, critical at 10%) for gigabit. Otherwise if our assumption that the usage is correct that would be the proper check_command to use.

[jdalrymple]

I stand corrected Pikmin, the rates are in bytes, so for gigabit or 125 GB your 80% threshold should be 100MB or 100000000 and your 100% threshold would be 125000000. That's how my math works out.

[jdalrymple]

You were right Pikmin, we have updated the documentation you referred to. Thank you for pointing out the error. Does this answer all your questions?

Thanks again.

[Pikmin]

Thanks for your reply and thank you for the right figures

[tmcdonald]

I'll be closing this thread now, but feel free to open another if you need anything in the future!