Elastic Beanstalk の拡張ヘルスレポートとモニタリング

このセクションでは、Elastic Beanstalk 拡張ヘルス機能の機能について説明します。

拡張ヘルスレポートは、環境で を有効にして、 が環境内のリソースに関する追加情報 AWS Elastic Beanstalk を収集できるようにする機能です。Elastic Beanstalk は、収集された情報を分析して環境全体の状態をより的確に示し、アプリケーションの使用を妨げる可能性のある問題を特定するために役立ちます。

色で状態を示す機能が変更されたことに加え、拡張ヘルスレポートにはステータス記述子が追加されています。これは、環境の状態が黄色または赤色の場合に検出された問題の重大度を示します。現在のステータスに関する詳細情報があるときは、[Causes] ボタンを選択して、[Health] ページにヘルスに関する詳細情報を表示できます。

環境で実行されている Amazon EC2インスタンスに関する詳細なヘルス情報を提供するために、Elastic Beanstalk では、拡張ヘルスをサポートする各プラットフォームバージョンの Amazon マシンイメージ (AMI) にヘルスエージェントが含まれています。状態エージェントは、ウェブサーバーログとシステムメトリクスを監視して、Elastic Beanstalk サービスに中継します。Elastic Beanstalk は、Elastic Load Balancing と Amazon EC2 Auto Scaling からのこれらのメトリクスとデータを分析して、環境の状態の全体像を提供します。

環境のリソースに関する情報の収集および提示に加えて、Elastic Beanstalk は何種類かのエラー状態に備えて環境内のリソースを監視し、通知を提供します。これは、障害を回避し、設定の問題を解決するために役立ちます。お客様の環境のヘルスに影響を与える要因としては、アプリケーションによって処理された各リクエストの結果、お客様のインスタンスのオペレーティングシステムからのメトリクス、最新のデプロイのステータスなどがあります。

Elastic Beanstalk コンソールの環境概要ページまたは Elastic Beanstalk コマンドラインインターフェイス (EB) の eb ヘルスコマンドを使用して、ヘルスステータスをリアルタイムで表示できますCLI。 Elastic Beanstalk コマンドラインインターフェイス (EB CLI) の使用環境とインスタンスのヘルスを経時的に記録および追跡するには、Elastic Beanstalk によって収集された情報をカスタムメトリクス CloudWatch として Amazon に公開するように環境を設定できます。カスタムメトリクス CloudWatch の料金はEnvironmentHealth、 以外のすべてのメトリクスに適用されます。これは無料です。

Windows プラットフォームのメモ

Windows Server 環境で拡張ヘルスレポートを有効にする場合、IISログ記録設定 を変更しないでください。拡張ヘルスモニタリングを正しく機能させるには、IISログ記録を W3C 形式とETWイベントのみ、またはログファイルとETWイベントログの両方のイベント送信先で設定する必要があります。

さらに、いずれの環境のインスタンスでも、Elastic Beanstalk ヘルスエージェントの Windows サービスを無効化または停止しないでください。インスタンスで拡張ヘルス情報を収集および報告するには、このサービスが有効で実行中である必要があります。

初めて環境を作成すると、Elastic Beanstalk から必要なロールを作成するように求められ、デフォルトで拡張ヘルスレポートが有効になります。拡張ヘルスレポートの詳しいしくみについては、この後の説明を参照してください。すぐに開始するには、「Elastic Beanstalk の拡張ヘルスレポートの有効化」を参照してください。

トピック

• Elastic Beanstalk のヘルスエージェント
• インスタンスと環境の状態を判断するための要素
• ヘルスチェックルールのカスタマイズ
• 拡張ヘルスレポートのロール
• 拡張ヘルス認証
• 拡張ヘルスレポートのイベント
• 更新、デプロイ、およびスケーリング中の拡張ヘルスレポートの動作
• Elastic Beanstalk の拡張ヘルスレポートの有効化
• 環境管理コンソールでの拡張ヘルスモニタリング
• 状態の色とステータス
• インスタンスメトリクス
• 環境の拡張ヘルスルールの設定
• 環境の Amazon CloudWatch カスタムメトリクスの発行
• Elastic Beanstalk API での拡張ヘルスレポートの使用
• 拡張ヘルスログ形式
• 通知とトラブルシューティング

Elastic Beanstalk のヘルスエージェント

Elastic Beanstalk ヘルスエージェントは、環境内の各 Amazon EC2インスタンスで実行され、オペレーティングシステムとアプリケーションレベルのヘルスメトリクスをモニタリングし、問題を Elastic Beanstalk に報告するデーモンプロセス (または Windows 環境でのサービス) です。ヘルスエージェントは、各プラットフォームのバージョン 2.0 以降、すべてのプラットフォームのバージョンに含まれています。

ヘルスエージェントは、CPUロード、HTTPコード、レイテンシーなどの基本的なヘルスレポートの一部として、Amazon EC2 Auto Scaling および Elastic Load Balancing によって に発行された CloudWatchメトリクスと同様のメトリクスをレポートします。ただし、状態エージェントによるレポートは、ベーシックヘルスレポートより高い詳細度と頻度で直接 Elastic Beanstalk に送信されます。

ベーシックヘルスレポートの場合、これらのメトリクスは、5 分間隔で公開され、環境マネジメントコンソールのグラフで確認できます。拡張ヘルスでは、Elastic Beanstalk ヘルスエージェントは 10 秒ごとに Elastic Beanstalk にメトリクスを報告します。Elastic Beanstalk は状態エージェントから提供されたメトリクスを使用して、環境内の各インスタンスのヘルスステータスを判断します。さらに、他の要素と組み合わせて、環境全体の状態を判断します。

環境の全体的な状態は、Elastic Beanstalk コンソールの環境概要ページでリアルタイムで表示でき、Elastic Beanstalk CloudWatch によって 60 秒ごとに発行されます。EB CLIの eb health コマンドを使用して、ヘルスエージェントによってリアルタイムで報告された詳細なメトリクスを表示できます。

追加料金で、60 秒 CloudWatch ごとに個々のインスタンスと環境レベルのメトリクスを に発行することを選択できます。その後 CloudWatch 、 に公開されたメトリクスを使用して、環境管理コンソール でモニタリンググラフを作成できます。

拡張ヘルスレポートには、拡張ヘルスメトリクスを に発行する場合にのみ料金が発生します CloudWatch。拡張ヘルスレポートを使用していて、拡張ヘルスレポートのメトリクスを公開するオプションを選択していなくても、ベーシックヘルスレポートのメトリクスは無料で公開できます。

状態エージェントによって報告されるメトリクスの詳細については、「インスタンスメトリクス」を参照してください。拡張ヘルスメトリクスを に発行する方法の詳細については CloudWatch、「」を参照してください環境の Amazon CloudWatch カスタムメトリクスの発行。

インスタンスと環境の状態を判断するための要素

Elastic Beanstalk 拡張ヘルスレポートは、基本的なヘルスレポートのシステムチェック (Elastic Load Balancing のヘルスチェック およびリソースモニタリングなど) に加えて、環境内のインスタンスの状態に関する追加のデータを収集します。これには、オペレーティングシステムのメトリクス、サーバーログ、およびデプロイや更新などの進行中の環境オペレーションの状態が含まれます。Elastic Beanstalk ヘルスレポートサービスは、利用可能なすべてのソースからの情報を組み合わせて分析し、環境全体の状態を判断します。

オペレーションとコマンド

環境内でオペレーション (アプリケーションの新しいバージョンのデプロイなど) を実行する場合、Elastic Beanstalk では、環境のヘルスステータスに影響するいくつかの変更が行われます。

例えば、複数のインスタンスを実行している環境にアプリケーションの新しいバージョンをデプロイすると、EB でCLI環境の状態をモニタリングするときに次のようなメッセージが表示されることがあります。

  id             status     cause
    Overall      Info       Command is executing on 3 out of 5 instances
  i-bb65c145     Pending    91 % of CPU is in use. 24 % in I/O wait
                            Performing application deployment (running for 31 seconds)
  i-ba65c144     Pending    Performing initialization (running for 12 seconds)
  i-f6a2d525     Ok         Application deployment completed 23 seconds ago and took 26 seconds
  i-e8a2d53b     Pending    94 % of CPU is in use. 52 % in I/O wait
                            Performing application deployment (running for 33 seconds)
  i-e81cca40     Ok

この例では、環境全体のステータスが Ok であり、このステータスの原因は Command is executing on 3 out of 5 instances です。環境内の 3 つのインスタンスのステータスが Pending であり、オペレーションが進行中であることを示します。

オペレーションが完了すると、Elastic Beanstalk により、オペレーションに関する追加情報が報告されます。たとえば、アプリケーションの新しいバージョンに更新が完了しているインスタンスについては、次の情報が表示されます。

i-f6a2d525     Ok         Application deployment completed 23 seconds ago and took 26 seconds

インスタンスのヘルスに関する情報には、お客様の環境内の各インスタンスへの最新のデプロイに関する詳細も含まれます。各インスタンスについて、デプロイ ID とステータスがレポートされます。デプロイ ID は整数であり、アプリケーションの新しいバージョンをデプロイするか、環境変数などインスタンス関連の設定オプションの設定を変更するたびに、1 ずつ増えます。デプロイに関する情報を使用して、ローリングデプロイの失敗後にアプリケーションの間違ったバージョンを実行しているインスタンスを特定できます。

Elastic Beanstalk は、原因を示す列に、成功したオペレーションに関する情報メッセージと、複数のヘルスチェックにおけるその他のヘルスステータスを表示しますが、これらは無期限に保存されるわけではありません。環境の異常な状態の原因を示す情報が保存されるのは、環境の状態が正常に戻るまでです。

コマンドタイムアウト

インスタンスが正常な状態に移行できるように、Elastic Beanstalk では、オペレーションが開始した時点からコマンドタイムアウトが適用されます。このコマンドタイムアウトは、環境の更新およびデプロイ設定 (aws:elasticbeanstalk:command 名前空間) で設定されており、デフォルト値は 10 分です。

ローリング更新の実行中、Elastic Beanstalk は、オペレーション内の各バッチに別々のタイムアウトを適用します。このタイムアウトは環境のローリング更新の一部として (aws:autoscaling:updatepolicy:rollingupdate 名前空間で) 設定されます。バッチ内のすべてのインスタンスがローリング更新タイムアウト内で正常に実行されている場合は、オペレーションが次のバッチに進みます。それ以外の場合、オペレーションは失敗となります。

注記

アプリケーションがヘルスチェックで OK ステータスにならなくても、別のレベルで安定する場合は、HealthCheckSuccessThreshold で aws:elasticbeanstalk:command namespace オプションを設定して、Elastic Beanstalk でインスタンスが正常と見なされるレベルに変更できます。

ウェブサーバー環境が正常であると見なされるには、環境内またはバッチ内の各インスタンスが 2 分間にわたって連続して行われる 12 のヘルスチェックに合格する必要があります。ワーカー枠環境の場合は、各インスタンスが 18 のヘルスチェックに合格する必要があります。Elastic Beanstalk は、ヘルスチェックで異常が検出されても、コマンドタイムアウトの前には、環境のヘルスステータスを引き下げません。環境内のインスタンスがコマンドタイムアウト内に正常な状態である場合、オペレーションは成功となります。

HTTP リクエスト

環境で進行中のオペレーションがない場合、インスタンスと環境の状態に関する情報のプライマリソースは、各インスタンスのウェブサーバーログです。インスタンスの状態と環境全体の状態を判断するためには、リクエストの数、各リクエストの結果、各リクエストが解決された速度が考慮されます。

Linux ベースのプラットフォームでは、Elastic Beanstalk はウェブサーバーログを読み取り、解析して、HTTPリクエストに関する情報を取得します。Windows Server プラットフォームでは、Elastic Beanstalk はIISウェブサーバー から直接この情報を受け取ります。

環境にはアクティブなウェブサーバーがない可能性があります。たとえば、複数コンテナ Docker プラットフォームにはウェブサーバーは含まれません。その他のプラットフォームにはウェブサーバーがあり、アプリケーションがこれを無効にする可能性があります。このような場合、環境では、ヘルス情報を Elastic Beanstalk サービスに中継するために必要な形式のログを Elastic Beanstalk ヘルスエージェントに提供するための、追加の設定が必要です。詳細については、「拡張ヘルスログ形式」を参照してください。

オペレーティングシステムのメトリクス

Elastic Beanstalk は、状態エージェントから報告されたオペレーティング システムのメトリクスを監視し、継続的にシステムリソースが不足しているインスタンスを特定します。

状態エージェントによって報告されるメトリクスの詳細については、「インスタンスメトリクス」を参照してください。

ヘルスチェックルールのカスタマイズ

Elastic Beanstalk 拡張ヘルスレポートは、環境のヘルスを判断するための一連のルールに依存しています。これらのルールの一部は、特定のアプリケーションに適していない場合があります。一般的なケースは、設計上頻繁に HTTP 4xx エラーを返すアプリケーションです。Elastic Beanstalk は、デフォルトのルールの 1 つを使用して、何かが間違っていると判断すると、エラーレートに応じて、環境のヘルスステータスを、OK から警告、パフォーマンス低下、または重大へと変化させます。このケースを正しく処理するために、Elastic Beanstalk ではこのルールを設定し、アプリケーション HTTP 4xx エラーを無視できます。詳細については、「環境の拡張ヘルスルールの設定」を参照してください。

拡張ヘルスレポートのロール

拡張ヘルスレポートには、2 つのロールが必要です。Elastic Beanstalk 用のサービスロールと、環境用のインスタンスプロファイルです。サービスロールを使用すると、Elastic Beanstalk はユーザーに代わって他の AWS サービスとやり取りし、環境内のリソースに関する情報を収集できます。インスタンスプロファイルを使用すると、環境内のインスタンスがログを Amazon S3 に書き込んだり、拡張ヘルス情報を Elastic Beanstalk サービスに伝達したりできます。

Elastic Beanstalk コンソールまたは EB を使用して Elastic Beanstalk 環境を作成するとCLI、Elastic Beanstalk はデフォルトのサービスロールを作成し、必要な管理ポリシーを環境のデフォルトのインスタンスプロファイルにアタッチします。

API、、SDKまたは を使用して環境を作成する場合は、これらのロール AWS CLI を事前に作成し、環境の作成時に指定して拡張ヘルスを使用する必要があります。環境に適切なロールを作成する方法については、「」を参照してくださいElastic Beanstalk サービスロール、インスタンスプロファイル、およびユーザーポリシー

インスタンスプロファイルとサービスロールには管理ポリシーを使用することをお勧めします。管理ポリシーは、Elastic Beanstalk が維持する AWS Identity and Access Management （IAM) ポリシーです。管理ポリシーを使用すると、環境が適切に機能するために必要なすべてのアクセス許可を持つことが保証されます。

インスタンスプロファイルでは、ウェブサーバー層またはワーカー層環境に対して、AWSElasticBeanstalkWebTier または AWSElasticBeanstalkWorkerTier 管理ポリシーをそれぞれ使用できます。これら 2 つのマネージドインスタンスプロファイルポリシーの詳細については、「Elastic Beanstalk インスタンスプロファイルの管理」を参照してください。

拡張ヘルス認証

Elastic Beanstalk インスタンスプロファイルマネージドポリシーには、elasticbeanstalk:PutInstanceStatistics アクションに対するアクセス許可が含まれています。このアクションは Elastic Beanstalk の一部ではありませんAPI。これは、環境インスタンスAPIが拡張ヘルス情報を Elastic Beanstalk サービスに伝達するために内部的に使用する別の の一部です。これをAPI直接呼び出すことはありません。

新しい環境を作成すると、elasticbeanstalk:PutInstanceStatistics アクションに対する認証がデフォルトで有効になっています。環境のセキュリティを強化し、ユーザーに代わってヘルスデータのスプーフィングを防ぐために、このアクションに対する認可を有効にしておくことをお勧めします。インスタンスプロファイルでマネージドポリシーを使用する場合、この機能は追加設定なしで新しい環境で使用できます。管理ポリシーの代わりにカスタムインスタンスプロファイルを使用すると、環境に [No Data] (データがありません) のヘルスステータスが表示されることがあります。これは、インスタンスで拡張ヘルスデータをサービスに伝達するアクションが許可されていないために発生します。

アクションを認証するには、インスタンスプロファイルに次のステートメントを含めます。

    {
      "Sid": "ElasticBeanstalkHealthAccess",
      "Action": [
        "elasticbeanstalk:PutInstanceStatistics"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:elasticbeanstalk:*:*:application/*",
        "arn:aws:elasticbeanstalk:*:*:environment/*"
      ]
    }

現時点では拡張ヘルス認証を使用しない場合は、aws:elasticbeanstalk:healthreporting:system 名前空間の EnhancedHealthAuthEnabled オプションを false に設定して無効にします。このオプションが無効になっている場合、前述のアクセス許可は必要ありません。アプリケーションと環境への最小特権アクセスのために、これらをインスタンスプロファイルから削除できます。

注記

以前の EnhancedHealthAuthEnabled のデフォルト設定は false であったため、elasticbeanstalk:PutInstanceStatistics アクションに対する認可でもデフォルトでは無効となっています。既存の環境でこのアクションを有効にするには、aws:elasticbeanstalk:healthreporting:system 名前空間の EnhancedHealthAuthEnabled オプションを true に設定します。このオプションは、設定ファイルのオプション設定を使用して設定できます。

拡張ヘルスレポートのイベント

拡張ヘルスレポートのシステムでは、環境の状態が変化するとイベントが生成されます。次の例は、環境の状態が Info、OK、Severe の間で変化した場合に出力されたイベントを示しています。

現在より悪い状態に変化した場合は、変化の原因を示すメッセージが拡張ヘルスイベントに含められます。

インスタンスレベルでのステータスの変化がすべて Elastic Beanstalk によるイベントの出力になるわけではありません。Elastic Beanstalk では、誤ったアラームを回避するために、複数のチェックで同じ問題が生じている場合のみ、状態に関連したイベントを出力します。

ステータス、色、原因などの環境レベルのリアルタイムのヘルス情報は、Elastic Beanstalk コンソールの環境概要ページと EB CLIで確認できます。EB をCLI環境にアタッチして eb health コマンドを実行することで、環境内の各インスタンスのリアルタイムステータスを表示することもできます。

更新、デプロイ、およびスケーリング中の拡張ヘルスレポートの動作

拡張ヘルスレポートを有効にすると、設定更新中およびデプロイ中の環境の動作に影響が及ぶ可能性があります。Elastic Beanstalk は、すべてのインスタンスが一貫してヘルスチェックに合格するまで、更新のバッチを完了しません。また、拡張ヘルスレポートはヘルスにより高い標準を適用し、より多くの要因を監視するため、基本的なヘルスレポートのELBヘルスチェックに合格したインスタンスは、必ずしも拡張ヘルスレポートに合格するとは限りません。ヘルスチェックがアップデート処理にどのように影響するかについては、ローリング設定更新およびローリングデプロイのトピックを参照してください。

拡張ヘルスレポートでは、Elastic Load Balancing の適切なヘルスチェックURLを設定する必要性も強調できます。環境が需要に合わせてスケールアップすると、新しいインスタンスは十分なELBヘルスチェックに合格するとすぐにリクエストの受け取りを開始します。ヘルスチェックが設定されURLていない場合、新しいインスタンスがTCP接続を受け入れるまで 20 秒程度かかることがあります。

ロードバランサーによってアプリケーションが正常であり、トラフィックを受け取っても問題がないと宣言されるまでにアプリケーションの起動が終了していない場合、大量のリクエストが失敗し、環境がヘルスチェックに合格しなくなります。アプリケーションが提供するパスURLにヘルスチェックがヒットすると、この問題を防ぐことができます。ELB ヘルスチェックへのGETリクエストが 200 ステータスコードをURL返すまで、ヘルスチェックは成功しません。