CloudWatch Classic Load Balancer 的指標 - Elastic Load Balancing

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

CloudWatch Classic Load Balancer 的指標

Elastic Load Balancing 會 CloudWatch 針對負載平衡器和後端執行個體將資料點發佈至 Amazon。CloudWatch 可讓您擷取有關這些資料點的統計資料,做為一組排序的時間序列資料 (稱為指標)。您可以將指標視為要監控的變數,且資料點是該變數在不同時間點的值。例如,您可以監視負載平衡器在指定期間內運作良好的EC2執行個體總數。每個資料點都有關聯的時間戳記和可選的測量單位。

您可以使用指標來確認系統的運作符合預期。例如,如果指標超出您認為可接受的範圍,您可以建立 CloudWatch 警示來監控指定的指標並啟動動作 (例如傳送通知至電子郵件地址)。

CloudWatch 只有在要求流經負載平衡器時,「Elastic Load Balancing」才會將度量報告給。如果有請求進出負載平衡器,Elastic Load Balancing 會以 60 秒為間隔來測量並傳送其指標。如果沒有請求流經負載平衡器,或者指標沒有資料,則不會回報該指標。

有關 Amazon 的更多信息 CloudWatch,請參閱 Amazon CloudWatch 用戶指南

Classic Load Balancer 指標

AWS/ELB 命名空間包含下列指標。

指標 描述
BackendConnectionErrors

負載平衡器與註冊執行個體之間未成功建立的連線數目。由於發生錯誤時,負載平衡器會重試連線,此計數可能會超過請求率。請注意,此計數亦包含與運作狀態檢查有關的任何連線錯誤。

報告條件:有非零值

統計資訊:最實用的統計資訊是 Sum。請注意,每個負載平衡器節點都會回報 AverageMinimumMaximum,但通常不太有用。但是,最小值與最大值 (或峰值與平均值,或平均值與傳輸量) 之間的差異,對於判斷負載平衡器節點是否為異常值是有用的。

範例:假設您的負載平衡器在 us-west-2a 有 2 個執行個體,在 us-west-2b 有 2 個執行個體,而嘗試連線至 us-west-2a 的 1 個執行個體發生後端連線錯誤。us-west-2a 的總和包括這些連線錯誤,而 us-west-2b 的總和則不包含。因此,負載平衡器的總和等於 us-west-2a 的總和。

DesyncMitigationMode_NonCompliant_Request_Count

[HTTP監聽程式] 不符合 RFC 7230 的要求數目。

報告條件:有非零值

統計資訊:最實用的統計資訊是 Sum

HealthyHostCount

已向您的負載平衡器註冊的正常狀態執行個體的數量。通過第一次運作狀態檢查之後,新註冊的執行個體將被視為狀態正常。如果已啟用跨區域負載平衡,LoadBalancerName 維度的正常狀態執行個體的數量將以所有可用區域計算。否則將以每個可用區域計算。

報告條件:有已註冊的執行個體

統計資訊:最實用的統計資訊是 AverageMaximum。這些統計資訊由負載平衡器節點決定。請注意,有些負載平衡器節點可能會短暫判斷某執行個體狀態不良,同時其他節點則判斷該執行個體為狀態正常。

範例:假設您的負載平衡器在 us-west-2a 有 2 個執行個體,在 us-west-2b 有 2 個執行個體,us-west-2a 有 1 個執行個體狀態不良,而 us-west-2b 沒有狀態不良的執行個體。使用 AvailabilityZone 維度時,us-west-2a 平均有 1 個狀態正常與 1 個狀態不良的執行個體,us-west-2b 平均有 2 個狀態正常與 0 個狀態不良的執行個體。

HTTPCode_Backend_2XX, HTTPCode_Backend_3XX, HTTPCode_Backend_4XX, HTTPCode_Backend_5XX

[HTTP偵聽程式] 已註冊執行個體所產生的HTTP回應碼數目。此計數不包含負載平衡器產生的任何回應碼。

報告條件:有非零值

統計資訊:最實用的統計資訊是 Sum。請注意,MinimumMaximumAverage 皆為 1。

範例:假設您的負載平衡器在 US-西 2a 中有 2 個執行個體,在 US-西 2b 中有 2 個執行個體,而在 US-西 2a 中傳送至 1 個執行個體的請求會產生 500 個回應。HTTPus-west-2a 的總和包括這些錯誤回應,而 us-west-2b 的總和則不包含。因此,負載平衡器的總和等於 us-west-2a 的總和。

HTTPCode_ELB_4XX

[HTTP偵聽程式] 負載平衡器所產生的 HTTP 4XX 用戶端錯誤碼數目。請求的格式不正確或不完整時,會產生用戶端錯誤。

報告條件:有非零值

統計資訊:最實用的統計資訊是 Sum。請注意,MinimumMaximumAverage 皆為 1。

範例:假設您的負載平衡器已啟用 us-West-2a 和 us-west-2b,而且用戶端要求包含格式錯誤的要求。URL因此,所有可用區域中的用戶端錯誤可能會增加。負載平衡器的總和為可用區域的值的總和。

HTTPCode_ELB_5XX

[HTTP偵聽程式] 負載平衡器產生的 HTTP 5XX 伺服器錯誤碼數目。此計數不包含註冊執行個體產生的任何回應碼。如果沒有狀態正常的執行個體向負載平衡器註冊,或如果請求率超過執行個體 (溢出) 或負載平衡器的容量,將會回報此指標。

報告條件:有非零值

統計資訊:最實用的統計資訊是 Sum。請注意,MinimumMaximumAverage 皆為 1。

範例:假設您的負載平衡器已啟用 us-west-2a 與 us-west-2b,而 us-west-2a 中的執行個體出現高延遲,對請求的回應過慢。結果,us-west-2a 中的負載平衡器節點的突增佇列將會填入,用戶端將收到 503 錯誤。如果 us-west-2b 繼續正常回應,負載平衡器的總和等於 us-west-2a 的總和。

Latency

[HTTP偵聽程式] 從負載平衡器將要求傳送至已註冊執行個體直到執行個體開始傳送回應標頭為止,經過的總時間 (秒) 為單位。

[TCP偵聽程式] 負載平衡器成功建立連線至已註冊執行個體的總時間 (以秒為單位)。

報告條件:有非零值

統計資訊:最實用的統計資訊是 Average。使用 Maximum 判斷是否有些請求花費的時間大幅長於平均時間。請注意,Minimum 通常不太有用。

範例:假設您的負載平衡器在 us-west-2a 有 2 個執行個體,在 us-west-2b 有 2 個執行個體,而傳送請求至 us-west-2a 的 1 個執行個體時,有較高的延遲。us-west-2a 的平均值高於 us-west-2b 的平均值。

RequestCount

已完成的請求數量或在指定時間間隔 (1 或 5 分鐘) 內建立的連線數量。

[HTTP偵聽程式] 接收和路由的要求數目,包括來自已註冊執行個體的HTTP錯誤回應。

[TCP偵聽程式] 與已註冊執行個體建立的連線數目。

報告條件:有非零值

統計資訊:最實用的統計資訊是 Sum。請注意,MinimumMaximumAverage 都會傳回 1。

範例:假設您的負載平衡器在 us-west-2a 有 2 個執行個體,在 us-west-2b 有 2 個執行個體,並且有 100 個請求傳送至負載平衡器。有 60 個請求傳送至 us-west-2a,每個執行個體接收 30 個請求,有 40 個請求傳送至 us-west-2b,每個執行個體接收 20 個請求。使用 AvailabilityZone 維度,us-west-2a 總計有 60 個請求,us-west-2b 總計有 40 個請求。使用 LoadBalancerName 維度,總計有 100 個請求。

SpilloverCount

由於突增佇列已滿,導致請求遭拒的總數。

[HTTP接聽程式] 負載平衡器會傳回 HTTP 503 錯誤碼。

[TCP監聽器] 負載平衡器關閉連接。

報告條件:有非零值

統計資訊:最實用的統計資訊是 Sum。請注意,每個負載平衡器節點都會回報 AverageMinimumMaximum,但通常不太有用。

範例:假設您的負載平衡器已啟用 us-west-2a 與 us-west-2b,而 us-west-2a 中的執行個體出現高延遲,對請求的回應過慢。結果,us-west-2a 中的負載平衡器節點的突增佇列將會填入,導致溢出。如果 us-west-2b 繼續正常回應,負載平衡器的總和將與 us-west-2a 的總和相同。

SurgeQueueLength

擱置路由傳送至健全狀況良好之執行處理的要求 (HTTPTCP監聽器) 或連線 (監聽器) 總數。佇列的大小上限為 1,024。當佇列已滿,其他要求或連線將遭拒。如需詳細資訊,請參閱SpilloverCount

報告條件:有非零值。

統計資訊:最有用的統計資訊為 Maximum,因為它表示已排入佇列的請求峰值。Average 統計資訊與 MinimumMaximum 組合時比較有用,可供判斷已排入佇列的請求範圍。請注意,Sum 不太有用。

範例:假設您的負載平衡器已啟用 us-west-2a 與 us-west-2b,而 us-west-2a 中的執行個體出現高延遲,對請求的回應過慢。結果,us-west-2a 中的負載平衡器節點的突增佇列將會填入,用戶端可能會遇到回應時間拉長的情況。如果此情況持續發生,負載平衡器可能會溢出 (請參閱 SpilloverCount 指標)。如果 us-west-2b 繼續正常回應,負載平衡器的 max 將與 us-west-2a 的 max 相同。

UnHealthyHostCount

已向您的負載平衡器註冊的不良狀態執行個體的數量。在執行個體超過運作狀態檢查中所設定的不良閥值之後,執行個體將被視為狀態不良。在執行個體符合運作狀態檢查中所設定的正常閥值之後,狀態不良的執行個體將再次被視為狀態正常。

報告條件:有已註冊的執行個體

統計資訊:最實用的統計資訊是 AverageMinimum。這些統計資訊由負載平衡器節點決定。請注意,有些負載平衡器節點可能會短暫判斷某執行個體狀態不良,同時其他節點則判斷該執行個體為狀態正常。

範例:請參閱 HealthyHostCount

如果您將 Classic Load Balancer 移轉至 Application Load Balancer,以下指標可讓您估計成本。這些指標僅供參考用途,不適用於 CloudWatch 警示。請注意,如果您的 Classic Load Balancer 有多個接聽程式,這些指標將會彙整各個接聽程式。

這些估算依據負載平衡器而定,它有一個預設規則及 2K 大小的憑證。如果使用 4K 或更大的憑證,建議您以下列方式進行估算:使用遷移工具,以您的 Classic Load Balancer 為基礎建立 Application Load Balancer,並監控 Application Load Balancer 的 ConsumedLCUs 指標。如需詳細資訊,請參閱 Elastic Load Balancing 使用指南中的從 Classic Load Balancer 移轉至 Application Load Balancer

指標 描述
EstimatedALBActiveConnectionCount

從用戶端到負載平衡器,以及從負載平衡器到目標的作用中並行TCP連線的預估數目。

EstimatedALBConsumedLCUs

應用程式負載平衡器使用的預估負載平衡器容量單位 (LCU) 數目。您需要支付每小時LCUs使用的數量。如需詳細資訊,請參閱「Elastic Load Balancing 定價」。

EstimatedALBNewConnectionCount

從用戶端到負載平衡器,以及從負載平衡器到目標之間建立的新TCP連線預估數目。

EstimatedProcessedBytes

Application Load Balancer 處理的位元組估計數量。

Classic Load Balancer 的指標維度

若要篩選 Classic Load Balancer 的指標,請使用下列維度。

維度 描述
AvailabilityZone

依指定的可用區域篩選指標資料。

LoadBalancerName

依指定的負載平衡器篩選指標資料。

Classic Load Balancer 指標的統計資料

CloudWatch 根據「Elastic Load Balancing」公佈的測量結果資料點,提供統計資料。統計資料是隨著指定期間的指標資料彙總。當您請求統計資料時,傳回的資料流是藉由指標名稱和維度做識別。維度是用來單獨辨識指標的名稱/值組。例如,您可以針對在特定可用區域中啟動的負載平衡器後面的所有運作狀態良好的EC2執行個體要求統計資料。

MinimumMaximum 統計資料會反應由個別負載平衡器節點回報的最低與最高值。例如,假設有 2 個負載平衡器節點。一個節點有內含 Minimum 2、Maximum 10、Average 6 的 HealthyHostCount,而其他節點有內含 Minimum 1、Maximum 5、以及 Average 3 的 HealthyHostCount。因此,負載平衡器有 Minimum 1、Maximum 10、以及因為約為 4 的 Average

Sum 統計資料為來自所有負載平衡器節點的彙總值。因為指標包含各期間的多個報告,Sum 僅適用於彙總跨所有負載平衡器節點的指標,例如 RequestCountHTTPCode_ELB_XXXHTTPCode_Backend_XXXBackendConnectionErrorsSpilloverCount

SampleCount 統計資料為測量而得的範本數量。因指標根據範本間隔與事件蒐集而得,此統計資料通常沒有幫助。例如,使用 HealthyHostCountSampleCount 是根據每個負載平衡器節點回報的範本數量,而非運作狀態良好的主機數量。

百分位數指出資料集之某個值的相對位置。您可以指定任何百分位數,最多使用兩位小數 (例如,p95.45)。例如,第 95 個百分位數表示 95% 的資料低於這個值,而 5% 高於這個值。百分位數通常用於隔離異常。例如,假設應用程式以 1-2 毫秒處理快取中的大部分請求,但如果快取是空的,則是 100-200 毫秒。上限會反映最慢的情況,大約 200 毫秒。平均數不表示資料的分佈。百分位數以更有意義的觀點表達應用程式的效能。藉由使用第 99 個百分位數做為 Auto Scaling 觸發程序或 CloudWatch 警示,您可以指定不超過 1% 的要求需要超過 2 毫秒的時間。

CloudWatch 檢視負載平衡器的指標

您可以使用 Amazon EC2 主控台檢視負載平衡器的 CloudWatch 指標。這些指標會以監控圖表的形式顯示。若啟用負載平衡器並接收請求,監控圖表會顯示資料點。

或者,您可以使用 CloudWatch 主控台檢視負載平衡器的指標。

使用 主控台檢視指標
  1. 在打開 Amazon EC2 控制台https://console.aws.amazon.com/ec2/

  2. 在導覽窗格的 Load Balancing (負載平衡器),選擇 Load Balancer (負載平衡器)

  3. 選擇負載平衡器的名稱來開啟其詳細資訊頁面。

  4. 選擇 Monitoring (監控) 索引標籤。

  5. 若要取得單一指標的詳細資訊,請將滑鼠游標暫留在其圖形上,然後選擇 Maximize 圖示。下列指標可供使用:

    • 運作狀況良好主機 — HealthyHostCount

    • 運作狀況不良主機 — UnHealthyHostCount

    • 平均延遲 — Latency

    • 請求 — RequestCount

    • 後端連接錯誤 — BackendConnectionErrors

    • 突增佇列長度 — SurgeQueueLength

    • Spillover 計數 — SpilloverCount

    • HTTP2 XXs — HTTPCode_Backend_2XX

    • HTTP3 XXs — HTTPCode_Backend_3XX

    • HTTP4 XXs — HTTPCode_Backend_4XX

    • HTTP5 XXs — HTTPCode_Backend_5XX

    • ELBHTTP4 XXs — HTTPCode_ELB_4XX

    • ELBHTTP5 XXs — HTTPCode_ELB_5XX

    • 預估處理的位元組 — EstimatedProcessedBytes

    • 估計ALB消耗量 LCUs — EstimatedALBConsumedLCUs

    • 估計ALB作用中連線計數 — EstimatedALBActiveConnectionCount

    • 預估的ALB新連線計數 — EstimatedALBNewConnectionCount

使用 CloudWatch 主控台檢視指標
  1. 在開啟 CloudWatch 主控台https://console.aws.amazon.com/cloudwatch/

  2. 在導覽窗格中,選擇 指標

  3. 选择 ELB 命名空间。

  4. 執行以下任意一項:

    • 選取指標維度以透過負載平衡器、可用區域或跨所有負載平衡器檢視指標。

    • 若要檢視所有維度的指標,請在搜尋欄位中鍵入其名稱。

    • 若要檢視單一負載平衡器的指標,請在搜尋欄位中輸入其名稱。

    • 若要檢視單一可用區域的指標,請在搜尋欄位中輸入其名稱。