DatadogでALBを監視するなら知っておきたい！httpcode_elb_4xx と httpcode_target_4xx の決定的な違い

AWS の Application Load Balancer（ALB）を Datadog で監視していると、4xx 系のメトリクスが 2 種類あることに気づきます。

• aws.applicationelb.httpcode_elb_4xx
• aws.applicationelb.httpcode_target_4xx

「結局どちらも 4xx エラーなんだから、どっちを監視しても同じじゃないの？」と思いがちですが、実はこの 2 つ、「エラーの発生源」が明確に区別されているんです。

今回は、この違いと使い分けについて解説します。

1. 結論：エラーを返したのは誰か？

一言で言うと、「エラーを生成した場所」が違います。

• elb_4xx：ALB 自体がエラーを生成した（アプリまでリクエストが届いていない）
• target_4xx：背後のアプリ（EC2/コンテナ等）がエラーを生成した（リクエストはアプリに届いた）

重要なのは、1つのエラーに対して両方のメトリクスが同時にカウントされることはないという点です。どちらか一方に分類されます。

2. それぞれの具体的なケース

httpcode_elb_4xx（ALBが返した場合）

リクエストが ALB のルールや制限に引っかかり、アプリに渡される前に ALB が「ごめんなさい」をした状態です。

• AWS WAF でブロックされた（403 Forbidden）
• リクエストヘッダーが大きすぎる（400 Bad Request）
• ALB のリスナールールで「固定レスポンス」を返した

httpcode_target_4xx（アプリが返した場合）

リクエストは正常にアプリまで到達しましたが、アプリ側が「そのリクエストには応じられません」と回答した状態です。

• 存在しないパスへのアクセス（404 Not Found）
• ログインが必要なページへの未認証アクセス（401 Unauthorized）
• アプリ側のバリデーションエラー

3. よくある疑問：「存在しないパス」へのリクエストはどうなる？

「存在しないパスにアクセスが来て、アプリが 404 を返している場合、ALB を経由しているから両方増えるのでは？」と疑問に思うかもしれません。

答えは target_4xx だけが増えます。

ALB はあくまで「アプリから受け取った 404 をクライアントにパス（中継）しているだけ」なので、ALB 自身のエラー（elb_4xx）としてはカウントされないのです。

4. 運用での使い分け：どう監視を設計するか

まとめ

• elb_4xx は ALB の門番が追い返した数。
• target_4xx は 中の人が対応した結果お断りした数。

この違いを理解しておくと、Datadog でアラートが飛んできた時に「インフラ（WAF/ALB）を疑うべきか、アプリのコードを疑うべきか」を即座に判断できるようになります！

saratoga

フリーランスエンジニア

XYouTube

仕事にも趣味にも IT を駆使するフリーランスエンジニア。技術的な TIPS や日々の生活の中で深堀りしてみたくなったことを備忘録として残していきます。