When configuring health monitors for a web application, targeting the appropriate HTTP status codes is crucial to ensure that the service is operating as expected. Different scenarios dictate different best practices. But as always, work with your development team to ensure the status codes are correct and what’s expected when probing.
Here are two common scenarios:
1. Monitoring HTTPS (port 443) for Secure Content Delivery:
When your application is serving content securely over HTTPS, monitoring that the content is available is essential. To do this, you generally check for a 200 OK status code, indicating the requested resource is available.
create ltm monitor https HTTPS_Content_Availability send "GET /path/to/resource HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n" recv "HTTP/1.[01] 200" interval 5 timeout 16
This configuration sends an HTTPS GET request to a specified resource and expects to receive a 200 status code in response. This status code ensures that the server is serving content successfully over HTTPS.
2. Monitoring HTTP to HTTPS Redirects (port 80 to 443):
If your application is configured to redirect traffic from HTTP to HTTPS for secure communication, it’s important to ensure that this redirection functions correctly. The typical status code for temporary redirection is 302.
create ltm monitor http HTTP_to_HTTPS_Redirect send "GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n" recv "HTTP/1.[01] 302" interval 5 timeout 16
This configuration sends an HTTP GET request to the host, expecting a 302 status code in response, confirming that the redirect to HTTPS is operational.
NOTE:
In this case, the server response to any request should be a 302 redirect if everything is working as expected, hence the lack of a specific resource in the “GET” request.
However, the application’s behavior varies based on the resource path. If certain paths have different redirect behaviors or do not redirect at all, then specifying a resource in the monitor may still be necessary. Always base your decision on the specific requirements and behaviors of your application.
NOTE 2:
Keep in mind when setting up the HTTP to HTTPS redirects in IIS or Apache, it could be set using any of the below HTTP status codes:
- 301 Permanent
- 302 Found
- 307 Temporary
- 308 Permanent Redirect
So make sure you configured the correct code.
Caution with using ranges or non-specific codes:
Using ranges or non-specific codes in monitoring can lead to false positives. For instance, if the monitor is configured to accept any 3xx status code as successful, it might not specifically check for the 302 redirects. As a result, another 3xx code might be returned by the server, which doesn’t necessarily mean that the HTTP to HTTPS redirect is functioning correctly. This might make you believe that everything is working when, in reality, the site is not redirecting users to HTTPS as intended.
Similarly, if the monitor is configured to accept any 2xx status code as successful for HTTPS content availability, this could mask an issue where content is not being served correctly, but some other form of a successful response is being given.
Conclusion:
Being specific about the expected response is vital when setting up health monitors. Monitor for a 200 status code when checking that content is being served correctly over HTTPS, and monitor for a 302 status code to ensure that HTTP to HTTPS redirects are functioning as expected. This specificity helps ensure that your health checks accurately reflect the operational state of your service and don’t give you a false sense of security.