監視 Azure 應用程式閘道時的參考資料
如需收集和分析 Azure 應用程式閘道監視資料的詳細資料，請參閱監視 Azure 應用程式閘道。
應用程式閘道 v2 計量
資源提供者與類型：Microsoft.Network/applicationGateways
計時計量
應用程式閘道提供數個與要求和回應相關的內建計時計量，這些計量的測量都是以毫秒為單位。
注意
如果應用程式閘道中有多個接聽程式，則一律依「接聽程式」維度進行篩選，同時比較不同的延遲計量，以取得有意義的推斷。
| 計量 | 單位 | 描述 |
|---|---|---|
| 後端連線時間 | 毫秒 | 與後端應用程式建立連線所花費的時間。 這包括網路延遲，以及後端伺服器 TCP 堆疊建立新連線所花費的時間。 如果是 TLS，也會包含交握時所花費的時間。 |
| 後端第一個位元組回應時間 | 毫秒 | 開始與後端伺服器建立連線，至接收到回應標頭第一個位元組的時間間隔。 這近似於下列時間的總和：後端連線時間、要求從應用程式閘道觸達後端所花費的時間、後端應用程式回應所花費的時間 (伺服器產生內容的時間，可能會擷取資料庫查詢)，以及第一個回應位元組從後端觸達應用程式閘道所花費的時間。 |
| 後端最後位元組回應時間 | 毫秒 | 開始與後端伺服器建立連線，至接收到回應主體最後一個位元組的時間間隔。 這近似於後端第一個位元組回應時間和資料傳輸時間的總和。 因為所要求的物件大小和伺服器網路的延遲不同，此數目可能會有極大的差異。 |
| 應用程式閘道總時間 | 毫秒 | 接收、處理要求並傳送其回應所花費的平均時間。 此值是指應用程式閘道收到 HTTP 要求的第一個位元組，到將最後一個回應位元組傳送至用戶端時的時間間隔。 這包括應用程式閘道所花費的處理時間、後端最後一個位元組回應時間，以及應用程式閘道傳送所有回應及用戶端 RTT 所花費的時間。 |
| 用戶端 RTT | 毫秒 | 用戶端與應用程式閘道之間的平均來回行程時間。 |
這些計量可用來判斷觀察到速度變慢的原因是用戶端網路、應用程式閘道效能、後端網路和後端伺服器 TCP 堆疊飽和度、後端應用程式效能或大型檔案大小。
例如，如果「後端第一個位元組回應時間」趨勢有尖峰，但「後端連線時間」趨勢穩定，則可以推斷應用程式閘道到後端之間有延遲，但建立連線所需的時間則是固定的，而尖峰是因為後端應用程式的回應時間增加所造成。 另一方面來說，後端第一個位元組回應時間的尖峰與後端連線時間中的對應尖峰有關聯，則可以推斷，應用程式閘道和後端伺服器之間或後端伺服器 TCP 堆疊的網路已飽和。
如果您注意到後端最後一個位元組回應時間中的尖峰，但後端第一個位元組回應時間是固定的，則可以推斷，此尖峰是因為要求中的檔案較大所致。
同樣地，如果「應用程式閘道總時間」有尖峰，但「後端最後位元組回應時間」是固定的，則可能是應用程式閘道上有效能瓶頸，或用戶端與應用程式閘道之間有網路瓶頸。 此外，如果用戶端 RTT 也有對應的尖峰，則表示效能降低是因為用戶端與應用程式閘道之間的網路。
應用程式閘道計量
| 計量 | 單位 | 描述 |
|---|---|---|
| 接收的位元組數 | Bytes | 應用程式閘道從用戶端收到的位元組數。 (此計量僅考慮應用程式閘道觀察到的要求內容大小。其不包括資料傳輸，例如 TLS 標頭交涉、TCP/IP 封包標頭或重新傳輸。) |
| 傳送的位元組數 | Bytes | 應用程式閘道傳送至用戶端的位元組數。 (此計量僅考慮應用程式閘道所提供的回應內容大小。其不包括資料傳輸，例如 TCP/IP 封包標頭或重新傳輸。) |
| 用戶端 TLS 通訊協定 | 計數 | 由用戶端起始的 TLS 和非 TLS 要求數目，這些要求會建立與應用程式閘道的連線。 若要檢視 TLS 通訊協定散發，請依 TLS 通訊協定維度進行篩選。 |
| 目前的容量單位 | 計數 | 對流量進行負載平衡所耗用的容量單位元數目。 容量單位有三個決定要素：「計算單位」、「持續的連線數」和「輸送量」。 每個容量單位最多包含：一個「計算單位」或 2500 個「持續連線數」，或 2.22-Mbps 的「輸送量」。 |
| 目前的計算單位 | 計數 | 已耗用處理器容量的計數。 影響計算單位的因素包括 TLS 連線數/秒、URL 重寫計算，以及 WAF 規則處理。 |
| 目前的連線數 | 計數 | 從用戶端到應用程式閘道的作用中並行連線總數。 |
| 預估計費容量單位 | 計數 | 若使用 v2 SKU，則計價模式會以耗用量來驅動。 容量單位會測量固定成本和以耗用量計費的成本。 *預估計費容量單位表示用來預估計費的容量單位數。 這會以「目前容量單位數」(對流量進行負載平衡所需的容量單位) 和「固定計費容量單位」(持續佈建的最小容量單位) 之間的較大值進行計算。 |
| 失敗的要求 | 計數 | 應用程式閘道服務的具有 5xx 伺服器錯誤碼的要求數目。 這包括從應用程式閘道產生的 5xx 代碼，以及從後端產生的 5xx 代碼。 您可以進一步篩選要求計數，以顯示每個/特定後端集區-HTTP 設定組合的計數。 |
| 固定計費容量單位 | 計數 | 持續佈建的最小容量單位數目，其以應用程式閘道組態中最小縮放單位設定 (一個執行個體轉譯為 10 個容量單位) 為依據。 |
| 每秒的新連線數 | 計數 | 從用戶端到應用程式閘道，以及從應用程式閘道到後端成員的平均每秒新 TCP 連線數目。 |
| 回應狀態 | 狀態碼 | 應用程式閘道傳回的 HTTP 回應狀態。 回應狀態碼發佈可以進一步分類，以顯示回應 2xx、3xx、4xx 和 5xx 分類中的回應。 |
| 輸送量 | 位元組數/秒 | 應用程式閘道每秒已服務的位元組數目。 (此計量僅考慮應用程式閘道所提供的內容大小。其不包括資料傳輸，例如 TLS 標頭交涉、TCP/IP 封包標頭或重新傳輸。) |
| 要求總數 | 計數 | 應用程式閘道已服務的成功要求計數。 您可以進一步篩選要求計數，以顯示每個/特定後端集區-HTTP 設定組合的計數。 |
後端計量
| 計量 | 單位 | 描述 |
|---|---|---|
| 後端回應狀態 | 計數 | 後端傳回的 HTTP 回應狀態碼計數。 這不包括應用程式閘道所產生的任何回應碼。 回應狀態碼發佈可以進一步分類，以顯示回應 2xx、3xx、4xx 和 5xx 分類中的回應。 |
| 良好的主機計數 | 計數 | 健全狀態探查判斷狀況良好的後端數目。 您可以根據每個後端集區進行篩選，以顯示特定後端集區中狀況良好的主機數量。 |
| 狀況不良的主機計數 | 計數 | 健全狀態探查判斷狀況不良的後端數目。 您可以根據每個後端集區進行篩選，以顯示特定後端集區中狀況不良的主機數量。 |
| 每個健康情況主機每分鐘的要求數 | 計數 | 後端集區中每個狀況良好的成員在一分鐘內收到的要求平均數目。 使用 BackendPool HttpSettings 維度來指定後端集區。 |
應用程式閘道第 4 層 Proxy 監視
第 4 層計量
由於應用程式閘道現在提供第 4 層 Proxy 功能，因此有一些常見計量 (適用於第 7 層和第 4 層) 以及某些第 4 層特定計量。 下表描述所有計量都適用於第 4 層使用方式。
| 計量 | 描述 | 類型 | 維度 |
|---|---|---|---|
| 目前的連線數 | 使用中連線的數目：讀取、寫入或等待。 目前透過應用程式閘道建立的連線計數。 | 常見 | 無 |
| 每秒的新連線數 | 過去 1 分鐘內每秒處理的平均連線數目。 | 常見 | 無 |
| 輸送量 | 過去 1 分鐘的資料流程速率 (inBytes+ outBytes)。 | 常見 | 無 |
| 狀況良好的主機計數 | 狀況良好的後端主機數目。 | 常見 | BackendSettingsPool |
| 狀況不良的主機 | 狀況不良的後端主機數目。 | 常見 | BackendSettingsPool |
| ClientRTT | 用戶端與應用程式閘道之間的平均來回行程時間。 | 常見 | 接聽程式 |
| 後端連線時間 | 與後端伺服器建立連線所花費的時間。 | 常見 | Listener、BackendServer、BackendPool、BackendSetting |
| 後端第一個位元組回應時間 | 開始與後端伺服器建立連線，到接收資料第一個位元組的時間間隔 (與後端伺服器的處理時間相近)。 | 常見 | Listener、BackendServer、BackendPool、BackendHttpSetting* |
| 後端工作階段持續時間 | 後端連線的總時間。 新連線開始到終止的平均持續時間。 | 僅限 L4 | Listener、BackendServer、BackendPool、BackendHttpSetting* |
| 連線存留期 | 用戶端連線到應用程式閘道的總時間。 新連線開始到終止的平均持續時間 (以毫秒為單位)。 | 僅限 L4 | 接聽程式 |
* BackendHttpSetting 維度包含第 7 層和第 4 層後端設定。
第 4 層記錄
應用程式閘道的第 4 層 Proxy 會透過存取記錄來提供記錄資料。 只有在閘道的診斷設定中設定這些記錄時，才會產生和發佈記錄。
- 請參閱：Azure 監視器資源記錄的支援類別。
| 類別 | 資源記錄類別 |
|---|---|
| ResourceGroup | 應用程式閘道資源所屬的資源群組。 |
| SubscriptionId | 應用程式閘道資源的訂用帳戶識別碼。 |
| ResourceProvider | 對於應用程式閘道，這會是 MICROSOFT.NETWORK。 |
| 資源 | 應用程式閘道資源的名稱。 |
| ResourceType | 這會是 APPLICATIONGATEWAYS。 |
| ruleName | 為連線要求提供服務的路由規則名稱。 |
| instanceId | 處理要求的應用程式閘道執行個體。 |
| clientIP | 要求的原始 IP。 |
| receivedBytes | 從用戶端接收到閘道的資料 (以位元組為單位)。 |
| sentBytes | 從閘道傳送至用戶端的資料 (以位元組為單位)。 |
| listenerName | 與用戶端建立前端連線的接聽程式名稱。 |
| backendSettingName | 用於後端連線的後端設定名稱。 |
| backendPoolName | 從中選取目標伺服器以建立後端連線的後端集區名稱。 |
| protocol | TCP (不論其是 TCP 或 TLS，通訊協定值一律為 TCP)。 |
| sessionTime | 工作階段持續時間 (以秒為單位) (這適用於 client->appgw 工作階段) |
| upstreamSentBytes | 傳送至後端伺服器的資料 (以位元組為單位)。 |
| upstreamReceivedBytes | 從後端伺服器接收的資料 (以位元組為單位)。 |
| upstreamSessionTime | 工作階段持續時間 (以秒為單位) (這適用於 appgw->backend 工作階段) |
| sslCipher | 用於 TLS 通訊的加密套件 (適用於 TLS 通訊協定接聽程式)。 |
| sslProtocol | 使用的 SSL/TLS 通訊協定 (適用於 TLS 通訊協定接聽程式)。 |
| serverRouted | 流量路由傳送目標的後端伺服器 IP 和連接埠號碼。 |
| serverStatus | 200：工作階段已順利完成。 400：無法剖析用戶端資料。 500：內部伺服器錯誤。 502：閘道不正確。 例如，無法連線到上游伺服器時。 503：服務無法使用。 例如，如果存取受限於連線數目。 |
| ResourceId | 應用程式閘道資源 URI |
第 4 層後端健康情況
應用程式閘道的第 4 層 Proxy 提供透過入口網站和 REST API 監視後端集區中個別成員健康情況的功能。
REST API
如需擷取應用程式閘道後端健康情況的 API 呼叫詳細資料，請參閱應用程式閘道 - 後端健康情況。
範例要求：output POST https://management.azure.com/subscriptions/subid/resourceGroups/rg/providers/Microsoft.Network/ applicationGateways/appgw/backendhealth?api-version=2021-08-01 After
傳送這個 POST 要求之後，您應該會看到「HTTP 202 已接受」回應。 在回應標頭中，尋找 Location 標頭，並使用該 URL 傳送新的 GET 要求。
output GET https://management.azure.com/subscriptions/subid/providers/Microsoft.Network/locations/region-name/operationResults/GUID?api-version=2021-08-01
應用程式閘道 v1 計量
應用程式閘道計量
| 計量 | 單位 | 描述 |
|---|---|---|
| CPU 使用率 | Percent | 顯示配置給應用程式閘道的 CPU 使用量。 在正常情況下，CPU 使用量不應經常超過 90%，因為這可能會導致應用程式閘道背後的網站中出現延遲，並且會中斷用戶端體驗。 您可以藉由增加執行個體計數或移至較大的 SKU 大小 (或同時執行這兩種方式) 來修改應用程式閘道的設定，以間接控制或改善 CPU 使用率。 |
| 目前的連線數 | 計數 | 目前透過應用程式閘道建立的連線計數。 |
| 失敗的要求 | 計數 | 因連線問題而失敗的要求數目。 此計數包括因為超過「要求逾時」HTTP 設定而失敗的要求，以及因為應用程式閘道與後端之間的連線問題而失敗的要求。 此計數不包含失敗，因為沒有狀況良好的後端可供使用。 系統也不會將來自後端的 4xx 和 5xx 回應視為此計量的一部分。 |
| 回應狀態 | 狀態碼 | 應用程式閘道傳回的 HTTP 回應狀態。 回應狀態碼發佈可以進一步分類，以顯示回應 2xx、3xx、4xx 和 5xx 分類中的回應。 |
| 輸送量 | 位元組數/秒 | 應用程式閘道每秒已服務的位元組數目。 |
| 要求總數 | 計數 | 應用程式閘道已服務的成功要求計數。 您可以進一步篩選要求計數，以顯示每個/特定後端集區-HTTP 設定組合的計數。 |
| Web 應用程式防火牆封鎖的要求計數 | 計數 | WAF 封鎖的要求數目。 |
| Web 應用程式防火牆封鎖的要求散發 | 計數 | 已由 WAF 篩選並封鎖的要求數目，顯示每個/特定 WAF 規則群組或 WAF 規則識別碼組合的計數。 |
| Web 應用程式防火牆的規則散發總計 | 計數 | 每個特定 WAF 規則群組或 WAF 規則識別碼組合接收到的要求數目。 |
如需詳細資訊，請參閱 Azure 監視器中支援的所有平台計量清單。
計量維度
如需計量維度是什麼的詳細資訊，請參閱多維度計量。
Azure 應用程式閘道支援 Azure 監視器中部分計量的維度。 每項計量都包含一項說明，解釋該計量特別可用的維度。
資源記錄
本節列出您可以向 Azure 應用程式閘道收集的資源記錄類型。
如需參考，請參閱 Azure 監視器中支援的所有資源記錄類別類型清單。
注意
該效能記錄僅適用於 v1 SKU。 若使用 v2 SKU，請為效能資料使用應用程式閘道 v2 計量。
如需詳細資訊，請參閱應用程式閘道的後端健康情況和診斷記錄。
應用程式閘道
資源提供者與類型：Microsoft.Network/applicationGateways
| 類別 | 顯示名稱 | 資訊 |
|---|---|---|
| ActivityLog | 活動記錄檔 | 系統預設會收集活動記錄項目。 您可以使用 Azure 活動記錄 (之前稱為「作業記錄和稽核記錄」) 來檢視提交至您的 Azure 訂用帳戶的所有作業及其狀態。 |
| ApplicationGatewayAccessLog | 存取記錄檔 | 您可以使用此記錄來檢視應用程式閘道存取模式並分析重要資訊。 這包含呼叫者的 IP 位址、所要求的 URL、回應延遲、傳回碼，以及輸入和輸出位元組。每隔 60 秒會收集一次存取記錄。 此記錄檔包含每個應用程式閘道執行個體的一筆記錄。 應用程式閘道執行個體是由 instanceId 屬性識別。 |
| ApplicationGatewayPerformanceLog | 效能記錄檔 | 您可以使用此記錄來檢視應用程式閘道執行個體的執行情況。 此記錄會擷取每個執行個體的效能資訊，包括提供的要求總數、輸送量 (以位元組為單位)、提供的總要求數、失敗的要求計數、狀況良好和狀況不良的後端執行個體計數。 每隔 60 秒會收集一次效能記錄。 該效能記錄僅適用於 v1 SKU。 若使用 v2 SKU，請為效能資料使用應用程式閘道 v2 計量。 |
| ApplicationGatewayFirewallLog | 防火牆記錄檔 | 您可以使用此記錄，檢視透過應用程式閘道的偵測或防止模式 (依 Web 應用程式防火牆的設定) 所記錄的要求。 防火牆記錄每 60 秒收集一次。 |
Azure 監視器記錄資料表
本節參考與 Azure 應用程式閘道相關的所有 Azure 監視器記錄 Kusto 資料表，並且可供 Log Analytics 查詢。
| 資源類型 | 備註 |
|---|---|
| 應用程式閘道 | 包含 AzureActivity、AzureDiagnostics 以及 AzureMetrics |
如需所有 Azure 監視器記錄/Log Analytics 資料表的參考，請參閱 Azure 監視器記錄資料表參考。
診斷資料表
Azure 應用程式閘道使用 Azure 診斷資料表來儲存資源記錄資訊。 下列為相關資料行。
Azure 診斷
| 屬性 | 說明 |
|---|---|
| requestUri_s | 用戶端要求的 URI。 |
| 訊息 | 資訊訊息，例如「SQL 插入式攻擊」 |
| userAgent_s | 用戶端要求的使用者代理程式詳細資料 |
| ruleName_s | 用來處理此要求的要求路由規則 |
| httpMethod_s | 用戶端要求的 HTTP 方法 |
| instanceId_s | 用戶端要求路由至以供評估的 Appgw 執行個體 |
| httpVersion_s | 用戶端要求的 HTTP 版本 |
| clientIP_s | 發出要求的 IP |
| host_s | 用戶端要求的主機標頭 |
| requestQuery_s | 用戶端要求的查詢字串 |
| sslEnabled_s | 用戶端要求是否已啟用 SSL |
另請參閱
- 如需監視 Azure 應用程式閘道的說明，請參閱監視 Azure 應用程式閘道。
- 如需監視 Azure 資源的詳細資訊，請參閱使用 Azure 監視器來監視 Azure 資源。