The Guru College
Google Apps Nagios Check
A while ago, I wrote a Nagios plugin that checks the Google Apps Status Dashboard for problems, and reports WARNING level alerts when things happen. (I didn’t want to flag these issues as CRITICAL, as there’s nothing our on-call staff can do to fix the problems.) It would be best to attach the service definition to a hostless object – that is, a Nagios host object with the IP set to 127.0.0.1. This way, you don’t have to worry about reachability logic.
The script itself is written in perl, and requires the module JSON::PP. It also makes a hard coded system() call for ‘curl’ to pull the JSON data object from Google’s servers. (At some point I’ll move that to LWP::Simple or something similar, but at the moment it is what it is.)
Basic usage information:
`A while ago, I wrote a Nagios plugin that checks the Google Apps Status Dashboard for problems, and reports WARNING level alerts when things happen. (I didn’t want to flag these issues as CRITICAL, as there’s nothing our on-call staff can do to fix the problems.) It would be best to attach the service definition to a hostless object – that is, a Nagios host object with the IP set to 127.0.0.1. This way, you don’t have to worry about reachability logic.
The script itself is written in perl, and requires the module JSON::PP. It also makes a hard coded system() call for ‘curl’ to pull the JSON data object from Google’s servers. (At some point I’ll move that to LWP::Simple or something similar, but at the moment it is what it is.)
Basic usage information:
`
You will get the same thing if you call the script with a misspelled or nonexistent service name. Otherwise, you’ll see the status of the app in question:
``A while ago, I wrote a Nagios plugin that checks the Google Apps Status Dashboard for problems, and reports WARNING level alerts when things happen. (I didn’t want to flag these issues as CRITICAL, as there’s nothing our on-call staff can do to fix the problems.) It would be best to attach the service definition to a hostless object – that is, a Nagios host object with the IP set to 127.0.0.1. This way, you don’t have to worry about reachability logic.
The script itself is written in perl, and requires the module JSON::PP. It also makes a hard coded system() call for ‘curl’ to pull the JSON data object from Google’s servers. (At some point I’ll move that to LWP::Simple or something similar, but at the moment it is what it is.)
Basic usage information:
`A while ago, I wrote a Nagios plugin that checks the Google Apps Status Dashboard for problems, and reports WARNING level alerts when things happen. (I didn’t want to flag these issues as CRITICAL, as there’s nothing our on-call staff can do to fix the problems.) It would be best to attach the service definition to a hostless object – that is, a Nagios host object with the IP set to 127.0.0.1. This way, you don’t have to worry about reachability logic.
The script itself is written in perl, and requires the module JSON::PP. It also makes a hard coded system() call for ‘curl’ to pull the JSON data object from Google’s servers. (At some point I’ll move that to LWP::Simple or something similar, but at the moment it is what it is.)
Basic usage information:
`
You will get the same thing if you call the script with a misspelled or nonexistent service name. Otherwise, you’ll see the status of the app in question:
``
I hope to have the paperwork done in the next week or so.