View a markdown version of this page

Elastic Beanstalk 環境のデプロイログの表示 - AWS Elastic Beanstalk

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

Elastic Beanstalk 環境のデプロイログの表示

Elastic Beanstalk は、環境へのデプロイごとにデプロイログを生成します。デプロイログは、デプロイ中に何が起こったかの統合ビューを提供するため、複数のログを自分で収集することなく障害を診断できます。ログに含まれる内容と利用可能になるタイミングは、環境が Beanstalk Standard 環境か Beanstalk クラスター環境かによって異なります。

Beanstalk Standard では、デプロイログは各インスタンスにローカルに書き込まれます。コンソール、CLI、API、またはマネージド更新を介してトリガーされたデプロイの場合、1 つのインスタンスはデプロイ中にログを Amazon S3 に継続的にアップロードします。Elastic Beanstalk コンソールは Amazon S3 からログを読み取るため、インスタンスに接続せずに進行状況をモニタリングできます。

標準デプロイログは簡潔に設計されています。成功すると、ログには概要メッセージ (実行および完了したコマンドなど) のみが表示されます。失敗した場合、ログには失敗したステップから最大 50 行の出力が含まれるため、詳細な出力をふるい分けることなくエラーを確認できます。

Beanstalk クラスターでは、Elastic Beanstalk はオペレーションの完了後にデプロイログを収集します。環境内のすべてのポッドのコンテナログを環境の名前空間の Kubernetes イベントとともに収集し、単一の zip ファイルとして環境の Amazon S3 ストレージバケットにアップロードします。Elastic Beanstalk コンソールは Amazon S3 から zip ファイルを読み取り、その内容を表示するため、クラスターに接続せずに読み取ることができます。可用性はプラットフォームバージョンに依存しず、Elastic Beanstalk はデプロイログファイルをノードに書き込みません。

注記

Beanstalk Standard 環境の場合、デプロイログは、2026 年 3 月 11 日以降にリリースされた Amazon Linux 2 および Amazon Linux 2023 プラットフォームバージョン、および 2026 年 4 月 22 日以降にリリースされた Windows プラットフォームバージョンで利用できます。 https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2026-03-11-al2023.html

サポートされているオペレーション

Beanstalk Standard 環境では、次のオペレーションのデプロイログが生成されます。

  • アプリケーションのデプロイ — 環境に新しいアプリケーションバージョンをデプロイします。

  • 設定の更新 – 既存のインスタンスに適用される環境設定の変更、および環境に新しいインスタンスを追加する更新。

  • 環境の作成 – 新しい環境を作成するときの最初のデプロイ。

  • アプリケーションサーバーの再起動 – インスタンスでアプリケーションサーバーを再起動します。

  • マネージドプラットフォームの更新 – スケジュールされたメンテナンスウィンドウ中に Elastic Beanstalk が自動的に適用するプラットフォームの更新。

ログのリクエスト、CNAMEs のスワップ、タグの更新など、インスタンスのアプリケーションまたは設定状態を変更しないオペレーションは、デプロイログを生成しません。

Beanstalk クラスター環境の場合、デプロイログは環境の作成、アプリケーションのデプロイ、設定の更新、アプリケーションサーバーの再起動、環境の終了のために生成されます。環境を終了すると、Beanstalk Standard にはないデプロイログが生成されます。Beanstalk クラスター環境はプラットフォームバージョンではなくコンテナイメージを実行するため、マネージドプラットフォームの更新は適用されません。

Elastic Beanstalk は、デプロイステップの後に Beanstalk クラスター環境のデプロイログを収集します。コンテナイメージの構築、クラスターの作成、リソースのプロビジョニング、Kubernetes 仕様の生成など、そのステップの前にオペレーションが失敗した場合、デプロイログはなく、環境のイベントは何が起こったかを記述します。詳細については、「Elastic Beanstalk 環境のイベントストリームの表示」を参照してください。

デプロイログの内容

Beanstalk Standard 環境の場合、デプロイログにはデプロイ中に次の情報がキャプチャされます。

  • デプロイライフサイクル – や など、各デプロイフェーズの開始Starting Application deploymentメッセージと完了メッセージCompleted Application deployment。

  • .ebextensions output – 成功すると、実行されたコマンドの名前。失敗した場合、問題の診断に役立つ最後の 50 行のcfn-init出力。

  • プラットフォームフック出力 – 成功すると、実行されたフックスクリプトの名前。失敗した場合、フック出力の最後の 50 行。

  • 依存関係のインストール — npm install、pip install、、 などのパッケージマネージャーからの出力composer installbundle install。成功すると、完了メッセージのみがログに記録されます。失敗した場合、出力の最後の 50 行が含まれます。

  • ビルド出力 – docker build、go build、Java ビルドなどのビルドコマンドからの出力。失敗した場合、出力の最後の 50 行が含まれます。

  • アプリケーション起動出力 – 起動後のアプリケーションからの初期出力。ソースはプラットフォームによって異なります。

    • Docker – docker logsまたは からのコンテナログ docker compose logs

    • Java SE、Go、Node.js、Python、Ruby、.NET – stdout ログを処理する

    • Tomcat – Catalina ログ出力

    • PHP – PHP-FPM マスターとプールのエラーログ

    • ECS – 各タスクコンテナからのコンテナログ

    注記

    アプリケーション出力は、アプリケーションの起動から 2 秒後にキャプチャされます。初期起動メッセージのみが含まれます。アプリケーションが出力の生成に時間がかかる場合、デプロイログには表示されません。完全なアプリケーションログを表示するには、バンドルログをリクエストするか、インスタンスに直接接続します。詳細については、「インスタンスログの表示」を参照してください。

デプロイステップが失敗すると、ログはそれを でマーク[ERROR]し、失敗したステップから最大 50 行の出力を含めます。デプロイログに十分な詳細が含まれていない場合は、 ログタブから完全なインスタンスログ (eb-engine.log、eb-hooks.log、およびアプリケーションログを含む) を取得できます。詳細については、「Elastic Beanstalk 環境の Amazon EC2 インスタンスからのログの表示」を参照してください。

Beanstalk クラスター環境のデプロイログの内容

Beanstalk クラスター環境の場合、デプロイログは zip ファイルです。環境全体のイベントファイルとポッドごとに 1 つのファイルを 1-environment/ ディレクトリに保持します。

1-environment/ _k8Events.txt pod-name.txt

_k8Events.txt は、スケジューリング、ボリューム、スケーリング、ロードバランサーイベントなど、単一のポッドに関連付けられていない Kubernetes イベントを環境の名前空間に保持します。先頭のアンダースコアが最初にソートされます。

各 は、最初にそのポッドのイベントを保持する =====EVENTS===== ブロックでpod-name.txt始まり、その後にポッド内の各コンテナのログを保持する =====LOGS=====ブロックが続きます。Init コンテナは独自のコンテナブロックとして表示されるため、init コンテナが失敗すると、2 番目の問題ではなく、アプリケーションコンテナの空のログが予期されます。

再起動するコンテナの場合、そのポッドの =====EVENTS===== ブロックは理由 (例: BackOff) を命名し、 =====LOGS=====ブロックは収集時のコンテナのログを保持します。コンテナの以前のインスタンスのログは含まれません。

各コンテナのログは 5 MiB に制限されており、行数に制限はありません。上限に達するログは切り捨てとしてマークされます。その上限とは別に、オペレーションが成功したか失敗したかにかかわらず、ログからは何も削除されません。Elastic Beanstalk が 1 つのコンテナのログを読み取れない場合、コレクションは続行され、そのコンテナのブロックにエラーが記録されます。

依存関係のインストールとビルドの出力は、Beanstalk クラスター環境のデプロイログにはありません。これらは、Elastic Beanstalk がコンテナイメージを構築するときに発生します。詳細については、「Beanstalk クラスター環境のコンテナイメージの構築」を参照してください。

コンソールでのデプロイログの表示

Elastic Beanstalk コンソールには、デプロイ履歴とログを表示できるデプロイタブが環境ダッシュボードに表示されます。デプロイ履歴には、過去 42 日間 (6 週間) のデプロイが表示されます。

デプロイ履歴の表示

デプロイ履歴を表示するには
  1. Elastic Beanstalk コンソールを開き、リージョンリストで を選択します AWS リージョン。

  2. ナビゲーションペインで、[環境] を選択し、リストから環境の名前を選択します。

  3. 環境ダッシュボードで、デプロイタブを選択します。

    デプロイタブには、環境のデプロイのテーブルが表示されます。各行には以下の情報が含まれます。

    • リクエスト ID – デプロイの一意の識別子。

    • ステータス – 成功、失敗、または進行中。

    • タイプ – 環境の作成、アプリケーションのデプロイ、設定の更新、マネージドプラットフォームの更新、アプリケーションサーバーの再起動、環境の再構築、環境の復元、環境ドメインのスワップ、環境の終了などのデプロイタイプ。

    • ポリシー – 一度にすべて、ローリング、追加のバッチによるローリング、イミュータブル、トラフィック分割などのデプロイポリシー。

    • 開始時刻 – デプロイが開始された時刻。

    • 期間 – デプロイの完了にかかった時間。

デプロイが進行中の場合、タブは自動的に更新をポーリングします。更新ボタンを選択して、リストを手動で再ロードすることもできます。

デプロイの詳細とログの表示

デプロイの詳細を表示するには
  1. デプロイタブで、検査するデプロイのリクエスト ID リンクを選択します。

  2. デプロイの詳細ページには、リクエスト ID、ステータス、デプロイタイプ、開始時刻、期間、デプロイポリシーを含む概要セクションが表示されます。デプロイポリシー (一度にすべて、ローリング、追加のバッチによるローリング、イミュータブル、トラフィック分割など) は、デプロイイベントから決定できるときに表示されます。

  3. 概要の下で、次のいずれかのタブを選択します。

    • イベント – このデプロイに関連するイベントのタイムライン。選択したデプロイのイベントのみを表示するようにフィルタリングされます。

    • デプロイログ – インスタンスからの統合デプロイログ。ログレベルによる検索、フィルタリング、ログファイルのダウンロードを行うことができます。

Beanstalk Standard 環境で進行中のデプロイの場合、ログタブは自動的に更新され、書き込まれた新しいログエントリが表示されます。デプロイが完了すると、コンソールは最終的なログ状態を取得し、完全な出力を確認します。

Beanstalk クラスター環境の場合、デプロイログはオペレーションの完了後に表示されるため、オペレーションの実行中にログタブが更新されません。環境全体のイベントファイルが最初に表示され、その後にポッドごとのファイルが表示されます。圧縮された zip ファイルが 5 MiB を超える場合、コンソールは表示せずに Amazon S3 からダウンロードするよう求めます。この制限は、単一のコンテナのログではなく、アーカイブ全体に適用されます。

重要

コンソールでデプロイログを表示するには、環境の Amazon S3 ストレージバケット () に対するs3:GetObjectアクセス許可が必要ですelasticbeanstalk-region-account-id。IAM ポリシーにこのアクセス許可が含まれていない場合、デプロイ履歴とイベントは引き続き使用できますが、ログタブにエラーが表示されます。

デプロイログが保存される場所

Beanstalk Standard インスタンスのデプロイログファイル

デプロイログは、各インスタンスの /var/log/deployments/ ディレクトリに書き込まれます。ログファイル名は、デプロイのトリガー方法によって異なります。

  • ワークフロー制御のデプロイ (コンソール、CLI、または API を介してトリガー) – eb-deployment-request-id.log。request-id は一意のデプロイリクエスト ID です。

  • 自己起動デプロイ (インスタンス起動) – eb-deployment-timestamp-instance-id.log。タイムスタンプは UTC 形式 (例: 20260317T151315Z) で、instance-id は Amazon EC2 インスタンス ID です。

Elastic Beanstalk はこれらのファイルを自動的にローテーションし、各インスタンスの最新のデプロイログを 50 個保持します。

ワークフロー制御のデプロイの場合、ログは次のパスで Amazon S3 にアップロードされます。

s3://elasticbeanstalk-region-account-id/resources/environments/logs/deployments/environment-id/log-filename

自己起動デプロイの場合、ログはselfstartup/サブディレクトリの Amazon S3 にアップロードされます。

s3://elasticbeanstalk-region-account-id/resources/environments/logs/deployments/environment-id/selfstartup/log-filename

ワークフロー制御のデプロイの場合、アップロードを開始する最初のインスタンスはデプロイ全体のロールを要求します。そのインスタンスは、デプロイの期間中、ログを Amazon S3 にアップロードします。自己起動デプロイの場合、各インスタンスは独自のログを個別にアップロードします。すべてのインスタンスは、引き続きデプロイログをローカルに書き込みます。

重要

Amazon S3 にデプロイログをアップロードするには、インスタンスプロファイル内の環境の Amazon S3 ストレージバケットに対するs3:PutObjectアクセス許可が必要であり、VPC 設定では Amazon S3 への接続を許可する必要があります。

デプロイログのアップロードは、ファイルあたり 1 MB に制限されます。デプロイログがこのサイズを超えると、アップロードされたバージョンは、インスタンスで完全なログが使用可能であることを示すメッセージで切り捨てられます。

S3 ログアップロードの無効化

Beanstalk Standard 環境では、デプロイログが Amazon S3 にアップロードされないようにするには、環境に次の環境プロパティを設定します。

option_settings: - namespace: aws:elasticbeanstalk:application:environment option_name: EB_DEPLOYMENT_LOG_S3_DISABLED value: true

この環境プロパティを設定すると、デプロイログは各インスタンス/var/log/deployments/の にローカルに書き込まれますが、Amazon S3 にアップロードされず、コンソールのデプロイタブでは使用できません。このプロパティは、ソフトウェアの設定ページ、または EB CLI または を使用して設定することもできます AWS CLI。

EB_DEPLOYMENT_LOG_S3_DISABLED プロパティはインスタンスで読み取られるため、Beanstalk クラスター環境には影響しません。現在、Elastic Beanstalk が Beanstalk クラスター環境のデプロイログをアップロードできないようにする方法はありません。

Beanstalk クラスター環境のデプロイログファイル

Beanstalk クラスター環境の場合、Elastic Beanstalk は次のパスでデプロイログを環境の Amazon S3 ストレージバケットにアップロードします。

s3://elasticbeanstalk-region-account-id/resources/environments/logs/deployments/environment-id/deployment-environment-name-request-id.zip

Elastic Beanstalk は環境のオペレーションロールを使用してアップロード自体を実行するため、インスタンスプロファイルのアクセス許可は関係せず、ノードから Amazon S3 に到達する必要はありません。

アップロードはベストエフォートです。成功しない場合、オペレーションは完了し、環境イベントは生成されず、コンソールはデプロイログを使用不可として報告します。