What's This

監視（疎通確認）で、ELB のTarget groupに通信が届かず、なぜだろうと考えていたところ、
社内の有識者にアドバイスいただき、解決できたのでそのメモです。

Details

Apacheのアクセスログを確認したところ、監視 Agentからの通信が来ていませんでした。

sudo grep "監視 Agent" /var/log/httpd/access_log
# 出力なし

また、curlでhttp/1.1を使ってアクセスすると464になりました。

$ curl --http1.1 -I https://hogehogeなURL/
HTTP/1.1 464
Server: awselb/2.0
Date: 日時
Content-Length: 0
Connection: keep-alive

このことから、以下仮説になりました。

・464はクライアント側とELB間でHTTP/1.1やHTTP/2.0、gRPCの差異があると出るエラー。
監視で使用するクライアントではHTTP/1.1が使用されているため、
現在ALBに設定されているHTTP/2対応のターゲットグループ経由でEC2にアクセスしようとすると、HTTP 464が返ってくる。
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html#http-464-issues

・監視用にHTTP/1対応のターゲットグループを作成して、
以下URI宛のアクセスのみ、そのターゲットグループに転送させるようALBのリスナールールを追加。
https://hogehogeなURL/healthcheck/

・監視で使用されているリクエストプロトコルは HTTP/1.1 であるが、
ターゲットグループのプロトコルバージョンが　HTTP/2 であるため、疎通確認が失敗していた。

・疎通確認用に、HTTP/1.1対応のターゲットグループを作成した。
・疎通確認用に、以下URI宛のアクセスのみ、そのターゲットグループに転送させるようALBのリスナールールを追加。
https://hogehogeなURL/healthcheck/

・監視でAlertではなく、正常判定になった。
・アクセスログで、監視 Agentから通信がきていることを確認できた。

sudo tail -n 20 /var/log/httpd/access_log
"IP" - - [日時時刻] "GET /healthcheck/ HTTP/1.1" 200 12 "-" "監視 Agent/0.0.0"

HTTPプロトコルのバージョンについては、なんとなくバージョンがあるんだな〜くらいの理解でしたが、
バージョンの不一致で疎通確認が失敗することがあるんですね。

・社内有識者
弊社には優秀な技術者が数多く在籍しており、技術的にわからないところがあれば、部署超えて教え合う風土が整っています。
自分は何回アドバイスいただいたか数え切れないほどです・・