Merge pull request #267542 from jaesoni/minor-corrections-l4

PMEds28 · web-flow · commit 5722745eb95a · 2024-02-28T11:12:42.000Z
Minor corrections l4
diff --git a/articles/application-gateway/application-gateway-diagnostics.md b/articles/application-gateway/application-gateway-diagnostics.md
@@ -6,7 +6,7 @@ services: application-gateway
 author: greg-lindsay
 ms.service: application-gateway
 ms.topic: article
-ms.date: 01/10/2024
+ms.date: 02/28/2024
 ms.author: greglin 
 ---
 
@@ -87,10 +87,13 @@ Azure generates the activity log by default. The logs are preserved for 90 days
 
 ### Access log
 
-The access log is generated only if you've enabled it on each Application Gateway instance, as detailed in the preceding steps. The data is stored in the storage account that you specified when you enabled the logging. Each access of Application Gateway is logged in JSON format as shown below. 
+The access log is generated only if you've enabled it on each Application Gateway instance, as detailed in the preceding steps. The data is stored in the storage account that you specified when you enabled the logging. Each access of Application Gateway is logged in JSON format as shown below.
 
 #### For Application Gateway and WAF v2 SKU
 
+> [!NOTE]
+> For TLS/TCP proxy related information, visit [data reference](monitor-application-gateway-reference.md#tlstcp-proxy-logs).
+
 |Value  |Description  |
 |---------|---------|
 |instanceId     | Application Gateway instance that served the request.        |
diff --git a/articles/application-gateway/application-gateway-faq.yml b/articles/application-gateway/application-gateway-faq.yml
@@ -6,7 +6,7 @@ metadata:
   author: greg-lindsay
   ms.service: application-gateway
   ms.topic: faq
-  ms.date: 02/26/2024
+  ms.date: 02/28/2024
   ms.author: greglin
   ms.custom: references_regions, devx-track-azurepowershell
 title: Frequently asked questions about Application Gateway
@@ -491,7 +491,7 @@ sections:
           > [!NOTE] 
           > You can't use any layer 4 properties for HTTP or HTTPS protocol settings.
 
-      - question: Can I use a TCP/TLS listener with an HTTP(S) backend betting?
+      - question: Can I map a TCP/TLS protocol listener with an HTTP(S) protocol Backend setting?
         answer: No. You can't cross-link Layer 4 and Layer 7 properties. Therefore, a routing rule will only allow you to link a Layer 4-type listener to a Layer 4-type Backend setting.
 
       - question: Can L7 and L4 properties have same names?
diff --git a/articles/application-gateway/application-gateway-metrics.md b/articles/application-gateway/application-gateway-metrics.md
@@ -15,6 +15,9 @@ Application Gateway publishes data points to [Azure Monitor](../azure-monitor/ov
 
 ## Metrics supported by Application Gateway V2 SKU
 
+> [!NOTE]
+> For TLS/TCP proxy related information, visit [data reference](monitor-application-gateway-reference.md#tlstcp-proxy-metrics).
+
 ### Timing metrics
 
 Application Gateway provides several built‑in timing metrics related to the request and response, which are all measured in milliseconds. 
diff --git a/articles/application-gateway/monitor-application-gateway-reference.md b/articles/application-gateway/monitor-application-gateway-reference.md
@@ -70,28 +70,47 @@ Similarly, if the *Application gateway total time* has a spike but the *Backend
 |**Unhealthy host count**|Count|The number of backends that are determined unhealthy by the health probe. You can filter on a per backend pool basis to show the number of unhealthy hosts in a specific backend pool.|
 |**Requests per minute per Healthy Host**|Count|The average number of requests received by each healthy member in a backend pool in a minute. Specify the backend pool using the *BackendPool HttpSettings* dimension.|
 
-## Application Gateway layer 4 proxy monitoring 
+### Backend health API
 
-### Layer 4 metrics
+See [Application Gateways - Backend Health](/rest/api/application-gateway/application-gateways/backend-health?tabs=HTTP) for details of the API call to retrieve the backend health of an application gateway.
+
+Sample Request:
+``output
+POST
+https://management.azure.com/subscriptions/subid/resourceGroups/rg/providers/Microsoft.Network/
+applicationGateways/appgw/backendhealth?api-version=2021-08-01
+After
+``
+
+After sending this POST request, you should see an HTTP 202 Accepted response. In the response headers, find the Location header and send a new GET request using that URL.
+
+``output
+GET
+https://management.azure.com/subscriptions/subid/providers/Microsoft.Network/locations/region-name/operationResults/GUID?api-version=2021-08-01
+``
+
+### Application Gateway TLS/TCP proxy monitoring 
+
+#### TLS/TCP proxy metrics
 
 With layer 4 proxy feature now available with Application Gateway, there are some Common metrics (apply to both layer 7 as well as layer 4), and some layer 4 specific metrics. The following table describes all the metrics are the applicable for layer 4 usage.
 
 | Metric              | Description                                                                                                                            | Type   | Dimension |
 |:--------------------|:---------------------------------------------------------------------------------------------------------------------------------------|:-------|:----------|
-| Current Connections | The number of active connections: reading, writing, or waiting. The count of current connections established with Application Gateway. | Common | None      |
-| New Connections per second | The average number of connections handled per second in last 1 minute. | Common | None      |
-| Throughput | The rate of data flow (inBytes+ outBytes) in the last 1 minute. | Common | None      |
-| Healthy host count | The number of healthy backend hosts. | Common | BackendSettingsPool  |
-| Unhealthy host | The number of unhealthy backend hosts. | Common | BackendSettingsPool  |
-| ClientRTT | Average round trip time between clients and Application Gateway. | Common | Listener  |
-| Backend Connect Time | Time spent establishing a connection with a backend server. | Common | Listener, BackendServer, BackendPool, BackendSetting |
-| Backend First Byte Response Time | Time interval between start of establishing a connection to backend server and receiving the first byte of data (approximating processing time of backend server). | Common | Listener, BackendServer, BackendPool, BackendHttpSetting`*`  |
-| Backend Session Duration | The total time of a backend connection. The average time duration from the start of a new connection to its termination. | L4 only | Listener, BackendServer, BackendPool, BackendHttpSetting`*` |
-| Connection Lifetime | The total time of a client connection to application gateway. The average time duration from the start of a new connection to its termination in milliseconds. | L4 only | Listener |
+| Current Connections | The number of active connections: reading, writing, or waiting. The count of current connections established with Application Gateway. | Common metric | None      |
+| New Connections per second | The average number of connections handled per second during that minute. | Common metric | None      |
+| Throughput | The rate of data flow (inBytes+ outBytes) during that minute. | Common metric | None      |
+| Healthy host count | The number of healthy backend hosts. | Common metric | BackendSettingsPool  |
+| Unhealthy host | The number of unhealthy backend hosts. | Common metric | BackendSettingsPool  |
+| ClientRTT | Average round trip time between clients and Application Gateway. | Common metric | Listener  |
+| Backend Connect Time | Time spent establishing a connection with a backend server. | Common metric | Listener, BackendServer, BackendPool, BackendSetting |
+| Backend First Byte Response Time | Time interval between start of establishing a connection to backend server and receiving the first byte of data (approximating processing time of backend server). | Common metric | Listener, BackendServer, BackendPool, BackendHttpSetting`*`  |
+| Backend Session Duration | The total time of a backend connection. The average time duration from the start of a new connection to its termination. | L4-specific | Listener, BackendServer, BackendPool, BackendHttpSetting`*` |
+| Connection Lifetime | The total time of a client connection to application gateway. The average time duration from the start of a new connection to its termination in milliseconds. | L4-specific | Listener |
 
 `*` BackendHttpSetting dimension includes both layer 7 and layer 4 backend settings.
 
-### Layer 4 logs
+#### TLS/TCP proxy logs
 
 Application Gateway’s Layer 4 proxy provides log data through access logs. These logs are only generated and published if they are configured in the diagnostic settings of your gateway.
 - Also see: [Supported categories for Azure Monitor resource logs](/azure/azure-monitor/essentials/resource-logs-categories#microsoftnetworkapplicationgateways).
@@ -122,30 +141,13 @@ Application Gateway’s Layer 4 proxy provides log data through access logs. The
 | serverStatus |200 - session completed successfully. 400 - client data could not be parsed. 500 - internal server error. 502 - bad gateway. For example, when an upstream server could not be reached. 503 - service unavailable. For example, if access is limited by the number of connections. |
 | ResourceId |Application Gateway resource URI |
 
-### Layer 4 backend health
+### TLS/TCP proxy backend health
 
 Application Gateway’s layer 4 proxy provides the capability to monitor the health of individual members of the backend pools through the portal and REST API.
 
 ![Screenshot of backend health](./media/monitor-application-gateway-reference/backend-health.png) 
 
-### REST API
-
-See [Application Gateways - Backend Health](/rest/api/application-gateway/application-gateways/backend-health?tabs=HTTP) for details of the API call to retrieve the backend health of an application gateway.
 
-Sample Request:
-``output
-POST
-https://management.azure.com/subscriptions/subid/resourceGroups/rg/providers/Microsoft.Network/
-applicationGateways/appgw/backendhealth?api-version=2021-08-01
-After
-``
-
-After sending this POST request, you should see an HTTP 202 Accepted response. In the response headers, find the Location header and send a new GET request using that URL.
-
-``output
-GET
-https://management.azure.com/subscriptions/subid/providers/Microsoft.Network/locations/region-name/operationResults/GUID?api-version=2021-08-01
-``
 
 ## Application Gateway v1 metrics
 
diff --git a/articles/application-gateway/multiple-site-overview.md b/articles/application-gateway/multiple-site-overview.md
@@ -4,7 +4,7 @@ description: This article provides an overview of the Azure Application Gateway
 services: application-gateway
 author: greg-lindsay
 ms.service: application-gateway
-ms.date: 02/26/2024
+ms.date: 02/28/2024
 ms.author: greglin
 ms.topic: conceptual
 ---
@@ -89,18 +89,9 @@ In the Azure portal, under the multi-site listener, you must choose the **Multip
 
 See [create multi-site using Azure PowerShell](tutorial-multiple-sites-powershell.md) or [using Azure CLI](tutorial-multiple-sites-cli.md) for the step-by-step guide on how to configure wildcard host names in a multi-site listener.
 
-## Multi-site listeners for Application Gateway layer 4 proxy
+## Multi-site listener for TLS and TCP protocol listeners
 
-Multi-site hosting enables you to configure more than one backend TLS or TCP-based application on the same port of application gateway. This can be achieved by using TLS listeners only. This allows you to configure a more efficient topology for your deployments by adding multiple backend applications on the same port using single application gateway. The traffic for each application can be directed to its own backend pool by providing domain names in the TLS listener.
-
-For example, you can create three multisite listeners each with its own domain (contoso.com, fabrikam.com, and *.adatum.com), and route them to their respective backend pools having different applications. All three domains must point to the frontend IP address of the application gateway. This feature is in preview phase for use with layer 4 proxy.
-
-### Feature information:
-
-- Multi-site listener allows you to add listeners using the same port number.
-- For multisite TLS listeners, Application Gateway uses the Server Name Indication (SNI) value. SNI is primarily used to present clients with the domain server certificate and route a connection to the appropriate backend pool. This is done by picking the common name in TLS handshake data of an incoming connection.
-- Application Gateway allows domain-based routing using multisite TLS listener. You can use wildcard characters like asterisk (*) and question mark (?) in the host name, and up to 5 domains per multi-site TLS listener. For example, *.contoso.com.
-- The TCP connection inherently has no concept of hostname or domain name. Hence, with Layer 4 proxy the multisite listener isn't supported for TCP listeners.
+The multi-site feature is also available for Layer4 proxy, but only for its TLS listeners. You can direct the traffic for each application to its backend pool by providing domain names in the TLS listener. For the functioning of the multisite feature on TLS listeners, Application Gateway uses the Server Name Indication (SNI) value (the clients primarily present SNI extension to fetch the correct TLS certificate). A multisite TLS listener would pick this SNI value from the TLS handshake data of an incoming connection and route that connection to the appropriate backend pool. The TCP connection inherently has no concept of hostname or domain name; hence, this isn't available for TCP listeners.
 
 ## Host headers and Server Name Indication (SNI)
 
