How an Azure Load Balancer gets to know if an application - a spring MVC application - deployed in an load-balanced VM is down?Is it by pinging the url? The VM may be up, but the application may be down.Do you have to make any changes to your application - implement an echo service? What good will be "Health Probes" if say we define port 80, TCP - ok that works but application does not.
I have read this, but still could not wrap my head around the issue: https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-health-extension
Azure Load Balancer provides health probes for use with load-balancing rules. Health probes could support protocols depends on the Load balancer SKU.
For TCP probe, it initiates a connection by performing a three-way open TCP handshake with the defined port. TCP probes terminate a connection with a four-way close TCP handshake.
For HTTP / HTTPS probe, it builds on the TCP probe and issues an HTTP GET with the specified path. Both of these probes support relative paths for the HTTP GET. The health probe is marked up when the instance responds with an HTTP status 200 within the timeout period. The health probe attempts to check the configured health probe port every 15 seconds by default. The minimum probe interval is 5 seconds. The total duration of all intervals cannot exceed 120 seconds.
TCP, HTTP, and HTTPS health probes are considered healthy and mark the role instance as healthy when:
- The health probe is successful once after the VM boots.
- The specified number of probes required to mark the role instance as healthy has been achieved.
Probe behavior depends on:
- The number of successful probes that allow an instance to be marked as up.
- The number of failed probes that cause an instance to be marked as down.
- The timeout and interval values specified determine whether an instance is marked as up or down.
The health probe traffic is directly between the probing service that generates the health probe and the customer VM. All Load Balancer health probes originate from the IP address 168.63.129.16 as their probe source IP address.
Overall, you could refer to the design guidance to design your health probe in your scenario, the application port and the probe port are not required to be the same. In some scenarios, it may be desirable for the probe port to be different than the port your application provides service on. In your case, I think if you have a TCP port 3389 or SSH 22 to your backend VM probe success, then HTTP probe fails with port 80, it might be the scenario "The VM may be up, but the application may be down."