如何解決 Application Load Balancer 的 TargetResponseTime 指標增加的問題?

上次更新日期:2022 年 5 月 6 日

我發現 Application Load Balancer 的 TargetResponseTime 指標增加。該如何解決此問題?

簡短描述

TargetResponseTime 是指在要求離開負載平衡器與收到來自目標的回應之間經過的時間 (以秒為單位)。亦即 Application Load Balancer 存取記錄中的 target_processing_time 欄位。

TargetResponseTime 增加的可能原因包括:

  • 主機運作狀態不良。
  • 後端執行個體因要求過多而不堪負荷。
  • 後端執行個體的 CPU 使用率很高。
  • 一或多個目標裝置故障。
  • 在後端執行個體上執行的 Web 應用程式有相依性問題。

解決方案

主機運作狀態不良

確認所有 Application Load Balancer 目標裝置運作狀態良好。請參閱如何對 Application Load Balancer 的運作狀態檢查失敗進行疑難排解和修復?

後端執行個體因要求過多而不堪負荷

檢查 Amazon CloudWatch RequestCountSum (加總 ) 統計數字與 Application Load Balancer 的 ActiveConnectionCount 指標。若總和隨著 TargetResponseTime 增加,可能表示後端執行個體因要求過多而不堪負荷。

若要解決此問題,請為後端執行個體設定 Auto Scaling 群組。請參閱教學:設定擴展和負載平衡應用程式

後端執行個體的 CPU 使用率很高

檢查後端執行個體的 CloudWatch CPUUtilization 指標。如果 CPU 使用率很高或使用率激增,請將執行個體升級為較大的執行個體類型。

一或多個目標裝置故障

若裝置目標故障,請按照以下步驟解決問題:

1.    啟用負載平衡器的存取記錄功能

2.    當 TargetResponseTime 很高時下載時間範圍的存取記錄。例如,若要使用 AWS Command Line Interface (AWS CLI) 下載 2022-02-01T03:00 至 2022-02-01T03:35 之間的存取記錄,請:

aws s3 cp s3://bucket-name[/prefix]/AWSLogs/aws-account-id/elasticloadbalancing/region/2022/02/01/ ./alblogs --recursive --exclude "*" --include "*20220201T03[0123]*”

注意:bucket-name 換成儲存貯體的名稱,將 aws-account id 換成您的 AWS 帳戶 ID,並將 region (區域)換成您帳戶所在的 AWS 區域。

3.    使用命令列工具來分析存取記錄:

彈性負載平衡 (ELB) 存取記錄會壓縮成 .gzip 格式。

選用步驟:若要擷取記錄檔,請使用下列命令:

$   gzip -dr ./alblogs

範例案例

若要取得 target_processing_time 的最長延遲時間,請執行下列命令。

壓縮的記錄檔:

$zcat *.log.gz | awk '$7 != -1' | awk 'BEGIN{a=0}{if ($7>0+a) a=$7} END{print a}'

未壓縮的記錄檔:

$cat *.log.gz | awk '$7 != -1' | awk 'BEGIN{a=0}{if ($7>0+a) a=$7} END{print a}'

-或-

若要計算 target_processing_time ">=N" 秒的每個目標發出的要求數,請將 N 修改成您需要的秒數。

壓縮記錄檔的命令範例:

$zcat *.log.gz | awk '{if($7 >= N){print $5}}' | sort | uniq -c

未壓縮記錄檔的命令範例:

$cat *.log.gz | awk '{if($7 >= N){print $5}}' | sort | uniq -c

輸出結果範例:

12 10.10.20.111:80 
12 10.10.60.163:80
254 10.10.70.7:80
6 10.10.80.109:80
20656 10.3.19.141:80

在上述範例中,TargetResponseTime 增加主要是因為 IP 地址為 10.3.19.141 的目標裝置 。在此情況下,請檢查目標裝置的作業系統 (OS) 和 Web 應用程式。

在後端執行個體上執行的 Web 應用程式有相依性問題

在目標裝置上執行封包擷取,以確認目標裝置回應延遲的原因。若使用 Linux 作業系統,請使用 tcpdump

若要擷取完整的傳入和傳出 POST HTTP 傳輸 (包括連接埠 TCP/80 上的 HTTP 要求和回應),請:

tcpdump -i any -ns 0 -A 'tcp dst port 80 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504F5354 or tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x48545450 or tcp[((tcp[12:1]& 0xf0) >> 2):4] = 0x3C21444F'

若要擷取完整的傳入和傳出 GET HTTP 傳輸 (包括連接埠 TCP/80 上的 HTTP 要求和回應),請:

tcpdump -i any -ns 0 -A 'tcp dst port 80 and tcp[((tcp[12:1]& 0xf0) >> 2):4] = 0x47455420 or tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x48545450 or tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x3C21444F'

輸出結果範例:

14:04:12.186593 IP 10.10.30.219.13000 > 10.10.60.10.http: Flags [P.], seq 641705534:641705793, ack 1587610435, win 106, options [nop,nop,TS val 1165674323 ecr 263805247],
    length 259: HTTP: GET / HTTP/1.1 E..7."@...I. .. < 2..P&?.>^..C...j9...... Ez.S..Y?GET / HTTP/1.1 X-Forwarded-For: 54.66.76.204 X-Forwarded-Proto: http X-Forwarded-Port: 80 Host: labalbinternet-1236602672.ap-southeast-2.elb.amazonaws.com
    X-Amzn-Trace-Id: Root=1-6254355c-15db4904726649b66a1e47d7 User-Agent: curl/7.79.1 Accept: */* ................
14:04:21.187892 IP 10.10.60.10.http > 10.10.30.219.13000: Flags [P.], seq 1:592, ack 259, win 488, options [nop,nop,TS val 263814250
    ecr 1165674323], length 591: HTTP: HTTP/1.1 200 OK E...\.@.@.l. < ...P2.^..C&?.A....qn..... ..|jEz.SHTTP/1.1 200 OK Date: Mon, 11 Apr 2022 14:04:12 GMT Server: Apache/2.4.52 () OpenSSL/1.0.2k-fips X-Powered-By: PHP/7.2.34 Upgrade: h2,h2c
    Connection: Upgrade Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 159 PHP file name: /index.php<br> ................

注意:在上述輸出結果範例中,GET HTTP 在 14:04:12 回應,而目標裝置在 14:04:21 回應。TargetResponseTime 約為 9 秒。使用 X-Amzn-Trace-Id: Root 可在存取記錄中追蹤此記錄。

壓縮記錄檔的命令範例:

$zcat *.log.gz | awk '{if($20 ~ "1-6254355c-15db4904726649b66a1e47d7"){print $6,$7,$8 }}'

未壓縮記錄檔的命令範例:

$cat *.log.gz | awk '{if($20 ~ "1-6254355c-15db4904726649b66a1e47d7"){print $6,$7,$8 }}'

輸出結果範例:

0.008 9.002 0.000

此文章是否有幫助?


您是否需要帳單或技術支援?