Classic Load Balancer の CloudWatch メトリクス

Elastic Load Balancing は、ロードバランサーとバックエンドインスタンス用として、データポイントを Amazon CloudWatch に発行します。CloudWatch では、それらのデータポイントについての統計を、(メトリクスと呼ばれる) 順序付けられた時系列データのセットとして取得できます。メトリクスは監視対象の変数、データポイントは時間の経過と共に変わる変数の値と考えることができます。例えば、指定した期間中のロードバランサーの正常な EC2 インスタンスの合計数を監視することができます。各データポイントには、タイムスタンプと、オプションの測定単位が関連付けられています。

メトリクスを使用して、システムが正常に実行されていることを確認できます。例えば、メトリクスが許容範囲外になる場合、CloudWatch アラームを作成して、指定されたメトリクスを監視し、アクション (E メールアドレスに通知を送信するなど) を開始することができます。

Elastic Load Balancing は、ロードバランサー経由でリクエストが伝達される場合にのみ、メトリクスを CloudWatch にレポートします。ロードバランサーを経由するリクエストがある場合、Elastic Load Balancing は 60 秒間隔でメトリクスを測定し、送信します。ロードバランサーを経由するリクエストがないか、メトリクスのデータがない場合、メトリクスは報告されません。

Amazon CloudWatch の詳細については、「Amazon CloudWatch ユーザーガイド」を参照してください。

Classic Load Balancer のメトリクス

AWS/ELB 名前空間には、次のメトリクスが含まれます。

メトリクス	説明
BackendConnectionErrors	ロードバランサーと登録されたインスタンス間で正常に確立されなかった接続数。エラーが発生すると、ロードバランサーは接続を再試行するため、このカウントはリクエストレートを上回ります。この数には、ヘルスチェックに関連する接続エラーも含まれます。 レポート条件: ゼロ以外の値がある 統計: 最も有用な統計は Sum です。Average、Minimum、Maximum はロードバランサーノードごとに報告されるため、通常有益ではありません。ただし、最大と最小の差 (ピーク値対平均、または平均対底値) は、1 つのロードバランサーノードが異常値かどうかを判断する上で有益な場合があります。 例: ロードバランサーにインスタンスがあり、そのうちの 2 つのインスタンスは us-west-2a に、もう 2 つのインスタンスは us-west-2b にあるとします。また、us-west-2a の 1 つのインスタンスへの接続を試みると、バックエンド接続エラーになるとします。us-west-2a の合計にはこれらの接続エラーが含まれますが、us-west-2b の合計には含まれません。このため、ロードバランサーの合計は us-west-2a の合計と同じになります。
DesyncMitigationMode_NonCompliant_Request_Count	[HTTP リスナー] RFC 7230 に準拠していないリクエストの数。 レポート条件: ゼロ以外の値がある 統計: 最も有用な統計は Sum です。
HealthyHostCount	ロードバランサーに登録された、正常なインスタンスの数。新しく登録されたインスタンスは、最初のヘルスチェックに合格すると、正常な状態と見なされます。クロスゾーンの負荷分散が有効な場合、すべてのアベイラビリティーゾーンにわたって LoadBalancerName ディメンションの正常なインスタンスの数が算出されます。それ以外の場合、アベイラビリティーゾーンごとに計算されます。 レポート要件: 登録されたインスタンスがある Statistics: 最も有用な統計は Average および Maximum です。これらの統計はロードバランサーノードによって決まります。短い間、インスタンスを異常と判断するロードバランサーノードがあったり、インスタンスを正常と判断するノードがあったりします。 例: ロードバランサーにインスタンスがあり、そのうちの 2 つのインスタンスは us-west-2a に、もう 2 つのインスタンスは us-west-2b にあるとします。また、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 です。 例: ロードバランサーにインスタンスがあり、そのうちの 2 つのインスタンスは us-west-2a に、もう 2 つのインスタンスは us-west-2b にあるとします。また、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 は有用ではありません。 例: ロードバランサーにインスタンスがあり、そのうちの 2 つのインスタンスは us-west-2a に、もう 2 つのインスタンスは us-west-2b にあるとします。また、us-west-2a の 1 つのインスタンスに送信されたリクエストのレイテンシーがより高いとします。us-west-2a の平均値は、us-west-2b の平均よりも高いとします。
RequestCount	指定された間隔 (1 分または 5 分) の間に完了したリクエストの数、または接続の数。 [HTTP リスナー] 登録されたインスタンスからの HTTP エラーレスポンスを含めて、受け取ったリクエストとルーティングされたリクエストの数。 [TCPリスナー] 登録されたインスタンスに対して行われた接続の数。 レポート条件: ゼロ以外の値がある 統計: 最も有用な統計は Sum です。Minimum、Maximum、および Average はすべて 1 を返すことに注意してください。 例: ロードバランサーにインスタンスがあり、そのうちの 2 つのインスタンスは us-west-2a に、もう 2 つのインスタンスは us-west-2b にあるとします。また、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	ロードバランサーに登録された、異常なインスタンスの数。インスタンスは、ヘルスチェックに対して構成された異常なしきい値を超えると、異常な状態と見なされます。異常なインスタンスは、ヘルスチェックに設定されている状態のしきい値を満たせば再び正常な状態と見なされます。 レポート要件: 登録されたインスタンスがある Statistics: 最も有用な統計は Average および Minimum です。これらの統計はロードバランサーノードによって決まります。短い間、インスタンスを異常と判断するロードバランサーノードがあったり、インスタンスを正常と判断するノードがあったりします。 例: HealthyHostCount を参照してください。

次のメトリクスを使用すると、Classic Load Balancer を Application Load Balancer に移行する場合のコストを見積もることができます。これらのメトリクスは、単なる情報提供を意図しており、CloudWatch アラームでの使用を目的にしていません。Classic Load Balancer に複数のリスナーがある場合、これらのメトリクスはすべてのリスナーを集計したものになります。

この見積りは、1 つのロードバランサーで 1 つのデフォルトルールと 1 つの証明書 (2K サイズ) を使用した場合に基づいています。サイズが 4K 以上の証明書を使用する場合にコストを見積もる方法としては、移行ツールを使用しながら Classic Load Balancer に基づいた Application Load Balancer を作成し、その Application Load Balancer で ConsumedLCUs メトリクスをモニタリングすることをお勧めします。詳細については、Elastic Load Balancing ユーザーガイドのClassic Load Balancer の移行を参照してください。

メトリクス	説明
EstimatedALBActiveConnectionCount	クライアントからロードバランサーへ、およびロードバランサーからターゲットへの、アクティブな同時 TCP 接続の予測数。
EstimatedALBConsumedLCUs	Application Load Balancer で使用されるロードバランサーキャパシティーユニット (LCU) の予測数。1 時間当たりで使用する LCU 数の料金をお支払いいただきます｡ 詳細については、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 つあるとします。一方のノードは、HealthyHostCount の Minimum が 2、Maximum が 10、Average が 6 で、もう一方のノードは HealthyHostCount の Minimum が 1、Maximum が 5、Average が 3 です。このため、ロードバランサーの Minimum は 1、Maximum は 10、Average は約 4 です。

Sum 統計は、すべてのロードバランサーノードにおける集計値です。メトリクスには期間あたり複数のレポートが含まれているため、Sum は、RequestCount、HTTPCode_ELB_XXX、HTTPCode_Backend_XXX、BackendConnectionErrors、SpilloverCount などのすべてのロードバランサーノードで集計されたメトリクスのみに適用されます。

SampleCount 統計は測定されたサンプルの数です。メトリクスはサンプリング間隔とイベントに基づいて集計されるため、通常、この統計は有用ではありません。例えば、HealthyHostCount の SampleCount は、正常なホストの数ではなく各ロードバランサーノードが報告するサンプル数に基づいています。

パーセンタイルは、データセットにおける値の相対的な位置を示します。小数点以下最大 2 桁を使用して、任意のパーセンタイルを指定できます (p95.45 など)。例えば、95 パーセンタイルは、95 パーセントのデータがこの値を下回っており、5 パーセントがこの値を上回っていることを意味します。パーセンタイルは、異常を分離するためによく使用されます。例えば、アプリケーションがほとんどのリクエストをキャッシュから 1 ～ 2 ミリ秒で処理するのに、キャッシュが空の場合は 100 ～ 200 ミリ秒になるとします。最大値は最も速度が遅い場合を反映し、約 200 ミリ秒になります。平均値はデータの分散を示してはいません。パーセンタイルで、アプリケーションのパフォーマンスのより有益なビューが得られます。99 番目のパーセンタイルを Auto Scaling のトリガーあるいは CloudWatch アラームとして使用すると、2 ミリ秒以上の処理時間がかかるリクエスト数が 1% を超えないようターゲットを設定できます。

ロードバランサーの CloudWatch メトリクスの表示

Amazon EC2 コンソールを使用して、ロードバランサーに関する CloudWatch メトリクスを表示できます。これらのメトリクスは、モニタリング用のグラフのように表示されます。ロードバランサーがアクティブでリクエストを受信しているときにのみ、モニタリング用のグラフにデータポイントが表示されます。

別の方法としては、ロードバランサーのメトリクスの表示に、CloudWatch コンソールを使用することもできます。

コンソールを使用してメトリクスを表示するには

1. Amazon EC2 コンソールの https://console.aws.amazon.com/ec2/ を開いてください。

2. ナビゲーションペインの [ロードバランシング] で [ロードバランサー] を選択します。

3. ロードバランサーの名前を選択して、その詳細ページを開きます。

4. モニタリングタブを選択します。

5. 1 つのメトリクスを拡大して表示するには、グラフ上にカーソルを移動させ、Maximize アイコンを選択します。以下のメトリクスが利用可能です。

   • 正常なホスト — HealthyHostCount

   • 非正常なホスト — UnHealthyHostCount

   • 平均レイテンシー — Latency

   • リクエスト — RequestCount

   • バックエンド接続エラー — BackendConnectionErrors

   • キュー長の急増 — SurgeQueueLength

   • 過剰数 — 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. CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。

2. ナビゲーションペインで [Metrics (メトリクス)] を選択してください。

3. [ELB] 名前空間を選択します。

4. 次のいずれかを行ってください。

   • メトリクスディメンションを選択して、ロードバランサーごと、アベイラビリティーゾーンごと、あるいはすべてのロードバランサーのメトリクスを表示できます。

   • すべてのディメンションでメトリクスを表示するには、検索フィールドに名称を入力します。

   • 1 つのロードバランサーのメトリクスを表示するには、検索フィールドにその名前を入力します。

   • 1 つのアベイラビリティーゾーンのメトリクスを表示するには、検索フィールドにその名前を入力します。