Elastic Beanstalk 環境のトラブルシューティング - AWS Elastic Beanstalk
Systems Manager ツールの使用一般的な質問、または機能要望シークレットの環境変数環境の作成デプロイ健康デュアルスタック設定済みロードバランサー設定Dockerよくある質問デプロイのトラブルシューティングデプロイエラー

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Elastic Beanstalk 環境のトラブルシューティング

この章では、Elastic Beanstalk 環境の問題をトラブルシューティングするためのガイダンスを提供します。この情報には以下が含まれます。

  • AWS Systems Manager の概要。トラブルシューティングのステップと推奨事項を出力する事前定義された Elastic Beanstalk ランブックを実行する手順が含まれます。

  • 環境ステータスが低下したときに使用するアクションとリソースに関する一般的なガイダンス。

  • カテゴリ別に整理された特定のトラブルシューティングのヒント。

環境の状態が赤に変わった場合は、まず事前定義されたランブックを含む AWS Systems Manager ツールを使用して Elastic Beanstalk のトラブルシューティングを行うことをお勧めします。詳細については、「 Systems Manager ツールの使用」を参照してください。

AI アシストによるトラブルシューティングのために Amazon Q Developer CLI を試す

Amazon Q Developer CLI は、環境の問題を迅速にトラブルシューティングするのに役立ちます。Q CLI は、環境ステータスの確認、イベントの確認、ログの分析、明確な質問を行うことでソリューションを提供します。詳細と詳細なチュートリアルについては、 AWS ブログの「Amazon Q Developer CLI を使用した Elastic Beanstalk 環境のトラブルシューティング」を参照してください。

AWS Systems Manager Elastic Beanstalk ランブックの使用

Systems Manager を使用して Elastic Beanstalk 環境のトラブルシューティングを行うことができます。Systems Manager は、お客様にすぐに使用を開始していただけるように、Elastic Beanstalk 用に事前定義されたオートメーションランブックを用意しています。オートメーションランブックは、環境のインスタンスやその他の  AWS  リソースで実行するアクションを定義する Systems Manager ドキュメントの一種です。

このドキュメント AWSSupport-TroubleshootElasticBeanstalk は、Elastic Beanstalk 環境のパフォーマンスが低下する可能性のある一般的な問題をいくつか特定するのに役立つように設計されたオートメーションランブックです。そうするためには、EC2 インスタンス、VPC、 AWS CloudFormation  スタック、ロードバランサー、Auto Scaling グループ、セキュリティグループルール、ルートテーブル、ACL に関連するネットワーク設定など、環境のコンポーネントをチェックします。

また、バンドルされたログファイルを環境から  AWS  サポートにアップロードするオプションもあります。

詳細についてはAWS Systems Manager 「 自動 ランブックリファレンス」のAWSSupport-TroubleshootElasticBeanstalkを参照してください。

Systems Manager を使用して AWSSupport-TroubleshootElasticBeanstalk ランブックを実行する
注記

この手順は、Elastic Beanstalk 環境 AWS リージョン があるのと同じ で実行します。

  1. AWS Systems Manager コンソールを開きます。

  2. ナビゲーションペインの [変更管理] で、[オートメーション] を選択します。

  3. [Execute automation (自動化の実行)] を選択してください。

  4. [Amazon が所有] タブの[オートメーションドキュメント] 検索ボックスに、「AWSSupport-TroubleshootElasticBeanstalk」を入力します。

  5. [AWSSupport-TroubleshootElasticBeanstalk] カードを選択してから、[次へ] を選択します。

  6. [実行] を選択します。

  7. [入力パラメータ] セクションで、以下の操作を行います。

    1. [AutomationAssumeRole] ドロップダウンから、System Manager がユーザーに代わってアクションを実行できるようにするロールの ARN を選択します。

    2. [ApplicationName] に、Elastic Beanstalk アプリケーションの名前を入力します。

    3. [環境名] には、Elastic Beanstalk 環境を入力します。

    4. （オプション) S3UploaderLink の場合、 AWS サポートエンジニアからログ収集用の S3 リンクが提供されている場合は、リンクを入力します。

  8. [実行] を選択してください。

    いずれかのステップが失敗した場合は、失敗したステップの [ステップ ID] 列の下にあるリンクを選択します。これにより、ステップの [実行詳細] ページが表示されます。[VerificationErrorMessage] セクションには、注意が必要な手順の概要が表示されます。たとえば、IAMPermissionCheck には警告メッセージが表示される場合があります。この場合、[AutomationAssumeRole] ドロップダウンで選択したロールに必要な権限があるかどうかを確認できます。

すべての手順が正常に完了すると、出力にはトラブルシューティングの手順および環境を正常な状態に復元するための推奨事項が表示されます。

Elastic Beanstalk 環境のトラブルシューティングに関する一般的なガイダンス

エラー メッセージは、コンソールの [イベント] ページ、ログ、または [ヘルス] ページに表示されることがあります。また、最近の変更によってパフォーマンスが低下した環境から回復するための対策を講じることもできます。対象環境のヘルスステータスが「赤色」に変わった場合は、以下の操作を試してください。

  • 環境の オペレーションがテキスト を含むエラーを返す場合はThe stack stack_id associated with environment environment-ID is in stack-status state、トラブルシューティングのヘルプElastic Beanstalk 環境を無効な状態から復旧するについて「」を参照してください。

  • 環境の オペレーションがテキスト を含むエラーを返した場合はEnvironment environment-name associated CloudFormation stack stack_arn does not exist、環境を終了して別のオペレーションを作成します。

  • 最新の環境イベントを確認します。デプロイ、負荷、設定の問題に関する Elastic Beanstalk からのメッセージは、多くの場合、ここに表示されています。

  • 最近の、環境に関する変更履歴を確認します。変更履歴には、環境に加えられたすべての設定変更の内容がリストされています。さらに、変更を行った IAM ユーザーや、設定が行われたパラメータなど、その他の情報も含まれています。

  • ログをプルして、最新のログファイルエントリを表示します。ウェブサーバーのログには、受信リクエストおよびエラーに関する情報が含まれています。

  • インスタンスに接続し、システムリソースをチェックします。

  • アプリケーションの以前の稼働バージョンにロールバックします。

  • 最新の設定変更を元に戻すか、保存した設定を復元します。

  • 新しい環境をデプロイします。この新しい環境に特に問題がないと確認できたら、CNAME スワップを実行してその環境にトラフィックをルーティングし、以前の環境のデバッグを続けます。

環境変数を使用してシークレットとパラメータにアクセスする環境

イベント： インスタンスのデプロイで 1 つ以上のシークレットを取得できませんでした

このメッセージは、Elastic Beanstalk がアプリケーションのデプロイ中に指定された 1 つ以上のシークレットを取得できなかったことを示します。

  • 環境変数設定の ARN 値で指定されたリソースが存在することを確認します。

  • Elastic Beanstalk EC2 インスタンスプロファイルロールに、リソースにアクセスするために必要な IAM アクセス許可があることを確認します。

  • このイベントが RestartAppServerオペレーションによってトリガーされた場合、問題が修正されたら、RestartAppServer呼び出しを再試行して問題を解決します。

  • イベントが UpdateEnvironment呼び出しによってトリガーされた場合は、 UpdateEnvironmentオペレーションを再試行します。

これらのコマンドの例については、AWS CLI 「Elastic Beanstalk の例」を参照してください。これらのオペレーションの API アクションの詳細については、AWS Elastic Beanstalk 「 API リファレンス」を参照してください。

イベント： インスタンスのデプロイで、このプラットフォームではサポートされていない 1 つ以上の複数行の環境値が検出されました

複数行変数は、Docker および ECS マネージド Docker プラットフォームを除き、Amazon Linux 2 プラットフォームではサポートされていません。続行できるオプションについては、「」を参照してください複数行の値。

イベント： シークレットが指定されると CreateEnvironment が失敗する

がCreateEnvironment失敗し、環境変数としてシークレットがある場合は、根本的な問題に対処してから、 UpdateEnvironment を使用して環境設定を完了する必要があります。このような状況では環境を起動するには十分ではないためRestartAppServer、 を使用しないでください。これらのコマンドの例については、AWS CLI 「Elastic Beanstalk の例」を参照してください。これらのオペレーションの API アクションの詳細については、 AWS Elastic Beanstalk API リファレンスを参照してください。

環境の作成とインスタンスの起動

イベント: 環境を起動できませんでした

このイベントは、Elastic Beanstalk が環境を起動しようとし、その途中でエラーが起こったときに発生します。[イベント] ページの以前のイベントが、この問題の根本的な原因について警告します。

イベント: 環境の作成オペレーションは完了しましたが、コマンドがタイムアウトしました。タイムアウト期間を長くしてみてください。

インスタンス上でコマンドを実行する、大きなファイルをダウンロードする、あるいはパッケージをインストールするために設定ファイルを使用すると、アプリケーションのデプロイに時間がかかる場合があります。コマンドタイムアウトを増やして、デプロイ中にアプリケーションが実行開始できる時間を多くしてください。

イベント: 以下のリソースで [AWSEBInstanceLaunchWaitCondition] を作成できませんでした

このメッセージは、環境の Amazon EC2 インスタンスが、正常に起動した Elastic Beanstalk と通信しなかったことを示します。これは、インスタンスにインターネットの接続がない場合に発生します。プライベート VPC サブネットでインスタンスを起動するように環境を設定した場合は、インスタンスに対して Elastic Beanstalk への接続を許可する NAT がサブネットにあることを確認します。

イベント: このリージョンではサービスロールが必要です。環境にサービスロールオプションを追加してください。

Elastic Beanstalk はサービスロールを使用して環境のリソースをモニタリングし、マネージド型プラットフォーム更新をサポートします。詳細については「Elastic Beanstalk サービスロールの管理」を参照してください。

デプロイ

問題: デプロイ中にアプリケーションが使用不可になります

Elastic Beanstalk はドロップインアップグレードプロセスを使用するため、数秒間のダウンタイムが生じることがあります。ローリングデプロイを使用して、運用環境におけるデプロイの影響を最小化します。

イベント： Elastic Beanstalk AWS アプリケーションバージョンの作成に失敗しました

アプリケーションソースバンドルが大きすぎるか、アプリケーションバージョンクォータに達した可能性があります。

イベント: 環境更新オペレーションは完了しましたが、コマンドがタイムアウトしました。タイムアウト期間を長くしてみてください。

インスタンス上でコマンドを実行する、大きなファイルをダウンロードする、あるいはパッケージをインストールするために設定ファイルを使用すると、アプリケーションのデプロイに時間がかかる場合があります。コマンドタイムアウトを増やして、デプロイ中にアプリケーションが実行開始できる時間を多くしてください。

健康

イベント: CPU 使用率が 95.00％ を超える

実行するインスタンスを増やすか、別のインスタンスタイプを選択してください。

イベント: Elastic Load Balancer awseb-myapp に正常なインスタンスがない

アプリケーションが機能しているようであれば、アプリケーションのヘルスチェック URL が正しく設定されていることを確認します。そうでなければ、[Health] 画面および環境ログで詳細を確認します。

イベント: Elastic Load Balancer awseb-myapp が見つかりません

環境のロードバランサーが帯域外に削除された可能性があります。環境のリソースに対する変更は、Elastic Beanstalk によって提供される設定オプションおよび拡張可能性のみにしてください。環境を再構築するか、新しいインスタンスを起動してください。

イベント: EC2 インスタンス起動エラー。新しい EC2 インスタンスの起動の待機中...

環境のインスタンスタイプの可用性が低いか、アカウントのインスタンスクォータに達した可能性があります。サービスヘルスダッシュボードを調べ、Elastic Compute Cloud (Amazon EC2) サービスが緑色になっていることを確認してください。なっていない場合はクォータの引き上げをリクエストしてください。

デュアルスタックのロードバランサーが設定された環境

イベント： VPC vpc_id には IPv6 CIDR ブロックが設定されていません。デュアルスタックロードバランサーには IPv6 CIDR ブロックが必要です。デュアルスタックモードを使用する前に、IPv6 CIDR ブロックを VPC に関連付けてください。

VPC とすべてのサブネットにはIPv6 CIDR ブロックが関連付けられている必要があります。これは、デュアルスタックのサポート用にロードバランサーを設定する前に完了する必要がある VPC 前提条件の 1 つです。このタスクを完了する方法の詳細については、このトピックの前Amazon VPC の前提条件半の「」を参照してください。

イベント： VPC vpc_id の 1 つ以上のサブネットに IPv6 CIDR ブロックが設定されていません。デュアルスタックロードバランサーで使用されるサブネットには、IPv6 CIDR ブロックが必要です。デュアルスタックモードを使用する前に、IPv6 CIDR ブロックを必要なすべてのサブネットに関連付けてください。

VPC のすべてのサブネットには、IPv6 CIDR ブロックが関連付けられている必要があります。これは、デュアルスタックのサポート用にロードバランサーを設定する前に完了する必要がある VPC 前提条件の 1 つです。このタスクを完了する方法の詳細については、このトピックの前Amazon VPC の前提条件半の「」を参照してください。

エラー： IpAddressTypeオプションは、Application Load Balancer または Network Load Balancer で設定された Elastic Beanstalk 環境にのみ適用されます。

このメッセージは、Elastic Beanstalk 環境が単一のインスタンス環境であるか、Classic Load Balancer を使用している可能性があります。Application Load Balancer または Network Load Balancer で設定された環境のみが を設定できますIpAddressType。

設定

イベント： 環境stack_idに関連付けられたスタックenvironment-IDが stack-status状態です

環境の基盤となる AWS CloudFormation スタックは *_FAILED ステータスの場合があります。環境で Elastic Beanstalk オペレーションを続行するには、このステータスを修正する必要があります。詳細については、「Elastic Beanstalk 環境を無効な状態から復旧する」を参照してください。

イベント: Elastic Load Balancing Target オプションおよび Application Healthcheck URL オプションの値を使用して、Elastic Beanstalk 環境を設定することはできません。

Target 名前空間の aws:elb:healthcheck オプションは廃止されました。Target オプション名前空間を環境から削除してもう一度更新してください。

イベント： ELB を同じ AZ 内の複数のサブネットにアタッチすることはできません

このメッセージは、同じアベイラビリティーゾーン内のサブネット間でロードバランサーを移動しようとすると表示される場合があります。ロードバランサーのサブネットを変更するには、元のアベイラビリティーゾーンの外に移動してから、必要なサブネットを用意した元のアベイラビリティーゾーンに戻す必要があります。この処理中は、すべてのインスタンスは AZ 間で移行されるため、長時間のダウンタイムが発生します。代わりに、新しい環境を作成して CNAME のスワップを実行することを検討してください。

Docker コンテナのトラブルシューティング

イベント: Docker イメージを取得できませんでした :latest: 無効なリポジトリ名です ()。[a-z0-9-_.] のみが許可されています。詳細については、ログを追跡します。

JSON 検証ツールを使用して dockerrun.aws.json ファイルの構文をチェックします。また、「Elastic Beanstalk へのデプロイ用に Docker イメージを準備する」で説明されている要件を参照して dockerfile の内容を確認します。

イベント: Dockerfile に EXPOSE ディレクティブが見つかりません。デプロイを中止します

Dockerfile または dockerrun.aws.json ファイルでコンテナポートが宣言されていません。EXPOSE インストラクション (Dockerfile) または Ports ブロック (dockerrun.aws.json ファイル) を使用して、受信トラフィックに対してポートを開きます。

イベント: バケット名から認証資格情報リポジトリをダウンロードできませんでした

dockerrun.aws.json ファイルは .dockercfg ファイルに無効な EC2 キーペアや S3 バケットを指定します。または、インスタンスプロファイルに S3 バケットの GetObject の権限がありません。.dockercfg ファイルに有効な S3 バケットと EC2 キーペアが含まれていることを確認します。インスタンスプロファイル内の IAM ロールに s3:GetObject 操作を許可します。詳細については、Elastic Beanstalk インスタンスプロファイルの管理 を参照してください

イベント: 以下の理由により、アクティビティの実行に失敗しました。警告: 認証設定ファイルが無効です

認証ファイル（config.json）が正しくフォーマットされていません。「イメージリポジトリを使用した認証」を参照してください。

よくある質問

質問:アプリケーション URL を、myapp.us-west-2.elasticbeanstalk.com から www.myapp.com に変更したい。

DNS サーバーで、www.mydomain.com CNAME mydomain.elasticbeanstalk.com などの CNAME レコードを登録します。

質問: Elastic Beanstalk アプリケーションに特定のアベイラビリティーゾーンを指定できない。

API、CLI、Eclipse プラグイン、または Visual Studio プラグインを使用すると、特定のアベイラビリティーゾーンを指定できます。Elastic Beanstalk コンソールを使用してアベイラビリティーゾーンを指定する方法については、「Elastic Beanstalk 環境インスタンスの Auto Scaling 」を参照してください。

質問: 環境のインスタンスタイプを変更したい

環境のインスタンスタイプを変更するには、[環境設定] ページに移動し、[インスタンス] 設定カテゴリにある [編集] をクリックします。新しいインスタンスタイプを選択し、[適用] をクリックして環境を更新します。その後、実行中のすべてのインスタンスが Elastic Beanstalk により終了され、新しいインスタンスに置き換えられます。

質問: いずれかのユーザーが環境設定を変更したかどうかを知るにはどうすればよいですか?

この情報を表示するには、Elastic Beanstalk コンソールのナビゲーションペインで [変更履歴] をクリックして、すべての環境の設定変更のリストを表示します。このリストから、変更の日時、設定されたパラメータと変更後の値、その変更を行った IAM ユーザーが確認できます。詳細については、「変更履歴」を参照してください。

質問: インスタンスの終了時に Amazon EBS ボリュームが削除されないようにしたい。

環境内のインスタンスは Amazon EBS を使用して保管されますが、Auto Scaling によってインスタンスが終了されると、ルートボリュームが削除されます。ご自身のインスタンス上に、状態やその他のデータを保存することは推奨されません。必要に応じて、「 AWS CLI リファレンス」で説明されている$ aws ec2 modify-instance-attribute -b '/dev/sdc=<vol-id>:falseように、 AWS CLIでボリュームが削除されないようにできます。

質問: Elastic Beanstalk アプリケーションから個人情報を削除したい。

AWS Elastic Beanstalk アプリケーションが使用する リソースは、個人情報を保存する場合があります。環境を終了すると、Elastic Beanstalk で作成されたリソースが終了されます。設定ファイルを使用して、追加したリソースも終了します。ただし、Elastic Beanstalk 環境の外部で AWS リソースを作成し、アプリケーションに関連付ける場合は、アプリケーションが保存した可能性のある個人情報が保持されないように手動で確認する必要がある場合があります。このデベロッパーガイドを通して追加リソースの作成について取り扱う際は、それらの削除を検討する必要がある場合についても必ず言及しています。

共通エラー

このトピックでは、EB CLI の使用時に表示される一般的なエラーメッセージと考えられる解決策を示しています。ここに示していないエラーメッセージが表示される場合は、[フィードバック] リンクを使用してお知らせください。

エラー: Git コマンドの処理中にエラーが発生しました。エラーコード: 128 エラー: 致命的: 有効なオブジェクト名 HEAD ではありません

原因: Git リポジトリを初期化したが、まだコミットしていない場合にこのエラーメッセージが表示されます。プロジェクトフォルダーに Git リポジトリが含まれていると、EB CLI は HEAD リビジョンを検索します。

解決策: ステージングエリアにプロジェクトフォルダ内のファイルを追加してコミットします。

~/my-app$ git add .
~/my-app$ git commit -m "First commit"

エラー: このブランチにはデフォルト環境がありません。「eb status my-env-name」と入力して環境を指定するか、「eb use my-env-name」と入力してデフォルト環境を設定する必要があります。

原因: Git で新しいブランチを作成すると、デフォルトでは Elastic Beanstalk 環境にアタッチされません。

解決策: eb list を実行して、利用可能な環境のリストを表示します。その後、eb use env-name を実行して、利用可能な環境のいずれかを使用します。

エラー: 2.0 以上のプラットフォームにはサービスロールが必要です。サービスロールは、--service-role オプションで指定できます

原因: eb create で環境名 (eb create my-env など) を指定した場合、EB CLI はサービスロールの自動作成を試みません。デフォルトのサービスロールがない場合、上記のエラーが表示されます。

解決策: 環境名を指定しないで eb create を実行し、プロンプトに従ってデフォルトのサービスロールを作成します。

デプロイエラー

Elastic Beanstalk デプロイは、404 (アプリケーションの起動に失敗した場合) または 500 (ランタイムにアプリケーションが失敗した場合) のレスポンスで応答する場合があります。多くの一般的な問題のトラブルシューティングを行うには、EB CLI を使用して、デプロイのステータスの確認、ログの表示、SSH を使用した EC2 インスタンスへのアクセス、またはアプリケーション環境の AWS マネジメントコンソールページを開くことができます。

EB CLI を使用してデプロイのトラブルシューティングを行うには

  1. eb status を実行して、現在のデプロイのステータスおよび EC2 ホストの状態を確認します。例:

    $ eb status --verbose

Environment details for: python_eb_app
  Application name: python_eb_app
  Region: us-west-2
  Deployed Version: app-150206_035343
  Environment ID: e-wa8u6rrmqy
  Platform: 64bit Amazon Linux 2014.09 v1.1.0 running Python 2.7
  Tier: WebServer-Standard-
  CNAME: python_eb_app.elasticbeanstalk.com
  Updated: 2015-02-06 12:00:08.557000+00:00
  Status: Ready
  Health: Green
  Running instances: 1
      i-8000528c: InService
    注記

    --verbose スイッチを使用すると、実行中のインスタンスのステータスに関する情報が表示されます。このスイッチを指定しない場合、eb status では、環境に関する全般的な情報のみが表示されます。

  2. 環境のヘルス情報を表示するには、eb health を実行します。

    $ eb health --refresh
 elasticBeanstalkExa-env                                  Degraded                  2016-03-28 23:13:20
WebServer                                                                              Ruby 2.1 (Puma)
  total      ok    warning  degraded  severe    info   pending  unknown
    5        2        0        2        1        0        0        0

  instance-id   status     cause
    Overall     Degraded  Incorrect application version found on 3 out of 5 instances. Expected version "Sample Application" (deployment 1).
  i-d581497d    Degraded  Incorrect application version "v2" (deployment 2). Expected version "Sample Application" (deployment 1).
  i-d481497c    Degraded  Incorrect application version "v2" (deployment 2). Expected version "Sample Application" (deployment 1).
  i-136e00c0    Severe    Instance ELB health has not been available for 5 minutes.
  i-126e00c1    Ok
  i-8b2cf575    Ok

  instance-id   r/sec    %2xx   %3xx   %4xx   %5xx      p99      p90      p75     p50     p10
    Overall     646.7   100.0    0.0    0.0    0.0    0.003    0.002    0.001   0.001   0.000
  i-dac3f859    167.5    1675      0      0      0    0.003    0.002    0.001   0.001   0.000
  i-05013a81    161.2    1612      0      0      0    0.003    0.002    0.001   0.001   0.000
  i-04013a80    0.0         -      -      -      -         -        -       -       -       -
  i-3ab524a1    155.9    1559      0      0      0    0.003    0.002    0.001   0.001   0.000
  i-bf300d3c    162.1    1621      0      0      0    0.003    0.002    0.001   0.001   0.000

  instance-id   type       az   running     load 1  load 5      user%  nice%  system%  idle%   iowait%
  i-d581497d    t2.micro   1a   25 mins       0.16     0.1        7.0    0.0      1.7   91.0       0.1
  i-d481497c    t2.micro   1a   25 mins       0.14     0.1        7.2    0.0      1.6   91.1       0.0
  i-136e00c0    t2.micro   1b   25 mins        0.0    0.01        0.0    0.0      0.0   99.9       0.1
  i-126e00c1    t2.micro   1b   25 mins       0.03    0.08        6.9    0.0      2.1   90.7       0.1
  i-8b2cf575    t2.micro   1c   1 hour        0.05    0.41        6.9    0.0      2.0   90.9       0.0
  
  instance-id   status     id   version              ago                                  deployments
  i-d581497d    Deployed   2    v2                   9 mins
  i-d481497c    Deployed   2    v2                   7 mins
  i-136e00c0    Failed     2    v2                   5 mins
  i-126e00c1    Deployed   1    Sample Application   25 mins
  i-8b2cf575    Deployed   1    Sample Application   1 hour

    上記の例は、5 つあるインスタンスのうち、3 番目のインスタンスでバージョン「v2」のデプロイに失敗した環境を示しています。デプロイの失敗後、想定されたバージョンは正常にデプロイされた最後のバージョン（この例では、最初のデプロイの「サンプルアプリケーション」）にリセットされます。詳細については「EB CLI を使用した環境ヘルスのモニタリング」を参照してください。

  3. eb logs を実行して、アプリケーションのデプロイに関連付けられたログをダウンロードして表示します。

    $ eb logs

  4. eb ssh を実行して、アプリケーションを実行している EC2 インスタンスに接続し、直接調査します。インスタンスでは、デプロイされたアプリケーションは /opt/python/current/app ディレクトリに、Python 環境は /opt/python/run/venv/ にあります。

  5. eb console を実行して、AWS マネジメントコンソールでアプリケーション環境を表示します。ウェブインターフェイスを使用して、アプリケーションの設定、ステータス、イベント、ログなど、デプロイのさまざまな側面を簡単に調査できます。また、サーバーにデプロイした現在または過去のアプリケーションバージョンをダウンロードすることもできます。