Forum Discussion

Icon for Cirrus rank

Cirrus

Dec 05, 2023

Health monitor question

We have a user who is seeing this message very frequently in their logs from the F5 statis self IP.

10.192.10.XXX - - [04/Dec/2023:15:56:36 -0600] "GET / " 404 682

All our nodes are reporting as up, but when you use "wget https://node:8443" or go to the node directly using https://node:8443/, it always returns a 404. The only way it doesn't is if you use https://node:8443/bc.

How are our nodes up if the result is always 404?
Is there something different I need to do besides the base https_8443 health monitor?

application delivery

PhatANhappy
Dec 06, 2023
A base HTTP(s) monitor will send a " GET / " to the service port of the pool memember, but does NOT have any recieve string. ANY response from a server 200/301/404 etc.... is a response to the monitor, and hence the node is marked up.
in creating a new monitor based off the https monitor, you can keep the default settings and change the recv string to HTTP/1\.(0|1) (2|3) <---- that will allow only 200 and 300 errors and 400/500 errors will be marked as node down. This is a great step in the right direction of providing better quality of service. It will also in the long run will have you learning all the 400/500 error codes and what they mean as you debug why the pool member is down.

Niels_van_Sluis
MVP
Dec 05, 2023
Yes, in the https_8443 health monitor check if the receive string is set. If the response of the pool member, doesn't match the receive string, then the pool member will me marked as down.

See: Using regular expressions in a health monitor receive string (f5.com)
PhatANhappy
MVP
Dec 06, 2023
A base HTTP(s) monitor will send a " GET / " to the service port of the pool memember, but does NOT have any recieve string. ANY response from a server 200/301/404 etc.... is a response to the monitor, and hence the node is marked up.
in creating a new monitor based off the https monitor, you can keep the default settings and change the recv string to HTTP/1\.(0|1) (2|3) <---- that will allow only 200 and 300 errors and 400/500 errors will be marked as node down. This is a great step in the right direction of providing better quality of service. It will also in the long run will have you learning all the 400/500 error codes and what they mean as you debug why the pool member is down.
MarieTiller
Nimbostratus
Dec 08, 2023
It seems like the health monitor is expecting a specific path (/bc) to determine the node's health. Ensure that the health monitor configuration matches the expected path for your application, or adjust it accordingly to accurately reflect the application's health status. Additionally, review the application's configuration to confirm the correct path for health checks.