Forum Discussion
tarsier_90410
Nimbostratus
Nimbostratusnagios for pool monitors?
Has anyone here tried to use custom HTTP pool monitors with the alias address/port set to pull service status data from the Nagios web interface?
Our thought is that we are using Nagios to monitor many metrics for our systems already, and that rather than rewrite each check in LTM and add load to the systems from being monitored by multiple systems, we could just have Nagios continue to monitor, alert, and log everything, while pointing BIGIP at it.
I have created this monitor and assigned it to a pool, but no luck so far.
interval: 60
timeout: 181
send string: GET /nagios/cgi-bin/extinfo.cgi?type=2&host=SERVER1&service=CPU
receive string: serviceOK
user name:
password: ******
reverse no
transparent no
alias address:
alias port: 80
If anyone has tried this and had a similar error, I greatly appreciate any help. Otherwise my next step is packet inspection to figure out why the checks are failing. (I see the requests in the apache logs, but the pool continues to be marked down.)
The end goal is to have Nagios determine the availability and load of the app, db, ldap, etc; use the Nagios output to drive the pool monitor, and check the pool state from an iRule to decide when to show a "we are experiencing high load" or maintenance page to the web app users.
- Is nagios possibly looking for an HTTP/1.1 request? You may have to add a few things to your send string, along the lines of the following:
GET /nagios/cgi-bin/extinfo.cgi?type=2&host=SERVER1&service=CPU HTTP/1.1\r\nHost: \r\nConnection: Close\r\n
You also might try the SuperHTTP monitor script:
http://devcentral.f5.com/Wiki/default.aspx/AdvDesignConfig/SuperHTTPMonitor.html
It's super flexible and fairly straightforward - the script comments walk though the various options and how to set them.
Ah, also - just remembered. Are you on V10 yet? You might take a look at the inband passive monitor feature that was recently added:
http://devcentral.f5.com/weblogs/amurphy/archive/2009/04/09/5933.aspx
(edited for readability) 
hooleylistCirrostratus
I think jquinby's suggestion to use an external monitor is good. Trying to use a standard HTTP monitor to poll a single, separate device for status of the pool members won't work. This is because you cannot specify the pool member IP address and port in a monitor send string--which is what Nagios is going to expect. With an external monitor, you can get the current pool member IP and port in shell variables and use that in the HTTP request sent to Nagios.
Aaron
tarsier_90410Thank you both for the suggestions. HTTP 1.1 settings were the culprit.
Our Nagios instance takes the host name in the url parameters, so passing in the pool IP is not necessary (we will need to define a different monitor for each application). Checking the web application server will still be performed with an HTTP check directly to the app, but we will check other metrics via Nagios which is already monitoring and alerting for CPU, memory, etc. for other servers that the app depends on (DB, directory services, load on a specific SAN, network outage, etc). We will need to be careful defining what to do when BIGIP cannot contact Nagios.
In a sense, we will use Nagios as the external monitor, but will interface through the LTM's generic HTTP monitor to Nagios' web interface.
We are still on 9.2.5 due to some business constraints, but just purchased a new pair of LTMs which we will run V10. Will look into the external monitors as an option soon.- External monitors will work in 9.x as well - the http monitor script is just a big shell wrapper for easily passing lots (and lots) of things to curl. V10 will get you the inband passive monitors which are designed to...well, passively watch network traffic rather than interacting directly with the service.
