- 12 Jun 2020
- 1 Minute to read
- Print
- DarkLight
Configuring Load Balancer Health Probes For Decisions Application
- Updated on 12 Jun 2020
- 1 Minute to read
- Print
- DarkLight
Overview
A Load Balancer has the capability to health check the servers that receive the traffic sent. Load Balancers are able to use health probes that connect to the Decisions HealthCheck.aspx for determining if a server is healthy. If the server fails the health probe enough times, it will stop receiving traffic from the Load Balancer until it starts passing the health probe again. Selecting the appropriate type of health check is necessary to ensure the correct behavior of the load balancer.
Decisions is a multi-tiered application and as such, checking that the server or virtual machine running the application is available is not sufficient. An issue can occur with the application that causes it to be unavailable but any pings or checks directly to the VM will not correctly report back the application being down. To prevent this, the /healthcheck.aspx health check endpoint is recommended for the Decisions application.
To find out more about HealthCheck.aspx, please visit the App Server Health Monitor article.
Configuring A Health Probe
This screenshot shows an example of a Health Probe configuration using Azure.
Path: This is the file path noted in the informational callout above, used to associate the health probe with the HealthCheck.aspx
Interval (seconds): This is to define how often the health probe will run.
Timeout (seconds): This is to define the amount of time until the health probe times out due to a bad response from the server.
Unhealthy threshold: This is to define a number of attempts for reaching the server until the health check declares that the server is unhealthy.
Use Probe Matching Conditions/HTTP Response Status Match: When enabled, this setting tells the health probe that it needs to receive a matching HTTP response code configured in the text box. In this case, and in most cases, 200 is recommended.