概要
EC2のメトリクスしか知らなかったが、
あるとき保守しているシステムのELBで異常を検知し、そのときに初めてELBのメトリクスを見て色々知った。
いい機会なので、ELBをはじめとし、今後知ったものをここへまとめていく。
ELB(Classic Load Balancer)
AWSの名前空間 > ELBで確認できる。
さらに、以下に分類した結果が表示される。
- LB・AZ別
- AZ別
- LB別
- 名前空間別
- サービス別
- すべてのLBにわたり
ただ、見た感じだと
- すべてのLBにわたり、名前空間別、サービス別：同じ結果
- LB・AZ別：AZ混合の結果になっていておかしい
- AZ別：こちらもなぜか結果がおかしい
という状態で、実用に足るのは「LB別」のみという感じだった・・・
| メトリクス名 | 意味 |
|---|---|
| HealthyHostCount | ロードバランサー配下の正常なインスタンス数。統計は平均とMaxが有用。 |
| HTTPCode_Backend_2XX(3XX,4XX,5XX) | ELB配下のインスタンスからのレスポンスのステータスコードの数。ロードバランサーのレスポンスのステータスコードは含まれない。なお、統計はSumで見ないと1固定になってしまうので注意。 |
| HTTPCode_ELB_5XX | ロードバランサーのレスポンスのステータスコード5XXの数。ELB配下のインスタンスからのレスポンスのステータスコードの数は含まれない。ELBに配下のインスタンスで正常なインスタンスがひとつもない場合や、リクエストレートがインスタンスやロードバランサーの容量を超える場合に発生する。なお、統計はSumで見ないと1固定になってしまうので注意。 |
| レイテンシー | ロードバランサーが配下のインスタンスへリクエストを送信〜対象インスタンスがレスポンスヘッダを送信し始めた合計経過時間(秒)。アベレージ、Maxが有用 |
| RequestCount | 指定された間隔に完了したリクエストの数。合計が有用。 |
| SurgeQueueLength | ロードバランサー配下の正常なインスタンスへの送信を保留しているリクエスト数。Max1024で、いっぱいになると拒否される。統計はピークを知るためにMaximumが有用。 |
| UnHealthyHostCount | ロードバランサー配下の異常なインスタンス数。統計は平均とMinが有用 |
どうやら、RequestはHTTPCode_Backend_XXXの合計で、HTTPCode_ELB_XXXの数は含まれないみたい。
あくまでバックエンドからレスポンスを返せた分だけRequestではカウントしてるってことだね。実際にはユーザーに返ってるレスポンス数はHTTPCode_ELB_XXXの数も含まれるんだけど。
有用な統計の設定がそれぞれのメトリクスでまちまちなので、あらかじめ同じ統計になるものでダッシュボードに登録しておいた方が便利。
- HTTPCode_Backend_5XX:ELB配下のインスタンスでリクエストが裁けなくなってる
- SurgeQueLength:ELBでキューの待ちが発生→そもそもELBがボトルネックになってる
- HTTPCode_ELB_5XX|ELB配下のインスタンスに負荷がかかりすぎて死亡とうとうインスタンスのヘルスチェックOKのインスタンスが0になったのでインスタンスにリクエストすら送れなくなり、ELBくんがユーザーにインスタンス死んでるから無理ｗｗｗと5XXエラー返しだした
って感じでみればいいか。