Merge pull request #287315 from MJyot/main

prmerger-automator[bot] · web-flow · commit 1e77cc60544f · 2024-09-25T15:33:01.000Z
latency observed in the metric data attributing to publishing data after every 1 min interval
diff --git a/articles/application-gateway/application-gateway-metrics.md b/articles/application-gateway/application-gateway-metrics.md
@@ -30,6 +30,10 @@ Application Gateway provides several built‑in timing metrics related to the re
 >
 > If there is more than one listener in the Application Gateway, then always filter by *Listener* dimension while comparing different latency metrics in order to get meaningful inference.
 
+> [!NOTE]
+>
+> Latency might be observed in the metric data, as all metrics are aggregated at one-minute intervals. This latency may vary for different application gateway instances based on the metric start time.
+
 You can use timing metrics to determine whether the observed slowdown is due to the client network, Application Gateway performance, the backend network and backend server TCP stack saturation, backend application performance, or large file size. For more information, see [Timing metrics](monitor-application-gateway-reference.md#timing-metrics-for-application-gateway-v2-sku).
 
 For example, if there's a spike in *Backend first byte response time* trend but the *Backend connect time* trend is stable, you can infer that the application gateway to backend latency and the time taken to establish the connection is stable. The spike is caused due to an increase in the response time of backend application. On the other hand, if the spike in *Backend first byte response time* is associated with a corresponding spike in *Backend connect time*, you can deduce that either the network between Application Gateway and backend server or the backend server TCP stack has saturated.

Original file line number	Diff line number	Diff line change
`@@ -30,6 +30,10 @@ Application Gateway provides several built‑in timing metrics related to the re`
`30`	`30`	`>`
`31`	`31`	`> If there is more than one listener in the Application Gateway, then always filter by Listener dimension while comparing different latency metrics in order to get meaningful inference.`
`32`	`32`
	`33`	`+> [!NOTE]`
	`34`	`+>`
	`35`	`+> Latency might be observed in the metric data, as all metrics are aggregated at one-minute intervals. This latency may vary for different application gateway instances based on the metric start time.`
	`36`	`+`
`33`	`37`	`You can use timing metrics to determine whether the observed slowdown is due to the client network, Application Gateway performance, the backend network and backend server TCP stack saturation, backend application performance, or large file size. For more information, see [Timing metrics](monitor-application-gateway-reference.md#timing-metrics-for-application-gateway-v2-sku).`
`34`	`38`
`35`	`39`	For example, if there's a spike in Backend first byte response time trend but the Backend connect time trend is stable, you can infer that the application gateway to backend latency and the time taken to establish the connection is stable. The spike is caused due to an increase in the response time of backend application. On the other hand, if the spike in Backend first byte response time is associated with a corresponding spike in Backend connect time, you can deduce that either the network between Application Gateway and backend server or the backend server TCP stack has saturated.