edit pass: three-load-balancer-articles

Author: ShawnJackson

articles/load-balancer/load-balancer-overview.md

@@ -30,7 +30,7 @@ For more information on the service's individual components, see [Azure Load Bal
 
 With Azure Load Balancer, you can scale your applications and create highly available services.
 
-The service supports both inbound and outbound scenarios. It provides low latency and high throughput, and it scales up to millions of flows for all Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) applications.
+The service supports both inbound and outbound scenarios. It provides low latency and high throughput, and it scales up to millions of flows for all TCP and UDP applications.
 
 Key scenarios that you can accomplish by using Azure Standard Load Balancer include:
 

articles/load-balancer/troubleshoot-rhc.md

@@ -1,6 +1,6 @@
 ---
 title: Troubleshoot Azure Load Balancer resource health, frontend, and backend availability problems
-description: Use the available metrics to diagnose your degraded or unavailable Azure Standard Load Balancer instance.
+description: Use the available metrics to diagnose your degraded or unavailable Azure Standard Load Balancer deployment.
 services: load-balancer
 author: mbender-ms
 ms.service: azure-load-balancer
@@ -12,14 +12,14 @@ ms.custom: FY23 content-maintenance
 
 # Troubleshoot resource health and inbound availability problems
 
-This article is a guide to investigate problems that affect the availability of your load balancer's frontend IP and backend resources.
+This article can help you investigate problems that affect the availability of your load balancer's frontend IP and backend resources.
 
 You can use the *resource health* feature in Azure Load Balancer to determine the health of your load balancer. It analyzes the Data Path Availability metric to determine whether the load-balancing endpoints, the frontend IP, and frontend port combinations with load-balancing rules are available.
 
 > [!NOTE]
-> The Basic Load Balancer tier doesn't support the resource health feature.
+> Basic Load Balancer doesn't support the resource health feature.
 
-The following table describes the logic that Azure Load Balancer uses to determine the health status of your load balancer.
+The following table describes the logic for determining the health status of your load balancer.
 
 | Resource health status | Description |
 | --- | --- |
@@ -34,53 +34,53 @@ The two metrics that Azure Load Balancer uses to check resource health are *Data
 
 ### Data Path Availability
 
-A TCP ping generates the Data Path Availability metric every 25 seconds on all frontend ports where you configured load-balancing rules. This TCP ping is routed to any of the healthy (probed up) backend instances. The metric is an aggregated percentage success rate of TCP pings on each frontend IP:port combination for each of your load balancing rules, across a sample period of time.
+A TCP ping generates the Data Path Availability metric every 25 seconds on all frontend ports where you configured load-balancing rules. This TCP ping is routed to any of the healthy (probed up) backend instances. The metric is an aggregated percentage success rate of TCP pings on each frontend IP/port combination for each of your load-balancing rules, across a sample period of time.
 
 ### Health Probe Status
 
-The Health Probe Status metric is generated by a ping of the protocol defined in the health probe. This ping is sent to each instance in the backend pool and on the port defined in the health probe. For HTTP and HTTPS probes, a successful ping requires an HTTP 200 OK response whereas with TCP probes any response is considered successful.
+A ping of the protocol defined in the health probe generates the Health Probe Status metric. This ping is sent to each instance in the backend pool and on the port defined in the health probe. For HTTP and HTTPS probes, a successful ping requires an `HTTP 200 OK` response. With TCP probes, any response is considered successful.
 
-The health of each backend instance is determined when the probe has reached the number of consecutive successes or failures necessary, based on your configuration of the probe threshold property. The health status of each backend instance determines whether or not the backend instance is allowed to receive traffic.
+Azure Load Balancer determines the health of each backend instance when the probe reaches the number of consecutive successes or failures that you configured for the probe threshold property. The health status of each backend instance determines whether or not the backend instance is allowed to receive traffic.
 
-Similar to the Data Path Availability metric, the Health Probe Status metric aggregates the average successful/total pings during the sampling interval. The Health Probe Status value indicates the backend health in isolation from your load balancer by probing your backend instances without sending traffic through the frontend.
+Like the Data Path Availability metric, the Health Probe Status metric aggregates the average successful and total pings during the sampling interval. The Health Probe Status value indicates the backend health in isolation from your load balancer by probing your backend instances without sending traffic through the frontend.
 
 > [!IMPORTANT]
-> Health Probe Status is sampled on a one-minute basis. This can lead to minor fluctuations in an otherwise steady value.
+> Health Probe Status is sampled on a one-minute basis. This sampling can lead to minor fluctuations in an otherwise steady value.
 >
-> For example, in Active/Passive scenarios where there are two backend instances, one probed up and one probed down, the health probe service may capture seven samples for the healthy instance and 6 for the unhealthy instance. This will lead to a previously steady value of 50 showing as 46.15 for a one-minute interval.
+> For example, consider active/passive scenarios where there are two backend instances, one probed up and one probed down. The health probe service might capture seven samples for the healthy instance and six for the unhealthy instance. This situation leads to a previously steady value of 50 showing as 46.15 for a one-minute interval.
 
 ## Diagnose degraded and unavailable load balancers
 
-As outlined in the [resource health article](load-balancer-standard-diagnostics.md#resource-health-status), a degraded load balancer is one that shows between 25% and 90% data path availability. An unavailable load balancer is one with less than 25% data path availability, over a two-minute period.
+As outlined in the [this article about resource health](load-balancer-standard-diagnostics.md#resource-health-status), a degraded load balancer shows between 25% and 90% for Data Path Availability. An unavailable load balancer is one with less than 25% for Data Path Availability over a two-minute period.
 
-You can take the same steps to investigate the failure that you see in any Health Probe Status or Data Path Availability alerts that you configured. The following paragraphs explore the case where you checked your resource health and found your load balancer to be unavailable with a Data Path Availability of 0%. Your service is down.
+You can take the same steps to investigate the failure that you see in any Health Probe Status or Data Path Availability alerts that you configured. The following steps explore what to do if you check your resource health and find your load balancer to be unavailable with a Data Path Availability value of 0%. Your service is down.
 
-First, go to the detailed metrics view of your load balancer insights page in the Azure portal. Access the view from your load balancer resource page or the link in your resource health message.
+1. In the Azure portal, go to the detailed metrics view of the page for your load balancer insights. Access the view from the page for your load balancer resource or from the link in your resource health message.
 
-Next, go to the Frontend and Backend availability tab and review a 30-minute window of the time period when the degraded or unavailable state occurred. If you see your data path availability is 0%, you know that something is preventing traffic for all of your load-balancing rules, and you can see how long this problem has lasted.
+1. Go to the tab for frontend and backend availability, and review a 30-minute window of the time period when the degraded or unavailable state occurred. If the Data Path Availability value is 0%, you know that something is preventing traffic for all of your load-balancing rules. You can also see how long this problem has lasted.
 
-The next place you need to look is your Health Probe Status metric to determine whether your data path is unavailable because you have no healthy backend instances to serve traffic. If you have at least one healthy backend instance for all of your load-balancing and inbound rules, you know it isn't your configuration causing your data paths to be unavailable. This scenario indicates an Azure platform problem. Although platform problems are rare, an automated alert is sent to our team to rapidly resolve all platform problems.
+1. Check your Health Probe Status metric to determine whether your data path is unavailable because you have no healthy backend instances to serve traffic. If you have at least one healthy backend instance for all of your load-balancing and inbound rules, you know it isn't your configuration that's causing your data paths to be unavailable. This scenario indicates an Azure platform problem. Although platform problems are rare, they trigger an automated alert to our team for rapid resolution.
 
 ## Diagnose health probe failures
 
-If your Health Probe Status metric is reflecting that your backend instances are unhealthy, we recommend using the following checklist to rule out common configuration errors:
+If your Health Probe Status metric indicates that your backend instances are unhealthy, we recommend using the following checklist to rule out common configuration errors:
 
-* Check the CPU utilization for your resources to determine if they are under high load.
+* Check the CPU utilization for your resources to determine if they're under high load.
 
-  You can check this by viewing the resource's Percentage CPU metric via the Metrics page. Learn how to [Troubleshoot high-CPU issues for Azure virtual machines (VMs)](/troubleshoot/azure/virtual-machines/troubleshoot-high-cpu-issues-azure-windows-vm).
-* If using an HTTP or HTTPS probe check if the application is healthy and responsive.
+  You can check by viewing the resource's Percentage CPU metric via the **Metrics** page. For more information, see [Troubleshoot high-CPU issues for Azure Windows virtual machines](/troubleshoot/azure/virtual-machines/troubleshoot-high-cpu-issues-azure-windows-vm).
+* If you're using an HTTP or HTTPS probe, check if the application is healthy and responsive.
 
-  Validate your application is functional by directly accessing the applications through the private IP address or instance-level public IP address associated with your backend instance.
-* Review the Network Security Groups applied to our backend resources. Ensure that there are no rules of a higher priority than *AllowAzureLoadBalancerInBound* that blocks the health probe.
+  Validate that your application is functional by directly accessing it through the private IP address or instance-level public IP address that's associated with your backend instance.
+* Review the network security groups applied to your backend resources. Ensure that no rules have a higher priority than `AllowAzureLoadBalancerInBound` that block the health probe.
 
-  You can do this by visiting the Networking settings of your backend VMs or Virtual Machine Scale Sets. If you find this NSG problem is the case, move the existing Allow rule or create a new high priority rule to allow AzureLoadBalancer traffic.
-* Check your OS. Ensure your VMs are listening on the probe port and review their OS firewall rules to ensure they aren't blocking the probe traffic originating from IP address `168.63.129.16`.
+  You can do this task by visiting the network settings of your backend VMs or virtual machine scale sets. If you find that this NSG problem is the case, move the existing `Allow` rule or create a new high-priority rule to allow Azure Load Balancer traffic.
+* Check your OS. Ensure that your VMs are listening on the probe port. Also review the OS firewall rules for the VMs to ensure that they aren't blocking the probe traffic originating from IP address `168.63.129.16`.
 
   You can check listening ports by running `netstat -a` from a Windows command prompt or `netstat -l` from a Linux terminal.
-* Ensure you're using the right protocol. For example, a probe using HTTP to probe a port listening for a non-HTTP application fails.
-* Azure Firewall shouldn't be placed in the backend pool of load balancers. See [Integrate Azure Firewall with Azure Standard Load Balancer](../firewall/integrate-lb.md) to properly integrate Azure Firewall with load balancer.
+* Ensure that you're using the right protocol. For example, a probe that uses HTTP to probe a port listening for a non-HTTP application fails.
+* Don't place Azure Firewall in the backend pool of load balancers. For more information, see [Integrate Azure Firewall with Azure Standard Load Balancer](../firewall/integrate-lb.md).
 
 ## Related content
 
-* [Learn more about the Azure Load Balancer health probe](load-balancer-custom-probe-overview.md)
+* [Learn more about Azure Load Balancer health probes](load-balancer-custom-probe-overview.md)
 * [Learn more about Azure Load Balancer metrics](load-balancer-standard-diagnostics.md)