check_mysql plugin

[tecnalb]

Hello

I am testing the mysql plugin, so I setup an ssh port redirect (ssh -L 5999:localhost:3306) to a cpanel server with MySQL.

From the nagios server, when I run my ./check_mysql, if I use the --mode (which is added when using the wizard) I keep getting an "unrecognized option --mode". If I run without, I get a whole slew of metrics back.

So how do I fix the wizard to give me what I want to see

--- so I got past this one.... and XI is displaying information...

but now, how I can I tunnel these command via XI? Instead of manually opening up a connection between servers?

[lmiltchev]

From the nagios server, when I run my ./check_mysql, if I use the --mode (which is added when using the wizard) I keep getting an "unrecognized option --mode". If I run without, I get a whole slew of metrics back.

Can you show us both commands (the one that works, and the one that fails) run from the CLI, along with the output?

[mp4783]

Firstly, are you sure you need to run the plugin on the MySQL server itself? If memory serves, you can run it from the Nagios XI server itself because the MySQL CLI client is installed by default.

If you need encryption, then you do have to so through the hassle of setting up MySQL to support it, generate a client certificate, etc. I don't know off hand if it provides SSL support.

You might also consider the check_mysql_health plugin, which is what we use. I think it provides SSL support.

Finally, you can simply run the check_mysql plugin on the MySQL server itself and execute it via NRPE.

[lmiltchev]

Any updates, tecnalb?

[tecnalb]

Sorry for the late reply....

I am not running on the server itself... I am running from the Nagios server BUT, thru an ssh tunnel. MySQL was not part of the nrpe package, and so I was looking to just run from the XI server.

So What I have done currently is this:

I have a key established from my nagios server to the MySQL server. Then I

screen ssh -p 22022 -L 5999:localhost:3306 XX.XX.XX.XX and this builds my tunnel. I use CTRL A-D to disconnect from the screen session, but leave it active.

My command in XI is

check_xi_mysql_health!--hostname=127.0.0.1 --port=5999 --username=nagios --password="blahblahblah" --database=information_schema --mode connection-time --warning 1 --critical 5

And I get a valid connection.


What I am trying to do (and this may not be possible) is not have to build the tunnel above manually, but instead, have it establish for EACH MySQL check.

Does that clear up what I am trying to do?



As for the --mode command.... if I leave the --mode switch in there, I get this:

./check_mysql: unrecognized option '--mode'
Usage:
check_mysql [-d database] [-H host] [-P port] [-s socket]
[-u user] [-p password] [-S] [-l] [-a cert] [-k key]
[-C ca-cert] [-D ca-dir] [-L ciphers] [-f optfile] [-g group]

[root@nagios libexec]# ./check_mysql --hostname=127.0.0.1 --port=5999 --username=nagios --password="blahblahblah" --database=information_schema --mode connection-time --warning
1 --critical 5

[Box293]

I think you'll probably want to create a bash wrapper script that:

Code: Select all

Establishes the tunnel
Executes the plugin
Tears down the tunnel
Returns plugin output and exit code back to Nagios

NOTE: all of your command line testing should be done as the user "nagios" NOT the user "root".

[mp4783]

You could modify the plugin to support native MySQL SSL encryption.

You could also modify it to drive the MySQL command line ('mysql ...') via SSH as suggested above. This would be similar to some of the current commands that support SSH options like "-i" for the private key.

[jdalrymple]

Is there a reason you couldn't just use check_by_ssh and install the plugin on the remote host?

FWIW, if you have a *relatively* similar system you probably don't need to go through the hassle of compiling all the plugins. I copied the binary from one machine to another totally non-nagiosed machine and it ran just fine.

[mp4783]

I agree that MySQL is pretty simple to do this way. I would warn however that Oracle and MS SQL Server are not. SQL Server in particular has a ton of dependencies, although if you were running it directly on a Windows server (which I haven't done) it's probably easier.

[tmcdonald]

tecnalb, let us know what you come up with.