You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/load-balancer/load-balancer-standard-diagnostics.md
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -82,7 +82,7 @@ To configure alerts:
82
82
### <aname = "DiagnosticScenarios"></a>Common diagnostic scenarios and recommended views
83
83
84
84
#### Is the data path up and available for my load balancer VIP?
85
-
<details><summary></summary>
85
+
<details><summary>Expand</summary>
86
86
87
87
The VIP availability metric describes the health of the data path within the region to the compute host where your VMs are located. The metric is a reflection of the health of the Azure infrastructure. You can use the metric to:
88
88
- Monitor the external availability of your service
@@ -114,7 +114,7 @@ Use **Average** as the aggregation for most scenarios.
114
114
115
115
#### Are the back-end instances for my VIP responding to probes?
116
116
<details>
117
-
<summary>Click to learn how to answer with metrics!</summary>
117
+
<summary>Expand</summary>
118
118
The health probe status metric describes the health of your application deployment as configured by you when you configure the health probe of your load balancer. The load balancer uses the status of the health probe to determine where to send new flows. Health probes originate from an Azure infrastructure address and are visible within the guest OS of the VM.
119
119
120
120
To get the health probe status for your Standard Load Balancer resources:
@@ -130,7 +130,7 @@ Use **Average** as the aggregation for most scenarios.
130
130
131
131
#### How do I check my outbound connection statistics?
132
132
<details>
133
-
<summary>Click to learn how with metrics!</summary>
133
+
<summary>Expand</summary>
134
134
The SNAT connections metric describes the volume of successful and failed connections for [outbound flows](https://aka.ms/lboutbound).
135
135
136
136
A failed connections volume of greater than zero indicates SNAT port exhaustion. You must investigate further to determine what may be causing these failures. SNAT port exhaustion manifests as a failure to establish an [outbound flow](https://aka.ms/lboutbound). Review the article about outbound connections to understand the scenarios and mechanisms at work, and to learn how to mitigate and design to avoid SNAT port exhaustion.
@@ -147,7 +147,7 @@ To get SNAT connection statistics:
147
147
148
148
#### How do I check my SNAT port usage and allocation?
149
149
<details>
150
-
<summary>Click to learn how with metrics!</summary>
150
+
<summary>Expand</summary>
151
151
The SNAT Usage metric indicates how many unique flows are established between an internet source and a backend VM or virtual machine scale set that is behind a load balancer and does not have a public IP address. By comparing this with the SNAT Allocation metric, you can determine if your service is experiencing or at risk of SNAT exhaustion and resulting outbound flow failure.
152
152
153
153
If your metrics indicate risk of [outbound flow](https://aka.ms/lboutbound) failure, reference the article and take steps to mitigate this to ensure service health.
@@ -173,7 +173,7 @@ To view SNAT port usage and allocation:
173
173
174
174
#### How do I check inbound/outbound connection attempts for my service?
175
175
<details>
176
-
<summary>Click to learn how with metrics!</summary>
176
+
<summary>Expand</summary>
177
177
A SYN packets metric describes the volume of TCP SYN packets, which have arrived or were sent (for [outbound flows](https://aka.ms/lboutbound)) that are associated with a specific front end. You can use this metric to understand TCP connection attempts to your service.
178
178
179
179
Use **Total** as the aggregation for most scenarios.
@@ -186,7 +186,7 @@ Use **Total** as the aggregation for most scenarios.
186
186
187
187
#### How do I check my network bandwidth consumption?
188
188
<details>
189
-
<summary>Click to learn how with metrics!</summary>
189
+
<summary>Expand</summary>
190
190
The bytes and packet counters metric describes the volume of bytes and packets that are sent or received by your service on a per-front-end basis.
191
191
192
192
Use **Total** as the aggregation for most scenarios.
@@ -204,7 +204,7 @@ To get byte or packet count statistics:
204
204
205
205
#### <aname = "vipavailabilityandhealthprobes"></a>How do I diagnose my load balancer deployment?
206
206
<details>
207
-
<summary>Click to learn how with metrics!</summary>
207
+
<summary>Expand</summary>
208
208
By using a combination of the VIP availability and health probe metrics on a single chart you can identify where to look for the problem and resolve the problem. You can gain assurance that Azure is working correctly and use this knowledge to conclusively determine that the configuration or application is the root cause.
209
209
210
210
You can use health probe metrics to understand how Azure views the health of your deployment as per the configuration you have provided. Looking at health probes is always a great first step in monitoring or determining a cause.
0 commit comments