Summary
This document describes how to troubleshoot monitor of type HTTP-ECV. In this case, HTTP-ECV monitor probes sent by the NetScaler to the server are failing, even though the web page can be accessed successfully on the Web server.
Background
A monitor of type HTTP-ECV may be configured to check that the response to a specific HTTP request from the NetScaler to the Web server contains a response containing particular data. When the response containing the particular data is received, the NetScaler deduces that the site is up. This may be required in scenarios where simpler monitoring does not provide an adequate guarantee that the server is actually functioning sufficiently to serve the requests. For example, a monitor may be defined to probe a Web server that is a front end to a database, and the HTTP response should be checked to ensure that the Web server is querying the database correctly.
The HTTP-ECV monitor uses the parameters
send [""] - HTTP data is sent to the service
recv [""] - the expected HTTP response data from the service
As an example, a custom HTTP-ECV monitor may be defined as follows:
> add monitor <name> http-ecv –send “GET /siteup.html” –recv “site_is_up”
This monitor causes NetScaler to probe the backend HTTP service to which the monitor is bound with a HTTP GET request for the file %wwwroot%/siteup.html. NetScaler expects to receive a response containing the string “site_is_up”.
Procedure
The string expected by the monitor (as specified in the recv parameter) must be found within the first 24 KB of the body of the HTTP response, otherwise the probe fails.
To determine if the required string exists within the first 24 KB of the response, use an Ethereal or Wireshark network trace to ensure that the string expected by the monitor can be found within the first 24 KB of the body of the HTTP response. If it is not found in the first 24 KB of the body of the HTTP response from the server, then the HTTP-ECV monitor fails, but the Web page can be accessed successfully.
More Information
This behavior is by design. Unnecessary processing overhead would be introduced by expecting the NetScaler to search an arbitrary length HTTP response from the server.
