経緯
下記の記事でロードバランサーのモニタリング画面で確認できる「ELB 5XXs」と「HTTP 5XXs」がそれぞれ何を示しているのか調べました。
結論としては、次の通りでした。
- ELB 5XXs
- ロードバランサーが返す 5XXエラーがカウントされる
- HTTP 5XXs
- ターゲットが返す 5XXエラーがカウントされる
ここでさらなる疑問が生まれます。
「ターゲットとロードバランサーのステータスコードってどうマッピングされているんだろう？」
「まぁ、普通に、ターゲットが返したコードをロードバランサーがそのまま返すんやろな」（← 後から振り返ると正解だった）
ところが、以降で示すような状況に遭遇し、「あれ？違うかも。分からん。」となってしまいました。
ターゲットが500を返すのにロードバランサは返さない？
ターゲットが500を大量に返すトラブルがあったときの、「HTTP 5XXs」と「ELB 5XXs」のスクショです。
トラブルが発生したのは16:18で、「HTTP 5XXs」にメトリクスが大量にカウントされています。
一方、「ELB 5XXs」にはメトリクスがカウントされていませんでした。（17:47にちょろっと出ているのは別件）
「なんで ALB は500返していないんだろう？ 逆に何を返しているんだ？」と当然疑問に思います。
そこで、Athena で ALB アクセスログを確認します。
ログでは「elb_status_code」と「target_status_code」の両方のカラムに500が刻まれています。
つまり、ALBはターゲットから受け取ったコードをちゃんとクライアントに返している。
ということは、CloudWatchメトリクスでカウントしていないのが謎になる。
結論
サポートに聞いたところ次のような回答でした。
「ALBはたしかにターゲットと同じ500を返すけど、それはメトリクスにカウントされません。なぜなら、ターゲットが返した応答コードはカウント対象外だからです。ドキュメントに書いてるやろ、ほれ」（意訳）
HTTPCode_ELB_5XX_Count
ロードバランサーから送信される HTTP 5XX サーバーエラーコードの数。この数には、ターゲットによって生成される応答コードは含まれません。
HTTPCode_Target_5XX_Count
ターゲットによって生成された HTTP 応答コードの数。これには、ロードバランサーによって生成される応答コードは含まれません。
つまりこういうこと
まとめ
たしかに、ターゲットが返す応答コードもALBのメトリクスとしてカウントしてしまうと、
どこで問題が起こっているのかひと目で分からなくなってしまいますもんね。
それが、ALBでターゲットの500をカウントしていない理由なんだと思います。
言われてみれば納得の仕様でした。
参考
↑ ALBのエラーコードとその原因がまとめられていて勉強になりました。