「ALB 502 エラーの原因切り分け Yes/No 診断」を作ってみた | DevelopersIO
こんにちは、テクニカルサポートの Shimizu です。 弊社ヘルプデスクへ「Application Load Balancer（ALB）の 502 エラーの原因調査が難しい」というお問い合わせをよくいただきます。 実際サポート側においても「原因箇所が ALB 側か、またはバックエンド EC2 サーバー側か」の切り分けは確認するべき点が多く、毎回時間がかかります。 そこで「もっと簡単に原因を切り分ける方法がないか」と考えた結果、Yes/No 形式のトラブルシューティングを作ろうと思いつきました。 それでは始めてみましょう！ 質問 [質問1] 該当時刻の ALB のメトリクスを確認しましょう。「HTTP 5XXs」は出ていますか？ YES（出ている） バックエンドサーバーの内部から 500 系のエラーレスポンスが返されており、バックエンド側の問題を明確に示しています。 → [結果A] へ N
ALB のターゲットグループに登録されているインスタンスがすべて Unhealthy の状態でも、ALB へアクセスするとインスタンスへ接続できる挙動は仕様通りです。 | DevelopersIO
困っていた内容 ALB のターゲットグループに登録されているインスタンスがすべて Unhealthy となりました。 しかし、ALB の FQDN へアクセスするとターゲットインスタンスに接続できます。 これは正しい挙動ですか？ どう対応すればいいの? AWS ドキュメントに記載のある仕様通りの挙動となります。 ALB のターゲットグループに登録されているインスタンスがすべて Unhealthy となった場合、ALB のノードは Unhealthy となったターゲット間でリクエストをルーティングします。 そのため、ALB の FQDN へアクセスしてもターゲットインスタンスに接続できます。 しかしながら、想定しない予期せぬ挙動が発生する可能性があるため、基本的にはターゲットインスタンスのヘルスチェックは Healthy であることが望ましいです。 やってみた EC2 に Apache をイ
ALBはヘルスチェックに指定したパスが存在しないと、ヘルスチェックに失敗する | DevelopersIO
ALBのヘルスチェックに関連して、気付きづらいポイントがあるので解説します。 ALBのヘルスチェックについて ALBはターゲットのステータスを確認するために定期的にリクエストを送信します。AWSコンソールから特になにも設定変更せずにターゲットグループを設定すると、"/"に対してリクエストを送信します。 "/"を指定した場合、ドキュメントルートに接続することになります。Amazon Linux2にapacheをインストールした場合、初期設定では/var/www/htmlです。 $ grep "/html" httpd.conf DocumentRoot "/var/www/html" apacheをインストールしただけでは、ドキュメントルート配下にファイルがありません。 $ yum install httpd $ systemctl start httpd $ ls -l /var/www/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
