Classic Load Balancer の CloudWatch メトリクス - Elastic Load Balancing

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 です。AverageMinimumMaximum はロードバランサーノードごとに報告されるため、通常有益ではありません。ただし、最大と最小の差 (ピーク値対平均、または平均対底値) は、1 つのロードバランサーノードが異常値かどうかを判断する上で有益な場合があります。

: ロードバランサーにインスタンスがあり、そのうちの 2 つのインスタンスは us-west-2a に、もう 2 つのインスタンスは us-west-2b にあるとします。また、us-west-2a の 1 つのインスタンスへの接続を試みると、バックエンド接続エラーになるとします。us-west-2a の合計にはこれらの接続エラーが含まれますが、us-west-2b の合計には含まれません。このため、ロードバランサーの合計は us-west-2a の合計と同じになります。

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_2XXHTTPCode_Backend_3XXHTTPCode_Backend_4XXHTTPCode_Backend_5XX

[HTTP リスナー] 登録されたインスタンスによって生成された HTTP 応答コードの数。この数には、ロードバランサーによって生成される応答コードは含まれません。

レポート条件: ゼロ以外の値がある

統計: 最も有用な統計は Sum です。MinimumMaximum、および 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 です。MinimumMaximum、および Average はすべて 1 です。

: ロードバランサーで us-west-2a および us-west-2b が有効になっていて、クライアントリクエストに正しい形式でないリクエスト URL が含まれているとします。その結果、すべてのアベイラビリティーゾーンでのクライアントエラーが増加する可能性があります。ロードバランサーの合計はアベイラビリティーゾーンの値の合計です。

HTTPCode_ELB_5XX

[HTTP リスナー] ロードバランサーで生成される HTTP 5XX サーバーのエラーコードの数。この数には、登録されたインスタンスによって生成される応答コードは含まれません。ロードバランサーに登録されている正常なインスタンスがない場合、またはリクエストレートがインスタンスまたはロードバランサーの容量を超える場合 (スピルオーバー)、このメトリクスが報告されます。

レポート条件: ゼロ以外の値がある

統計: 最も有用な統計は Sum です。MinimumMaximum、および 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 です。MinimumMaximum、および 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 です。AverageMinimumMaximum はロードバランサーノードごとに報告されるため、通常有益ではありません。

: ロードバランサーで 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 から アプリケーションロードバランサー への移行コストを見積もることができます。これらのメトリクスは、単なる参考情報であり、CloudWatch アラーム用に意図されたものではありません。Classic Load Balancer に複数のリスナーがある場合、これらのメトリクスはすべてのリスナーの集計です。

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

メトリクス 説明
EstimatedALBActiveConnectionCount

クライアントからロードバランサーへ、およびロードバランサーからターゲットへの、アクティブな同時 TCP 接続の予測数。

EstimatedALBConsumedLCUs

アプリケーションロードバランサー で使用されるロードバランサーキャパシティーユニット (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 つあるとします。一方のノードは、HealthyHostCountMinimum が 2、Maximum が 10、Average が 6 で、もう一方のノードは HealthyHostCountMinimum が 1、Maximum が 5、Average が 3 です。このため、ロードバランサーの Minimum は 1、Maximum は 10、Average は約 4 です。

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

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

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

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

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

または、CloudWatch コンソールを使用してロードバランサーのメトリクスを表示できます。

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

  1. https://console.aws.amazon.com/ec2/ で Amazon EC2 コンソールを開きます。

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

  3. ロードバランサーを選択します。

  4. [Monitoring] タブを選択します。

  5. (オプション) 結果を時間でフィルタリングするには、[Showing data for] から時間範囲を選択します。

  6. 1 つのメトリクスの大きいビューを取得するには、グラフを選択します。以下のメトリクスが利用可能です。

    • 正常なホスト — HealthyHostCount

    • 非正常なホスト — UnHealthyHostCount

    • 平均レイテンシー — Latency

    • 合計リクエスト数 — RequestCount

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

    • キュー長の急増 — SurgeQueueLength

    • 過剰数 — SpilloverCount

    • 合計 HTTP 2XX — HTTPCode_Backend_2XX

    • 合計 HTTP 4XX — HTTPCode_Backend_4XX

    • 合計 HTTP 5XX — HTTPCode_Backend_5XX

    • Sum ELB HTTP 4XXs — HTTPCode_ELB_4XX

    • Sum ELB HTTP 5XXs — HTTPCode_ELB_5XX

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

  1. https://console.aws.amazon.com/cloudwatch/ にある CloudWatch コンソールを開きます。

  2. ナビゲーションペインで メトリクスを選択します。

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

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

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

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

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

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

ロードバランサーに CloudWatch アラームを作成する

1 つのアラームで、指定した期間中、1 つのメトリクスを監視します。アラームでは、アプリケーション、エンドユーザー、デバイスが瞬時に通知を送受信できるようにするサービスである Amazon SNS を使用して、定義したしきい値に対するメトリクスの値に応じて 1 つ以上の通知を送信することができます。詳細については、「Amazon Simple Notification Service とは」を参照してください。

指定されたメトリクスが定義された範囲に達し、特定期間その範囲に留まると、アラームにより Amazon SNS に通知が送信されます。アラームには次の 3 つの状態があります。

  • OK – メトリクスの値が、指定した範囲内に収まっている。

  • ALARM – メトリクスの値が、時間の期間について指定した範囲に収まっていない。

  • INSUFFICIENT_DATA – メトリクスがまだ使用できないか、データが不足していてアラームの状態を判定できない。

アラームの状態が変化するたびに、CloudWatch は Amazon SNS を使用して、指定した E メールアドレスに通知を送信します。

次の手順を実行して、Amazon EC2 コンソールを使用してロードバランサーに関するアラームを作成します。このアラームは、5 分の連続した期間にロードバランサーのレイテンシーが 120 秒を超えるたびに、SNS トピックに通知を送信します。期間を短くするほど高感度のアラームが作成され、期間を長くするほどメトリクスの短時間での急上昇を軽減できることに注意してください。

注記

または、CloudWatch コンソールを使用してロードバランサーに関するアラームを作成することができます。詳細については、Amazon CloudWatch ユーザーガイド の「ロードバランサーアラームに基づいて E メールを送信する」を参照してください。

ロードバランサーにアラームを作成するには

  1. https://console.aws.amazon.com/ec2/ で Amazon EC2 コンソールを開きます。

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

  3. ロードバランサーを選択します。

  4. [Monitoring] タブで、[Create Alarm] を選択します。

  5. 使用する SNS トピックがある場合は、[Send a notification to] からそのトピックを選択します。ない場合は、次のようにして SNS トピックを作成します。

    1. [create topic] を選択します。

    2. [Send a notification to] に、トピック名を入力します。

    3. [With these recipients] に、通知の受取人の E メールアドレスを入力します。複数のアドレスを入力する場合はカンマで区切ります。最大 10 個の E メールアドレスを入力できます。各受信者には、通知を受け取るために SNS トピックを購読するリンクを記載したメールが Amazon SNS から送信されます。

  6. 次のように、アラームのしきい値を定義します。[Whenever] では、[Average] および [Average Latency] を選択します。[Is] では、[>] を選択して 120 と入力します。[For at least] に「1」と入力し、連続した間隔として [5 minutes] を選択します。

  7. [Name of alarm] に名前が自動的に表示されます。必要に応じて、別の名前を入力できます。

  8. [Create Alarm] を選択します。