Forum Discussion

Gill_32697's avatar
Gill_32697
Icon for Nimbostratus rankNimbostratus
Mar 30, 2015

Get HTTP Monitor

I needing to create a health check monitor against these fqdn page on these two servers, it should just return and ok or 200. Not sure how to do it but im guessing I would create a Http health monitor and add this to the the Send String? Also is there a way to not specify the server and just do a health monitor check at the pool for both pool members and not by node. Below is the string im checking for on each server. ! !- So would this be correct?

 

GET ok

 

7 Replies

  • Just to clarify, are you saying that the web server is expecting a specific host name (i.e. one server looking for p-wfecat1-v and the other p-wfecat2-v) or does the web server not care what to host name is?

    If your web servers don't care about the host name coming in, your send and receive strings would be pretty simple.

    SEND: GET /SpatialKeyFramework/skmanage?action=healthCheck (This doesn't specify the HTTP version, and unless you're using HTTP 1.1, you dont' have to specify a Host header. If you're using HTTP 1.1 the Host header is required, though if you're web server doesn't care what it is, you can put whatever you want in it)

    RECEIVE: ok (which should mark it up if the page contains "ok" or I think also on a 200 response code, because the status message would be "OK")

    Assigned at the pool level, it will send that string to all the members, which is agnostic of host name.

    SOL13397: HTTP Monitors

    Hope this helps.

  • The servers dont care, its just two pool members, I agree it should be simple. Currently I have it set exactly as you outline, assigned at the pool level. But the pool members continue to be Marked Down Monitor.

     

    • Michael_Jenkins's avatar
      Michael_Jenkins
      Icon for Cirrostratus rankCirrostratus
      if you do a curl to the server (curl "http://servername/URI" -v), what kind of response to you get back?
  • Pretty much answered by Michael. Just to elaborate, you may also have to include a line-break symbol at the end of your send string. This requirement varies across web servers - for some web-servers, it's not needed while for others a line-break (or even 2 is required). Test it for yourself, and if there are issues, try adding more line-breaks (or remove them). Continue testing with cURL or WGET until the pool members are marked Available.

    Give it a try:

     

    ltm monitor http /Common/monitor_spatial_http {
        defaults-from /Common/http
        destination *:*
        interval 60
        ip-dscp 0
        recv OK
        send "GET /SpatialKeyFramework/skmanage?action=healthCheck\\r\\n"
        time-until-up 0
        timeout 20
    }
    

     

  • I did a curl to the IP..below are the results.. !> [root@VE-LAB-LTM:ModuleNotLicensed:Active:Standalone] config curl "http://10.111.222.121/SpatialKeyFramework/skmanage?action=healthCheck" -v * About to connect() to 10.111.222.121 port 80 (0) * Trying 10.111.222.121... connected * Connected to 10.111.222.121 (10.111.222.121) port 80 (0)

     

    GET /SpatialKeyFramework/skmanage?action=healthCheck HTTP/1.1 User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8y zlib/1.2.3 libidn/0.6.5 Host: 10.111.222.121 Accept: /

     

    < HTTP/1.1 200 OK < Date: Mon, 30 Mar 2015 15:49:23 GMT < Server: Apache/2.4 < X-Distributed-by: AHC < Content-Type: text/xml;charset=UTF-8 < Accept-Ranges: none < Transfer-Encoding: chunked < * Connection 0 to host 10.111.222.121 left intact * Closing connection 0

     

    • Michael_Jenkins's avatar
      Michael_Jenkins
      Icon for Cirrostratus rankCirrostratus
      So if you try something like "GET /SpatialKeyFramework/skmanage?action=healthCheck HTTP/1.1\r\nHost: example.com\r\nConnection: Close\r\n\r\n" and the receive "OK" (or you could try "200"), does that make any difference
  • If that doesn't work, the best way to figure out what you need is to enable monitor logging and watch the log for the RECV string.

    There's SOL12531 that talks about monitors a little bit, and then this article that adds a little extra information.

    • Open the pool that is having the problem (let's call it MY_POOL)
    • Make sure the monitor is active on the pool (let's call it MY_MONITOR)
    • On the Members tab in the pool settings, click on one of the members (let's call it 10.0.0.1:443)
    • Enable the checkbox for Monitor Logging
    • Open an SSH session (I use Putty to connect) to the device and log in to the shell.

      • Run the command cd /var/log/monitors
      • Run the command ls -l
      • Look for the file referencing your pool and member (most likely in our example it'd be something like _Common_RDP_MONITOR__Common_10.0.0.1_443.log)
      • Run the command tail -f FILENAME (where FILENAME is the log filename)
      • It may be visible immediately, but you should see where the monitor sends the request to the server (and you'll see the send string), and you're looking for the recv string that comes back.
      • Take that recv string and update the monitor and see if the pool member(s) show up green again.
    • Go back in and disable the monitor logging for that member so you don't have excessive logging filling up space.

    This should help figure it out. If your log file ever looks like it's not updating, delete the file and remove the monitor from the pool and re-add it. I've found that will kick it back off again.