CloudWatch Classic Load Balancer 的指標 - Elastic Load Balancing
Classic Load Balancer 指標Classic Load Balancer 的指標維度Classic Load Balancer 指標的統計資料 檢視負載平衡器的 CloudWatch 指標

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

CloudWatch Classic Load Balancer 的指標

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

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

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

如需 Amazon 的詳細資訊 CloudWatch，請參閱 Amazon CloudWatch 使用者指南 。

Classic Load Balancer 指標

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

指標 描述
BackendConnectionErrors

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

報告條件：有非零值

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

範例：假設您的負載平衡器在 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接聽程式】 不符合 7230 RFC 的請求數目。

報告條件：有非零值

統計資訊：最實用的統計資訊是 Sum。
HealthyHostCount

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

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

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

範例：假設您的負載平衡器在 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。請注意，Minimum、Maximum 及 Average 皆為 1。

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

【HTTP接聽程式】 負載平衡器產生的 HTTP 4XX 用戶端錯誤碼數目。請求的格式不正確或不完整時，會產生用戶端錯誤。

報告條件：有非零值

統計資訊：最實用的統計資訊是 Sum。請注意，Minimum、Maximum 及 Average 皆為 1。

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

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

報告條件：有非零值

統計資訊：最實用的統計資訊是 Sum。請注意，Minimum、Maximum 及 Average 皆為 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。請注意，Minimum、Maximum 與 Average 都會傳回 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。請注意，每個負載平衡器節點都會回報 Average、Minimum 及 Maximum，但通常不太有用。

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

正在等待路由至運作狀態良好的執行個體的請求 （HTTP接聽程式） 或連線 （TCP接聽程式） 總數。佇列的大小上限為 1,024。當佇列已滿，其他要求或連線將遭拒。如需詳細資訊，請參閱SpilloverCount。

報告條件：有非零值。

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

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

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

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

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

範例：請參閱 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

Application Load Balancer 使用的負載平衡器容量單位預估數量 （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執行個體請求統計資料。

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

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

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

百分位數指出資料集之某個值的相對位置。您可以指定任何百分位數，最多使用兩位小數 (例如，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

    • HTTP 2XXs — HTTPCode_Backend_2XX

    • HTTP 3XXs — HTTPCode_Backend_3XX

    • HTTP 4XXs — HTTPCode_Backend_4XX

    • HTTP 5XXs — HTTPCode_Backend_5XX

    • ELB HTTP 4XXs — HTTPCode_ELB_4XX

    • ELB HTTP 5XXs — HTTPCode_ELB_5XX

    • 預估處理的位元組 — EstimatedProcessedBytes

    • 預估ALB已耗用 LCUs — EstimatedALBConsumedLCUs

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

    • 預估ALB新連線計數 — EstimatedALBNewConnectionCount

使用 CloudWatch 主控台檢視指標

  1. 在 開啟 CloudWatch 主控台https://console.aws.amazon.com/cloudwatch/。

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

  3. 选择 ELB 命名空间。

  4. 執行以下任意一項：

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

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

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

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