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
Solution
・監視用にHTTP/1対応のターゲットグループを作成して、
以下URI宛のアクセスのみ、そのターゲットグループに転送させるようALBのリスナールールを追加。
https://hogehogeなURL/healthcheck/
Conclusion
原因
・監視で使用されているリクエストプロトコルは 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プロトコルのバージョンについては、なんとなくバージョンがあるんだな〜くらいの理解でしたが、
バージョンの不一致で疎通確認が失敗することがあるんですね。
Reference
・社内有識者
弊社には優秀な技術者が数多く在籍しており、技術的にわからないところがあれば、部署超えて教え合う風土が整っています。
自分は何回アドバイスいただいたか数え切れないほどです・・