AWS：どのインスタンスもデータを送信していません
Amazon Web ServicesでElastic Beanstalkアプリケーションを設定しようとしていますが、メッセージNone of the instances are sending data。サンプルアプリケーションを使用してElastic BeanstalkアプリケーションとEC2インスタンスを数回削除して再試行しましたが、同じエラーが発生します。
また、AWS Elastic Beanstalkコマンドラインツールを使用してflaskアプリケーションをアップロードしようとしましたが、次のエラーが表示されました。
Environment health has transitioned from Pending to Severe. 100.0 % of the requests to the ELB are failing with HTTP 5xx. Insufficient request rate (0.5 requests/min) to determine application health (7 minutes ago). ELB health is failing or not available for all instances. None of the instances are sending data
このエラーが発生する理由と修正方法を教えてください。ありがとう。
Enhanced Health Monitoring を使用しています。強化されたヘルスモニタリングにより、EC2インスタンスにインストールされた agent は、重要なシステムおよびアプリケーションレベルのヘルスメトリックを監視し、Elastic Beanstalkに直接送信します。
「いずれのインスタンスもデータを送信していません」などのエラーメッセージが表示される場合、インスタンスのエージェントがクラッシュしているか、ネットワークエラーまたはその他のエラーのためにElastic Beanstalkにデータを投稿できないことを意味します。
これをデバッグするには、AWSコンソールから「フルログ」をダウンロードすることをお勧めします。 「Elastic Beanstalkコンソールからのバンドルログのダウンロード」セクションのログを取得する手順に従ってください here 。何らかの理由でコンソールを使用してログをダウンロードできない場合は、インスタンスにsshして/var/logのログを確認することもできます。
/var/log/healthd/daemon.logにヘルスエージェントのログがあります。この状況に役立つ追加のログは、/var/log/cfn-init.log、/var/log/eb-cfn-init.log、および/var/log/eb-activity.logです。ログを見て、表示されるエラーの詳細を教えてください。これにより、「どのインスタンスもデータを送信していません」というエラーに関する詳細がわかります。
他の健康の「原因」に関して、あなたは見ています：
環境の健全性が保留から重大に移行しました-これは、最初は環境の健全性ステータスがPendingであるためです。インスタンスが猶予期間内に正常にならない場合、正常性状態はSevereに移行します。あなたのケースでは、どのインスタンスも健全/データを送信していないため、健全性は重大に移行しました。
ELBへのリクエストの100.0％がHTTP 5xxで失敗しています。アプリケーションの健全性を判断するための不十分なリクエストレート（0.5リクエスト/分）（7分前）。Elastic Beanstalkは、強化された健全性モニタリングを使用する場合、EC2インスタンスに加えて他のリソースを監視します。たとえば、ELBのクラウドウォッチメトリックを監視します。このエラーは、環境CNAME /ロードバランサーに送信されたすべてのリクエストがHTTP 5xxエラーで失敗していることを意味します。同時に、リクエストレートは1分あたり0.5リクエストと非常に低いため、すべてのリクエストが失敗してもリクエストレートがかなり低いことを示しています。 「7分前」は、ELBメトリックに関する情報が少し古いことを意味します。 Elastic Beanstalkはクラウドウォッチメトリックスを数分ごとに監視するため、データが少し古くなる可能性があります。これは、「ほぼリアルタイム」であるEC2インスタンスから直接取得するヘルスデータとは対照的です。あなたの場合、インスタンスはデータを送信していないため、ヘルスの利用可能なソースはELBメトリックのみで、約7分遅れています。
ELBヘルスが失敗しているか、すべてのインスタンスで利用できないElastic BeanstalkはELBのヘルスを調べています。つまり、背後でサービス中のインスタンスの数をチェックしていますELB。あなたの場合、ELBの背後にあるすべてのインスタンスがアウトオブサービスであるか、他の何らかの理由でヘルスが利用できません。サービスロールが正しく構成されていることを再確認する必要があります。サービスロールを正しく構成する方法を読むことができます here または documentation で。アプリケーションの起動に失敗した可能性があります。
あなたの場合、最初のエラー「どのインスタンスもデータを送信していません」に注目することをお勧めします。このためには、上記で概説したログを確認する必要があります。ログに表示される内容を教えてください。エージェントは、インスタンスのbootstrapプロセスのかなり早い段階で開始されます。したがって、「インスタンスのいずれもデータを送信していません」などのエラーが表示される場合、bootstrapが失敗したか、何らかの理由でエージェントを起動できませんでした。
また、環境でインスタンスプロファイルを使用していることを確認してください。インスタンスプロファイルにより、EC2インスタンスで実行されているヘルスエージェントはElastic Beanstalkで認証できます。インスタンスプロファイルが環境に関連付けられていない場合、エージェントはElastic Beanstalkにデータを送信できません。 Elastic Beanstalkを使用したインスタンスプロファイルの詳細については、こちらをご覧ください こちら 。
Update正常性の原因「インスタンスのいずれもデータを送信していない」の1つの一般的な理由は、インスタンスがVPCにあり、VPCが許可しないことです。 NTP access。この問題の典型的な指標は/var/log/messages: ntpdate: Synchronizing with time server: [FAILED]の次のメッセージです。これが発生すると、EC2インスタンスのクロックが同期しなくなり、データは無効と見なされます。また、AWSウェブコンソールの健全性ページでインスタンスの健全性の原因が表示され、インスタンスのクロックが同期していないことがわかります。修正は、VPCがNTPへのアクセスを許可するようにすることです。
健康エージェントがデータを送信できない理由はたくさんありますので、これはあなたの問題に対する答えではないかもしれませんが、それは私のものであり、うまくいけば他の誰かを助けることができます：
同じエラーが発生し、/var/log/healthd/daemon.log次のことが繰り返し報告されました。
sending message(s) failed: (Aws::Healthd::Errors::GroupNotFoundException) Group 97c30ca2-5eb5-40af-8f9a-eb3074622172 does not exist
これは、Elastic Beanstalk環境内のEC2インスタンスからAMIイメージを作成して使用したことが原因でした。つまり、実稼働環境と同じ構成の1つのインスタンスで一時環境を作成し、EC2コンソールに移動してインスタンスのイメージを作成し、一時環境を終了してから、新しいカスタムAMIを使用してさらに別の環境を作成しました。
もちろん（後知恵で）これは、一時環境のいくつかの設定がまだ使用されていることを意味します。この場合、特に/etc/healthd/config.yaml。その結果、ヘルスエージェントは、存在しないヘルスグループにメッセージを送信しようとします。
これを修正し、他の古い構成が存在しないことを確認するために、代わりに、本番環境で使用されるデフォルトのAMIから新しいEC2インスタンスを手動で開始しました（環境の「インスタンス」構成ページで確認します）。次に、そこから新しいイメージを作成し、そのイメージを新しいEB環境で使用します。
別のセキュリティグループ（Elastic Beanstalkのデフォルトグループ）を追加することでこれを解決しました。
インスタンスタイプのRAMがアプリ+ os + Amazonツールに十分であるかどうかを確認します。t2.microがユースケースにかろうじて十分であることを発見したとき、これに長い間苦しみました。 t2.small（2GB）を使用した直後に問題は解決しました。