K5917: Using regular expressions in a health monitor receive string
Non-Diagnostic
Original Publication Date: Oct 20, 2015
Update Date: Aug 24, 2021
Topic
Some BIG-IP application health monitors, such as the HTTP monitor, include a Receive String field. This field specifies a string for comparison with the server response. You can specify a regular expression in that field to provide some flexibility in matching an expected response from a healthy server. Health monitors that support regular expressions include TCP, HTTP, HTTPS, and User Datagram Protocol (UDP).
Regular expressions provide the flexibility for identifying strings of text that are of interest, such as certain characters, words, or a pattern of characters. With some exceptions, health monitors on BIG-IP systems support the use of POSIX Extended Regular Expressions (ERE). ERE syntax treats most characters as literals, meaning that they match only themselves, and defines metacharacters, which can be used to represent special characters, multiple characters, or a sequences of characters.
To reduce operating overhead for the BIG-IP system, F5 recommends that, whenever possible, you use static strings for monitoring. Using static strings instead of regular expressions for monitoring is simpler and more efficient. However, the performance impact is minimal in comparison to the administrative flexibility offered from using regular expressions.
For example, your HTTP health monitor requests the /admin/monitor.html page from the web server, which invokes a simple local script. The script checks whether vital local operating parameters, such as connections, memory, processor, or disk space, are within acceptable limits. If so, the script returns the monitor.html page, which includes a single line of body text that varies for each server, based on the server name:
Server1: OK Server2: OK Server3: OK
If you do not use a regular expression to match this response, you must create three separate monitors, each with a different receive string, and ensure the correct monitor is applied to each server. However, you can create a single monitor that uses ERE metacharacters in a receive string regular expression that will match the expected healthy response regardless of the variation in the server name. The following examples match all of the server responses above, with varying levels of specificity:
Server.: OK Server[0-9]: OK Server[123]: OK Constructing BIG-IP monitor Receive Strings using regular expressions
Two differences exist between standard regular expression logic and that implemented in the BIG-IP receive rule engine:
The BIG-IP LTM receive rule engine is case insensitive; a lowercase letter will match both the uppercase and lowercase of the same letter.
Note: The receive rule engine functionality differs between BIG-IP LTM and BIG-IP GTM; while the BIG-IP LTM receive rule engine is not case-sensitive, the BIG-IP GTM receive rule engine is case- sensitive.
The entire server response is processed as one data stream, which the receive rule engine evaluates against the regular expression as a single line. As a result, there is only one line beginning (the beginning of the response line), there is only one line ending (the end of the response), and white space or boundary characters may not match, as expected.
The following sections detail the use of metacharacters in receive strings. The examples in each section assume that the following response is expected from a healthy server:
HTTP/1.0 200 OK\r\n Server: Microsoft-IIS/5.0 ...
win2000.gif
Alternation
You can use the pipe metacharacter (|) to match on one of a set. A match is achieved if one of the set matches. You may observe the results listed in the following table.
Receive string Match? Explanation http|OK Yes Both http and OK are present in the response. OK|htp Yes OK is present in the response. bbb|htp No Neither bbb nor htp is present in the response. bbb|http Yes HTTP is present in the response.
Line anchors
A caret (^) signifies the start of line. A dollar sign ($) signifies the end of line anchor.
The line anchors do not work as they do in standard regular expressions: the rule engine sees the beginning of the response as the start of line, and the end of the response data as the end of line. You may observe the results listed in the following table.
Receive Match? Explanation string OK\r\n$ No In the example response above, the receive rule engine sees only a single start-of-line followed by the string HTTP. In the example response above, the receive rule engine sees only a single end-of-line >