2014/02/13追記
ELBの挙動とCloudWatchメトリクスの読み方を徹底的に理解する ｜ Developers.IOがわかりやすいですね
- Elastic Load Balancing Developer Guide (API Version 2012-06-01)を見て各監視項目の内容を訳してみた（英語苦手)
| Metric | Unit | 詳細 |
|---|---|---|
| Latency | Seconds | リクエストがロードバランサーを離れてから対応する応答を受け取るまでの経過時間 |
| RequestCount | Count | ロードバランサーに処理されるリクエストの数 |
| HealthyHostCount | Count | 指定されたAvailabilityZoneでのロードバランサーに登録されたhelthyなEC2インスタンスの数。 unhealthyな閾値を超えてヘルスチェックに失敗していないホストはhealthyだとみなされる。 このmetricを評価する場合、dimensionはLoadBalancerNameとAvailabilityZoneで規定されるはずである。 このmetricは指定されたAvailability Zoneでのhealthyなインスタンスの数を表している。 200でない応答(HTTPやHTTPSでのヘルスチェックの場合)が返ったり、ヘルスチェックを行っている場合にタイムアウトするような接続の問題でインスタンスはunhealthyになることがある。 全てのhealthyなホスト数の合計を得るために、このmetricは各登録されたAvailabilityZoneを取得し、全てのmetricを合わせて追加する必要がある |
| UnHealthyHostCount | Count | 指定されたAvailabilityZoneでのロードバランサーに登録されたunhelthyなEC2インスタンスの数。 unhealthyな閾値を超えてヘルスチェックに失敗したホストはunhealthyだとみなされる。 このmetricを評価する場合、dimensionはLoadBalancerNameとAvailabilityZoneで規定されるはずである。 このmetricは指定されたAvailability Zoneでのunhealthyなインスタンスの数を表している。 200でない応答(HTTPやHTTPSでのヘルスチェックの場合)が返ったり、ヘルスチェックを行っている場合にタイムアウトするような接続の問題でインスタンスはunhealthyになることがある。 全てのunhealthyなホスト数の合計を得るために、このmetricは各登録されたAvailabilityZoneを取得し、全てのmetricを合わせて追加する必要がある |
| HTTPCode_ELB_4XX | Count | ELBによって生成された4xx(クライアントエラー)系のHTTPレスポンスコードの数 |
| HTTPCode_ELB_5XX | Count | ELBによって生成された5xx(サーバーエラー)系のHTTPレスポンスコードの数。 もしバックエンドのインスタンスが登録されていない、healthyなバックエンドインスタンスがない、要求率がELBの現在利用可能なキャパシティーを超えているといったような場合、ELBは5xxエラーを生成するだろう。 このレスポンス数はバックエンドインスタンスが生成したレスポンスを含んでいない |
| HTTPCode_Backend_2XX | Count | バックエンドインスタンスによって生成された2xx(成功)系のHTTPレスポンスコードの数 |
| HTTPCode_Backend_3XX | Count | バックエンドインスタンスによって生成された3xx(ユーザのアクションが必要)系のHTTPレスポンスコードの数 |
| HTTPCode_Backend_4XX | Count | バックエンドインスタンスによって生成された4xx(クライアントエラー)系のHTTPレスポンスコードの数。 このレスポンス数はELBが生成したレスポンスを含んでいない |
| HTTPCode_Backend_5XX | Count | バックエンドインスタンスによって生成された5xx(サーバーエラー)系のHTTPレスポンスコードの数。 このレスポンス数はELBが生成したレスポンスを含んでいない |