Merge pull request #76793 from KumudD/githubissue29875

Image updates

Author: v-shils

articles/load-balancer/load-balancer-standard-diagnostics.md

@@ -11,7 +11,7 @@ ms.devlang: na
 ms.topic: article
 ms.tgt_pltfrm: na
 ms.workload: infrastructure-services
-ms.date: 10/11/2018
+ms.date: 06/06/2019
 ms.author: Kumud
 ---
 
@@ -26,33 +26,33 @@ This article provides a quick tour of these capabilities, and it offers ways to
 
 ## <a name = "MultiDimensionalMetrics"></a>Multi-dimensional metrics
 
-Azure Load Balancer provides new multi-dimensional metrics via the new Azure Metrics (preview) in the Azure portal, and it helps you get real-time diagnostic insights into your load balancer resources. 
+Azure Load Balancer provides new multi-dimensional metrics via the new Azure Metrics in the Azure portal, and it helps you get real-time diagnostic insights into your load balancer resources. 
 
 The various Standard Load Balancer configurations provide the following metrics:
 
 | Metric | Resource type | Description | Recommended aggregation |
 | --- | --- | --- | --- |
-| VIP availability (data path availability) | Public load balancer | Standard Load Balancer continuously exercises the data path from within a region to the load balancer front end, all the way to the SDN stack that supports your VM. As long as healthy instances remain, the measurement follows the same path as your application's load-balanced traffic. The data path that your customers use is also validated. The measurement is invisible to your application and does not interfere with other operations.| Average |
-| DIP availability (health probe status) |  Public and internal load balancer | Standard Load Balancer uses a distributed health-probing service that monitors your application endpoint's health according to your configuration settings. This metric provides an aggregate or per-endpoint filtered view of each instance endpoint in the load balancer pool. You can see how Load Balancer views the health of your application, as indicated by your health probe configuration. |  Average |
+| Data path availability (VIP availability)| Public load balancer | Standard Load Balancer continuously exercises the data path from within a region to the load balancer front end, all the way to the SDN stack that supports your VM. As long as healthy instances remain, the measurement follows the same path as your application's load-balanced traffic. The data path that your customers use is also validated. The measurement is invisible to your application and does not interfere with other operations.| Average |
+| Health probe status(DIP availability) |  Public and internal load balancer | Standard Load Balancer uses a distributed health-probing service that monitors your application endpoint's health according to your configuration settings. This metric provides an aggregate or per-endpoint filtered view of each instance endpoint in the load balancer pool. You can see how Load Balancer views the health of your application, as indicated by your health probe configuration. |  Average |
 | SYN (synchronize) packets |  Public load balancer | Standard Load Balancer does not terminate Transmission Control Protocol (TCP) connections or interact with TCP or UDP packet flows. Flows and their handshakes are always between the source and the VM instance. To better troubleshoot your TCP protocol scenarios, you can make use of SYN packets counters to understand how many TCP connection attempts are made. The metric reports the number of TCP SYN packets that were received.| Average |
 | SNAT connections |  Public Load Balancer |Standard Load Balancer reports the number of outbound flows that are masqueraded to the Public IP address front end. Source network address translation (SNAT) ports are an exhaustible resource. This metric can give an indication of how heavily your application is relying on SNAT for outbound originated flows. Counters for successful and failed outbound SNAT flows are reported and can be used to troubleshoot and understand the health of your outbound flows.| Average |
 | Byte counters |  Public and internal load balancer | Standard Load Balancer reports the data processed per front end.| Average |
 | Packet counters |  Public and internal load balancer | Standard Load Balancer reports the packets processed per front end.| Average |
 
 ### View your load balancer metrics in the Azure portal
 
-The Azure portal exposes the load balancer metrics via the Metrics (preview) page, which is available on both the load balancer resource page for a particular resource and the Azure Monitor page. 
+The Azure portal exposes the load balancer metrics via the Metrics page, which is available on both the load balancer resource page for a particular resource and the Azure Monitor page. 
 
 To view the metrics for your Standard Load Balancer resources:
-1. Go to the Metrics (preview) page and do either of the following:
+1. Go to the Metrics page and do either of the following:
    * On the load balancer resource page, select the metric type in the drop-down list.
    * On the Azure Monitor page, select the load balancer resource.
 2. Set the appropriate aggregation type.
 3. Optionally, configure the required filtering and grouping.
 
-![Metrics preview for Standard Load Balancer](./media/load-balancer-standard-diagnostics/LBMetrics1.png)
+    ![Metrics for Standard Load Balancer](./media/load-balancer-standard-diagnostics/lbmetrics1anew.png)
 
-*Figure: DIP availability and health probe status metric for Standard Load Balancer*
+    *Figure: Data Path Availability metric for Standard Load Balancer*
 
 ### Retrieve multi-dimensional metrics programmatically via APIs
 
@@ -67,15 +67,15 @@ The VIP availability metric describes the health of the data path within the reg
 - Dig deeper and understand whether the platform on which your service is deployed is healthy or whether your guest OS or application instance is healthy.
 - Isolate whether an event is related to your service or the underlying data plane. Do not confuse this metric with the health probe status ("DIP availability").
 
-To get the VIP availability for your Standard Load Balancer resources:
+To get the Data Path Availability for your Standard Load Balancer resources:
 1. Make sure the correct load balancer resource is selected. 
-2. In the **Metric** drop-down list, select **VIP Availability**. 
+2. In the **Metric** drop-down list, select **Data Path Availability**. 
 3. In the **Aggregation** drop-down list, select **Avg**. 
-4. Additionally, add a filter on the VIP address or VIP port as the dimension with the required front-end IP address or front-end port, and then group them by the selected dimension.
+4. Additionally, add a filter on the Frontend IP address or Frontend port as the dimension with the required front-end IP address or front-end port, and then group them by the selected dimension.
 
 ![VIP probing](./media/load-balancer-standard-diagnostics/LBMetrics-VIPProbing.png)
 
-*Figure: Load Balancer VIP probing details*
+*Figure: Load Balancer Frontend probing details*
 
 The metric is generated by an active, in-band measurement. A probing service within the region originates traffic for the measurement. The service is activated as soon as you create a deployment with a public front end, and it continues until you remove the front end. 
 
@@ -88,21 +88,17 @@ VIP availability fails for the following reasons:
 - Your deployment has no healthy VMs remaining in the back-end pool. 
 - An infrastructure outage has occurred.
 
-For diagnostic purposes, you can use the [VIP availability metric together with the health probe status](#vipavailabilityandhealthprobes).
+For diagnostic purposes, you can use the [Data Path Availability metric together with the health probe status](#vipavailabilityandhealthprobes).
 
 Use **Average** as the aggregation for most scenarios.
 
 #### Are the back-end instances for my VIP responding to probes?
 
 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.
 
-To get the DIP availability for your Standard Load Balancer resources:
-1. Select the **DIP Availability** metric with **Avg** aggregation type. 
-2. Apply a filter on the required VIP IP address or port (or both).
-
-![DIP availability](./media/load-balancer-standard-diagnostics/LBMetrics-DIPAvailability.png)
-
-*Figure: Load Balancer VIP availability*
+To get the health probe status for your Standard Load Balancer resources:
+1. Select the **Health Probe Status** metric with **Avg** aggregation type. 
+2. Apply a filter on the required Frontend IP address or port (or both).
 
 Health probes fail for the following reasons:
 - You configure a health probe to a port that is not listening or not responding or is using the wrong protocol. If your service is using direct server return (DSR, or floating IP) rules, make sure that the service is listening on the IP address of the NIC's IP configuration and not just on the loopback that's configured with the front-end IP address.
@@ -160,13 +156,13 @@ You can use health probe metrics to understand how Azure views the health of you
 
 You can take it a step further and use VIP availability metrics to gain insight into how Azure views the health of the underlying data plane that's responsible for your specific deployment. When you combine both metrics, you can isolate where the fault might be, as illustrated in this example:
 
-![VIP diagnostics](./media/load-balancer-standard-diagnostics/LBMetrics-DIPnVIPAvailability.png)
+![Combining Data Path Availability and Health Probe Status metrics](./media/load-balancer-standard-diagnostics/lbmetrics-dipnvipavailability-2bnew.png)
 
-*Figure: Combining DIP and VIP availability metrics*
+*Figure: Combining Data Path Availability and Health Probe Status metrics*
 
 The chart displays the following information:
-- The infrastructure itself was healthy, the infrastructure hosting your VMs was reachable, and more than one VM was placed in the back end. This information is indicated by the blue trace for VIP availability, which is 100 percent. 
-- However, the health probe status (DIP availability) is at 0 percent at the beginning of the chart, as indicated by the orange trace. The circled area in green highlights where the status (DIP availability) became healthy, and at which point the customer's deployment was able to accept new flows.
+- The infrastructure hosting your VMs was unavailable and at 0 percent at the beginning of the chart. Later, the infrastructure was healthy and the VMs were reachable, and more than one VM was placed in the back end. This information is indicated by the blue trace for data path availability (VIP availability), which was later at 100 percent. 
+- The health probe status (DIP availability), indicated by the purple trace, is at 0 percent at the beginning of the chart. The circled area in green highlights where the health probe status (DIP availability) became healthy, and at which point the customer's deployment was able to accept new flows.
 
 The chart allows customers to troubleshoot the deployment on their own without having to guess or ask support whether other issues are occurring. The service was unavailable because health probes were failing due to either a misconfiguration or a failed application.