

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

# Classic Load Balancer 的 CloudWatch 指標
<a name="elb-cloudwatch-metrics"></a>

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

您可以使用指標來確認系統的運作符合預期。例如，若指標超過您認為能夠接受的範圍，您可以建立 CloudWatch 警示來監控指定的指標並執行動作 (例如傳送通知到電子郵件地址)。

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

如需 Amazon CloudWatch 的詳細資訊，請參閱 *[Amazon CloudWatch 使用者指南](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/)*。

**Topics**
+ [Classic Load Balancer 指標](#loadbalancing-metrics-clb)
+ [Classic Load Balancer 的指標維度](#load-balancer-metric-dimensions-clb)
+ [Classic Load Balancer 指標的統計資料](#measure-stats)
+ [檢視負載平衡器的 CloudWatch 指標](#ViewingDataUsingCloudWatch)

## Classic Load Balancer 指標
<a name="loadbalancing-metrics-clb"></a>

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


| 指標 | Description | 
| --- | --- | 
| 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\$1NonCompliant\$1Request\$1Count |  [HTTP 接聽程式] 不符合 RFC 7230 的請求數量。 **報告條件**：有非零值 **統計資訊**：最實用的統計資訊是 `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\$1ELB\$14XX |  [HTTP 接聽程式] 負載平衡器產生的 HTTP 4XX 用戶端錯誤碼數目。請求的格式不正確或不完整時，會產生用戶端錯誤。 **報告條件**：有非零值 **統計資訊**：最實用的統計資訊是 `Sum`。請注意，`Minimum`、`Maximum` 及 `Average` 皆為 1。 **範例**：假設您的負載平衡器已啟用 us-west-2a 與 us-west-2b，而用戶端請求中包含格式不正確的請求 URL。因此，所有可用區域中的用戶端錯誤可能會增加。負載平衡器的總和為可用區域的值的總和。  | 
| HTTPCode\$1ELB\$15XX |  [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`。  | 

<a name="estimated-metrics"></a>如果您將 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](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/migrate-classic-load-balancer.html)。


| 指標 | Description | 
| --- | --- | 
| EstimatedALBActiveConnectionCount |  從用戶端到負載平衡器以及從負載平衡器到目標的並行作用中 TCP 連線估計數量。  | 
| EstimatedALBConsumedLCUs |  Application Load Balancer 所使用的負載平衡器容量單位 (LCU) 估計數量。您需要按每小時使用的 LCU 數目付費。如需詳細資訊，請參閱「[Elastic Load Balancing 定價](https://aws.amazon.com/elasticloadbalancing/pricing/)」。  | 
| EstimatedALBNewConnectionCount |  從用戶端到負載平衡器以及從負載平衡器到目標建立的新 TCP 連線估計數量。  | 
| EstimatedProcessedBytes |  Application Load Balancer 處理的位元組估計數量。  | 

## Classic Load Balancer 的指標維度
<a name="load-balancer-metric-dimensions-clb"></a>

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


|  維度  |  Description  | 
| --- | --- | 
|  AvailabilityZone  |  依指定的可用區域篩選指標資料。  | 
|  LoadBalancerName  |  依指定的負載平衡器篩選指標資料。  | 

## Classic Load Balancer 指標的統計資料
<a name="measure-stats"></a>

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 警示，將目標訂為處理時間超過 2 毫秒的請求不超過 1%。

## 檢視負載平衡器的 CloudWatch 指標
<a name="ViewingDataUsingCloudWatch"></a>

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

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

**使用 主控台檢視指標**

1. 前往 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) 開啟 Amazon EC2 主控台。

1. 在導覽窗格的 **Load Balancing (負載平衡器)**，選擇 **Load Balancer (負載平衡器)**。

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

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

1. 若要取得單一指標的詳細資訊，請將滑鼠游標暫留在其圖形上，然後選擇 `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 耗用 LCU — `EstimatedALBConsumedLCUs`
   + 預估 ALB 作用中連線計數 — `EstimatedALBActiveConnectionCount`
   + 預估 ALB 新連線計數 — `EstimatedALBNewConnectionCount`

**使用 CloudWatch 主控台檢視指標**

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

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

1. 選取 **ELB** 命名空間。

1. 執行以下任意一項：
   + 選取指標維度以透過負載平衡器、可用區域或跨所有負載平衡器檢視指標。
   + 若要檢視所有維度的指標，請在搜尋欄位中鍵入其名稱。
   + 若要檢視單一負載平衡器的指標，請在搜尋欄位中輸入其名稱。
   + 若要檢視單一可用區域的指標，請在搜尋欄位中輸入其名稱。