Creating a website health check

[Nick Oliver]

I have no idea if this is even the right place for this question - 

A customer wants a website to do a health check and if a 503 occurs, the traffic will then be routed to the next server.  I think that a monitor is what I need, but don't find a reference for this kind of action. 

 

My background in using a netscaler is creating VIP's, assigning basic load balancing to services, that kind of thing - My experience in doing rules and responses is via cut and paste from existing examples.

thanks,

Nick Oliver

Systems Administrator 

IBM Cloud

[Rhonda Rowland1709152125]

There's a lot of built in monitors already and you do have the ability to build your own in perl.

 

However, the regular HTTP monitor can be used to check a specific page and validate a 200 OK (or other response code is received) and if not, down the service.  Therefore, you shouldn't need a monitor to look explicitly for 503 (service unavailable), just anything not returning a 200 OK should not be used.  Just identify which page to query to determine the result.

The USER monitor type is the custom monitor (just so you have the info) and is documented some here:  https://docs.citrix.com/en-us/citrix-adc/current-release/load-balancing/load-balancing-custom-monitors/understand-user-monitors.html  (They are also written in PERL)

Example: regular http monitors....

add lb monitor mon_httpcheck HTTP -respCode 200 -httpRequest "Head /" 

add lb monitor mon_httpcheck2 HTTP -respCode 200 -httpRequest "Head /somepage.htm"

# bind to your services with whichever test works for you; anything that isn't 200 OK response will be down anyway.

 

If you still need a custom 503 validation, you can write your own. First, you need to determine which page to query AND you would need to use a REV monitor to keep service UP when 503 not returned in addition to a regular monitor.

 

Regarding your second requirement, to send traffic to next service in list,  you just need a series of lb vservers and services set as backup vservers.

Normally, you would create a single lb vserver with 2 or more services bound and load balancing would ensure traffic is sent between services svc1, svc2, svc3 - based on criteria such as which ones are UP and persistence.  DOWN services are skipped automatically.

 

If you want all traffic to go to service 1 only until its down, then failover over to service 2, you can use the backup lb vserver property of the lb vserver.  It will only use the backup destination if the primary vserver is down.  Client traffic is still client-to-vip1 (user will never see "backup vserver" directly and can be a non-addressable vserver), but when primary vserver is down due to no services available, it will rely on services on backup vserver. If needed, you can daisy chain multiples.

 

And if this is not what you described, the below won't help you as much.  But example of backup vservers below.

 

add service svc1 1.2.3.4 http 80

add service svc2 1.2.3.5 http 80

add service svc3 1.2.3.6 http 80

 

# Second backup; non addressable

add lb vserver lb_vsrv3 HTTP 

bind lb vserver lb_vsrv3 svc3

 

# First backup; non addressable with secondary and fallback

add lb vserver lb_vsrv2 HTTP -backuplbvserver lb_vsrv3 

bind lb vserver lb_vsrv2 svc2

 

# Primary vserver/service...

add lb vserver lb_vsrv1 HTTP <VIP1> 80 -backuplbvserver lb_vsrv2

bind lb vserver lb_vsrv_primary svc1

 

 

 

[Nick Oliver]

Rhonda,

Thanks very much for your response.  I feel like I am moving to another level of netscaler use and understanding - 

So to clear up any questions in my mind:

1. To look for any response other than 200 would be counter productive.  If the response (say a 503) was NOT found, the connection would fail.

2. Looking for 200 is desired (but not necessary), as that is the normal "good',

3. If they want to search for 200 for a specific page, that can be done (by your example above), and if a 200 is not found, the service will be downed (regardless of the code returned).

 

[Rhonda Rowland1709152125]

Yes. You've got it. (Point 2 is a little inaccurate; if you aren't doing a web probe there a few places where the service could be UP and not do what you want because your probe is less specific; but 1 and 3 are correct.)

 

So the monitor is a positive condition (usually): if probe succeeds, mark service UP; if probe fails, mark service DOWN.

If we were just using a PING probe, it would verify IP responds but not confirm that port 80 is running or returning specific responses to pages.  So, you have a range in which the probe works but the app is down and couldn't be used. So your monitor wouldn't be as reliable.  The default for web traffic is actually the tcp-default monitor (which just verifies the IP/port and confirms the tcp handshake starts, but could still result in a service being unable to generate a web response.

 

If you use the HTTP monitor and test the default page "/" or a specific page "/somepage.htm" then the probe will make this request to the web server during the monitor event and if probe succeeds it returns one of the expected response codes. Usually this is just a 200 OK response and therefore anything else is invalid and will DOWN the service.

 

So, during regular load balancing if you bind a custom instance of the HTTP monitor with your own page request and response code (or codes) you want, then anything not in  list is DOWN. Including any 503 error too.

 

If your end user wants to treat the 503 as a specific subset of errors and do something unique on that error vs any other, then things would be more complicated. But since your request isn't being fulfilled other than 200, we shouldn't need that type of condition.  Any time the service is not responding 200 OK, go to next service.

 

Also, even if you were load balancing and not failing over, any  service that is DOWN will be bypassed for load balancing.  Traffic is only sent to a service in an UP state.

 

 

 

[Nick Oliver]

Rhonda,

Great, thanks - this will allow me to update the customer and see if he REALLY wants what he asked for.

 

[Nick Oliver]

The customer has asked me this:

"Can you please implement the rule for if a 200 status code is not detected?"

 

Is this something the "reverse monitor" can apply to?

[Rhonda Rowland1709152125]

The regular monitor does this automatically.

 

Regular monitors (reverse:OFF):  monitor succeeds, service is UP and in use; monitor fails, service is DOWN and not used.

The default HTTP monitor probes a page via a HEAD request. If page returns 200 OK, then service is UP; if any other code received OR no response at all, then service is down.

 

You do not need a reverse monitor. (Sorry for delay returning a response to you; holidays interrupted my schedule.)