Skip to content

Commit 8e86b2d

Browse files
author
Michael Bender
committed
updates to concepts
1 parent 714faac commit 8e86b2d

File tree

2 files changed

+162
-0
lines changed

2 files changed

+162
-0
lines changed

‎articles/load-balancer/TOC.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -138,6 +138,8 @@
138138
href: load-balancer-standard-diagnostics.md
139139
- name: Load Balancer Health Event Logs
140140
href: load-balancer-health-event-logs.md
141+
- name: Manage Load Balancer health status
142+
href: load-balancer-manage-health-status.md
141143
- name: Inbound connectivity
142144
items:
143145
- name: Inbound NAT rules

‎articles/load-balancer/load-balancer-manage-health-status.md

Lines changed: 160 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,160 @@
1+
---
2+
title: Manage Azure Load Balancer health status
3+
titleSuffix: Azure Load Balancer
4+
description: Learn how to manage Azure Load Balancer health status to get detailed health information about the backend instances in your Azure Load Balancer backend pool.
5+
author: mbender
6+
ms.service: azure-load-balancer
7+
ms.topic: concept-article
8+
ms.date: 10/30/2024
9+
ms.author: mbender-ms
10+
ms.custom: references_regions
11+
---
12+
13+
# Manage Azure Load Balancer Health Status
14+
15+
Health status is an Azure Load Balancer feature that gives detailed health information about the backend instances in your Azure Load Balancer backend pool linked to your load balancing rule. This status provides insights into the health state and reasoning of these backend instances.
16+
17+
## State of backend instances
18+
19+
Health status exposes the state of your backend instances. There are two state values:
20+
21+
| **State** | **Description** |
22+
|-----------|-----------------|
23+
| Up | This state value represents a healthy backend instance. |
24+
| Down | This state value represents an unhealthy backend instance. |
25+
26+
## Reason codes
27+
28+
Health status also exposes various reason codes, categorized into User Triggered Reason Codes and Platform Triggered Reason Codes. These codes help you understand the precise reasons for the health probe state of your backend instances and why they're being probed being Up or Down.
29+
30+
### User Triggered Reason Codes
31+
32+
User triggered reason codes are triggered based on how you configured your Load Balancer; these can be addressed by you, the user. The following tables describe the user-triggered reason codes along with the portal displayed reason for success and failed reason codes.
33+
34+
#### Success reason codes
35+
36+
The following table describes the success reason codes where the backend state is equal to **Up**:
37+
38+
| **Reason Code** | **Portal displayed reason** | **Description** |
39+
|-------------|-------------------------|-------------|
40+
| **Up_Probe_Succes**s | The backend instance is responding to health probe successfully. | Your backend instance is responding to the health probe successfully. |
41+
| **Up_Probe_AllDownIsUp** | The backend instance is considered healthy due to enablement of *NoHealthyBackendsBehavior*. | Health probe state of the backend instance is ignored because *NoHealthyBackendsBehavior* is enabled. The backend instance is considered healthy and can receive traffic. |
42+
| **Up_Probe_ApproachingUnhealthyThreshold** | Health probe is approaching an unhealthy threshold but backend instance remains healthy based on last response. | The most recent probe has failed to respond but the backend instance remains healthy enough based on earlier responses. |
43+
| **Up_Admin**| The backend instance is healthy due to Admin State set to *Up*. | Health probe state of the backend instance is ignored because the Admin State is set to *UP*. The backend instance is considered healthy and can receive traffic. |
44+
45+
#### Failure reason codes
46+
47+
The following table describes the failure reason codes where the backend state is equal to **Down**:
48+
49+
| **Reason Code** | **Portal displayed reason** | **Description** |
50+
|-------------|-------------------------|-------------|
51+
| **Down_Probe_ApproachingHealthyThreshold** | Health probe is approaching a healthy threshold but backend instance remains unhealthy based on last response. | The most recent probe outcome is positive, but it doesn't meet the required number of responses in the healthy threshold, so the backend instance remains unhealthy. |
52+
| **Down_Probe_HttpStatusCodeError** | A non-200 HTTP status code received; meaning there's an issue with the application listening on the port. | Your backend instance is returning a non-200 HTTP status code indicating an issue with the application listening on the port. |
53+
| **Down_Probe_HttpEndpointUnreachable** | HTTP endpoint unreachable; meaning either an NSG rule blocking port or unhealthy app listening on port. | The health probe was able to establish a TCP handshake with your backend instance but the HTTP session was rejected which indicates two possibilities: An NSG rule blocking the port or no healthy application listening on the port. |
54+
| **Down_Probe_TcpProbeTimeout** | TCP probe timeout; meaning either unhealthy backend instance, blocked health probe port, or unhealthy app listening on port. | Your backend instance has sent back no TCP response within the probe interval. This indicates three possibilities: An unhealthy Backend Instance, blocked health probe port, or unhealthy application listening on the port. |
55+
| **Down_Probe_NoHealthyBackend** | No healthy backend instances behind the regional load balancer. | Your regional load balancer that is associated with a Global Load Balancer has no healthy backend instances behind it. |
56+
| **Down_Admin** | The backend instance is unhealthy due to *Admin State* set to *Down*. | Health probe state of the backend instance is ignored because the *Admin State* is set to *Down*. The backend instance is considered unhealthy and can't receive new traffic. |
57+
| **Down_Probe_HttpNoResponse** | Application isn't returning a response. | The health probe was able to establish an HTTP session but the application isn't returning a response. This indicates an unhealthy application listening on the port. |
58+
59+
> [!NOTE]
60+
> In rare cases, **NA** will show as a reason code. This code is shown when the health probe has not probed your backend instance yet so there is no reason code to display.
61+
62+
### Platform Triggered reason codes
63+
64+
Platform triggered reason codes are triggered based on the Azure Load Balancer’s platform; these codes can't be addressed by you, the user. The following table below describes each reason code:
65+
66+
| **Reason Code** | **Portal displayed reason** | **Description** |
67+
|-------------|-------------------------|-------------|
68+
| **Up_Platform** | The backend instance is responding to the health probe successfully, but there may be an infrastructure related issue. The Azure service team is alerted and will resolve the issue.| The backend instance is responding to the health probe successfully, but there can be an infrastructure related issue. The Azure service team is alerted and will resolve the issue. |
69+
| **Down_Platform** | The backend instance is unhealthy due to an infrastructure related issue. The Azure service team is alerted and will resolve the issue. | The backend instance is unhealthy due to an infrastructure related issue. The Azure service team is alerted and will resolve the issue. |
70+
71+
# [Azure portal](#tab/azure-portal)
72+
## How to retrieve health status
73+
74+
Health status can be retrieved on a per load balancing rule basis. This is supported via Azure port and REST API.
75+
76+
1. Sign in to the Azure portal.
77+
2. In the search bar, enter **Load Balancers** and select **Load Balancers** from the search results.
78+
3. On the **Load Balancers** page, select your load balancer from the list.
79+
4. In your load balancer's **Settings** section, select **Load balancing rules**.
80+
5. In the **Load balancing rules** page, select **View details** under the **Health state** column for the rule you want to view.
81+
6. Review the health status of your backend instances in the **Load balancing rule health status** window.
82+
7. To retrieve the latest health status, select **Refresh**.
83+
84+
> [!IMPORTANT]
85+
> The Load balancing rule health status window may take a few minutes to load the health status of your backend instances.
86+
87+
8. Select **Close** to exit the **Load balancing rule health status** window.
88+
89+
# [REST API](#tab/rest-api)
90+
91+
To retrieve the health status information via REST API, you need to do a two request process.
92+
93+
> [!NOTE]
94+
> Using the REST API method requres that you have a **Bearer access token** for autorization. For assistance retrieving the access token, see [Get-AzAccessToken](/powershell/module/az.accounts/get-azaccesstoken?view=azps-12.4.0&viewFallbackFrom=azps-12.2.0) for details.
95+
96+
1. Use the following POST request to obtain the Location URI from the Response Headers.
97+
98+
```rest
99+
100+
101+
POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/loadBalancers/{loadBalancerName}/loadBalancingRules/{loadBalancingRulesName}/health?api-version=2024-03-01
102+
Authorization: Bearer <access token>
103+
104+
```
105+
106+
1. Copy the Location URI from the Response Headers. Location URI should follow this schema.
107+
108+
```rest
109+
https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Network/locations/{locationName}/operationResults/{operationResultsId}?api-version=2024-03-01
110+
```
111+
112+
1. Use the copied Location URI to make a GET request.
113+
114+
```rest
115+
GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Network/locations/{locationName}/operationResults/{operationResultsId}?api-version=2024-03-01
116+
117+
Authorization: Bearer <access token>
118+
119+
```
120+
121+
1. A status code of 200 is returned and the health status information is displayed in the response body similar to this example response:
122+
123+
```JSON
124+
{
125+
"up": 2,
126+
"down": 0,
127+
"loadBalancerBackendAddresses": [
128+
{
129+
"ipAddress": "10.0.2.5",
130+
"networkInterfaceIPConfigurationId": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/networkInterfaces/{networkInterfaceName}/ipConfigurations/{ipConfigurationName}",
131+
"state": "Up",
132+
"reason": "Up_Admin"
133+
},
134+
{
135+
"ipAddress": "10.0.2.4",
136+
"networkInterfaceIPConfigurationId": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/networkInterfaces/{networkInterfaceName}/ipConfigurations/{ipConfigurationName}",
137+
"state": "Up",
138+
"reason": "Up_Probe_Success"
139+
}
140+
]
141+
}
142+
143+
```
144+
145+
## Design considerations
146+
147+
When using the health status feature, consider the following design considerations:
148+
149+
- If the virtual machine instance in the backend pool is turned off, health status returns empty values since the health status isn't retrievable.
150+
- If you're using a global load balancer, health status displays the reason as *Down_Platform** when a regional load balancer’s backend pool is an IP-based backend address that isn't associated with a virtual machine instance.
151+
- For retrieving health status, the Azure portal and REST API methods are the only supported methods.
152+
153+
## Limitations
154+
155+
When using the health status feature, consider the following limitations:
156+
157+
- Health status isn’t supported for nonprobed load balancing rules.
158+
- Health status isn’t supported for Gateway Load Balancer.
159+
160+
## Next steps

0 commit comments

Comments
 (0)