翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Elastic Beanstalk での環境のモニタリング
Elastic Beanstalk ヘルスモニタリングを使用すると、アプリケーションの可用性を検証し、メトリクスがしきい値を超えたときにアクティブ化するアラートを作成できます。コンソールとコマンドラインの両方で Elastic Beanstalk ヘルスモニタリングを使用して、環境のステータスを追跡できます。
**Topics**
+ [AWS マネジメントコンソールでの環境の状態のモニタリング](environment-health-console.md)
+ [EB CLI を使用した環境ヘルスのモニタリング](health-enhanced-ebcli.md)
+ [ベーシックヘルスレポート](using-features.healthstatus.md)
+ [Elastic Beanstalk の拡張ヘルスレポートおよびモニタリング](health-enhanced.md)
+ [アラームを管理する](using-features.alarms.md)
+ [Elastic Beanstalk 環境の変更履歴の表示](using-features.changehistory.md)
+ [Elastic Beanstalk 環境のイベントストリームの表示](using-features.events.md)
+ [サーバーインスタンスの一覧表示と接続](using-features.ec2connect.md)
+ [Elastic Beanstalk 環境の Amazon EC2 インスタンスからのログの表示](using-features.logging.md)
+ [Elastic Beanstalk 環境のデプロイログの表示](environments-deployment-logs.md)
# AWS マネジメントコンソールでの環境の状態のモニタリング
Elastic Beanstalk コンソールからアプリケーションの動作情報にアクセスできます。コンソールは、環境の状態とアプリケーションの状態を一目で分かるように表示します。コンソールの [**環境**] ページおよび各アプリケーションのページで、リスト上の環境はステータスを示すために色分けされています。
**Elastic Beanstalk コンソールで環境を監視するには**
1. [Elastic Beanstalk コンソール](https://console.aws.amazon.com/elasticbeanstalk)を開き、**リージョン**リストで を選択します AWS リージョン。
1. ナビゲーションペインで、[**環境**] を選択し、リストから環境の名前を選択します。
1. ナビゲーションペインで、[**モニタリング**] を選択します。
[Monitoring] ページには、環境全体の統計（CPU 使用率や平均レイテンシー）が表示されます。全体の統計に加え、時間ごとのリソース使用率を示すモニタリンググラフも表示されます。グラフの任意の場所をクリックして、詳細情報を表示できます。
**注記**
デフォルトでは、基本的な CloudWatch メトリクスだけが有効化されていて、5 分周期でデータを返します。環境の設定を変更することで、より粒度の高い、1 分単位の CloudWatch メトリクスを有効化することもできます。
## モニタリンググラフ
**[モニタリング]** ページには、環境のヘルスに関連するメトリクスの概要が表示されます。これには、Elastic Load Balancing と Amazon EC2 によって提供されるデフォルトのメトリクスのセット、および環境の状態が時間の経過とともにどのように変化したかを示すグラフが含まれます。
グラフの上のバーには、選択できるさまざまな時間間隔が表示されます。例えば、先週の情報を表示するには、**[1w]** を選択します。または、**[3h]** を選択すると、過去 3 時間の情報が表示されます。
より幅広く時間間隔を選択するには、**[カスタム]** を選択します。ここからは、*[絶対]* または *[相対]* という 2 つの範囲オプションがあります。**[絶対]** オプションを使用すると、*2023 年 1 月 1 日から 2023 年 6 月 30 日*など、特定の日付範囲を指定できます。**[相対]** オプションを使用すると、特定の時間単位 (*[分]*、*[時間]*、*[日]*、*[週]*、または *[月]*) で整数を選択できます。*[10 時間]*、*[10 日]*、*[10 か月]* などです。
![\[Elastic Beanstalk コンソールの環境モニタリングページにある環境のヘルスモニタリングセクション\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/environment-monitoring-graphs.png)
## モニタリングコンソールのカスタマイズ
カスタムメトリクスを作成および表示するには、Amazon CloudWatch を使用する必要があります。CloudWatch を使用すると、単一のビューでリソースをモニタリングするために、カスタムダッシュボードを作成できます。**[ダッシュボードに追加]** を選択して、**[モニタリング]** ページから Amazon CloudWatch コンソールに移動します。Amazon CloudWatch では、新しいダッシュボードを作成するか、既存のダッシュボードを選択できます。詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」を参照してください。
![\[Elastic Beanstalk コンソールの環境モニタリングページにある環境のヘルスモニタリングセクション\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/environment-monitoring-graphs.png)
[Elastic Load Balancing](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/elb-metricscollected.html) と [Amazon EC2](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/ec2-metricscollected.html) メトリクスは、すべての環境で有効になります。
[強化ヘルス](health-enhanced.md)を使用すると、EnvironmentHealth メトリクスが有効になり、グラフが 1 つモニタリングコンソールに自動的に追加されます。拡張ヘルスでは、マネジメントコンソールに [[Health] ページ](health-enhanced-console.md#health-enhanced-console-healthpage)も追加されます。強化ヘルスメトリクスのリストについては、「[環境の Amazon CloudWatch カスタムメトリクスの発行](health-enhanced-cloudwatch.md)」を参照してください。
# EB CLI を使用した環境ヘルスのモニタリング
[Elastic Beanstalk コマンドラインインターフェイス](eb-cli3.md) (EB CLI) は、 AWS Elastic Beanstalk 環境を管理するためのコマンドラインツールです。EB CLI では、環境の状態をリアルタイムで、現在の Elastic Beanstalk コンソールより細かくモニタリングすることもできます。
EB CLI を[インストール](eb-cli3.md#eb-cli3-install)し、[設定](eb-cli3-configuration.md)したら、**eb create** コマンドを使用して、新しい環境を起動し、それにコードをデプロイできます。Elastic Beanstalk コンソールで既に環境を作成している場合は、プロジェクトフォルダ (空でも問題ありません) で **eb init** を実行し、プロンプトに従うことによって、その環境に EB CLI をアタッチできます。
**重要**
`pip install` オプションを付けて `--upgrade` を実行し、EB CLI の最新バージョンを使用していることを確認します。
```
$ sudo pip install --upgrade awsebcli
```
EB CLI の詳細なインストール手順については、「[セットアップスクリプトを使用して EB CLI をインストールする (推奨)](eb-cli3.md#eb-cli3-install)」を参照してください。
EB CLI を使用して対象環境のヘルスステータスを監視するには、**eb init** を実行して画面の指示に従うことで、まず、ローカルのプロジェクトフォルダを設定する必要があります。詳細な手順については、「[EB CLI の設定](eb-cli3-configuration.md)」を参照してください。
Elastic Beanstalk で既に環境が実行されており、EB CLI を使用してその状態をモニタリングする場合は、既存の環境を使用するために、以下のステップに従って、それに EB CLI をアタッチします。
**EB CLI を既存の環境にアタッチするには**
1. コマンドラインターミナルを開き、ユーザーフォルダに移動します。
1. 対象環境用に新しいフォルダを作成して開きます。
1. **eb init** コマンドを実行し、モニタリングするアプリケーションと環境を選択します。選択したアプリケーションを実行している環境が 1 つしかない場合、EB CLI は自動的にそれを選択するので、次の例に示すように、手動で環境を選択する必要はありません。
```
~/project$ eb init
Select an application to use
1) elastic-beanstalk-example
2) [ Create new Application ]
(default is 2): 1
Select the default environment.
You can change this later by typing "eb use [environment_name]".
1) elasticBeanstalkEx2-env
2) elasticBeanstalkExa-env
(default is 1): 1
```
**EB CLI を使用して状態をモニタリングするには**
1. コマンドラインを開き、ユーザーフォルダに移動します。
1. **eb health** コマンドを実行して、お客様の環境内のインスタンスのヘルスステータスを表示します。この例では、5 つのインスタンスが Linux 環境内で実行されています。
```
~/project $ eb health
elasticBeanstalkExa-env Ok 2015-07-08 23:13:20
WebServer Ruby 2.1 (Puma)
total ok warning degraded severe info pending unknown
5 5 0 0 0 0 0 0
instance-id status cause health
Overall Ok
i-d581497d Ok
i-d481497c Ok
i-136e00c0 Ok
i-126e00c1 Ok
i-8b2cf575 Ok
instance-id r/sec %2xx %3xx %4xx %5xx p99 p90 p75 p50 p10 requests
Overall 671.8 100.0 0.0 0.0 0.0 0.003 0.002 0.001 0.001 0.000
i-d581497d 143.0 1430 0 0 0 0.003 0.002 0.001 0.001 0.000
i-d481497c 128.8 1288 0 0 0 0.003 0.002 0.001 0.001 0.000
i-136e00c0 125.4 1254 0 0 0 0.004 0.002 0.001 0.001 0.000
i-126e00c1 133.4 1334 0 0 0 0.003 0.002 0.001 0.001 0.000
i-8b2cf575 141.2 1412 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% cpu
i-d581497d t2.micro 1a 12 mins 0.0 0.04 6.2 0.0 1.0 92.5 0.1
i-d481497c t2.micro 1a 12 mins 0.01 0.09 5.9 0.0 1.6 92.4 0.1
i-136e00c0 t2.micro 1b 12 mins 0.15 0.07 5.5 0.0 0.9 93.2 0.0
i-126e00c1 t2.micro 1b 12 mins 0.17 0.14 5.7 0.0 1.4 92.7 0.1
i-8b2cf575 t2.micro 1c 1 hour 0.19 0.08 6.5 0.0 1.2 92.1 0.1
instance-id status id version ago deployments
i-d581497d Deployed 1 Sample Application 12 mins
i-d481497c Deployed 1 Sample Application 12 mins
i-136e00c0 Deployed 1 Sample Application 12 mins
i-126e00c1 Deployed 1 Sample Application 12 mins
i-8b2cf575 Deployed 1 Sample Application 1 hour
```
この例では、1 つのインスタンスが Windows 環境内で実行されています。
```
~/project $ eb health
WindowsSampleApp-env Ok 2018-05-22 17:33:19
WebServer IIS 10.0 running on 64bit Windows Server 2016/2.2.0
total ok warning degraded severe info pending unknown
1 1 0 0 0 0 0 0
instance-id status cause health
Overall Ok
i-065716fba0e08a351 Ok
instance-id r/sec %2xx %3xx %4xx %5xx p99 p90 p75 p50 p10 requests
Overall 13.7 100.0 0.0 0.0 0.0 1.403 0.970 0.710 0.413 0.079
i-065716fba0e08a351 2.4 100.0 0.0 0.0 0.0 1.102* 0.865 0.601 0.413 0.091
instance-id type az running % user time % privileged time % idle time cpu
i-065716fba0e08a351 t2.large 1b 4 hours 0.2 0.1 99.7
instance-id status id version ago deployments
i-065716fba0e08a351 Deployed 2 Sample Application 4 hours
```
## 出力の読み取り
出力は、環境の名前、環境の総合的な状態、および現在の日付を画面の上部に表示します。
```
elasticBeanstalkExa-env Ok 2015-07-08 23:13:20
```
その次の 3 行には、環境のタイプ (ここでは "WebServer")、設定 (Ruby 2.1 with Puma)、および 7 つの状態にあるインスタンスの数が表示されます。
```
WebServer Ruby 2.1 (Puma)
total ok warning degraded severe info pending unknown
5 5 0 0 0 0 0 0
```
出力の残りは 4 つのセクションに分かれています。最初のセクションには、環境全体と各インスタンスの*ステータス*とそのステータスの*原因*が表示されます。以下の例は、環境内のステータスが `Info` である 2 つのインスタンスと、デプロイが開始されたことを示す原因を示しています。
```
instance-id status cause health
Overall Ok
i-d581497d Info Performing application deployment (running for 3 seconds)
i-d481497c Info Performing application deployment (running for 3 seconds)
i-136e00c0 Ok
i-126e00c1 Ok
i-8b2cf575 Ok
```
ヘルスのステータスと色の詳細については、「[状態の色とステータス](health-enhanced-status.md)」を参照してください。
[**requests**] セクションには、各インスタンスに関するウェブサーバーログからの情報が表示されます。この例では、各インスタンスは正常にリクエストを受け取っており、エラーはありません。
```
instance-id r/sec %2xx %3xx %4xx %5xx p99 p90 p75 p50 p10 requests
Overall 13.7 100.0 0.0 0.0 0.0 1.403 0.970 0.710 0.413 0.079
i-d581497d 2.4 100.0 0.0 0.0 0.0 1.102* 0.865 0.601 0.413 0.091
i-d481497c 2.7 100.0 0.0 0.0 0.0 0.842* 0.788 0.480 0.305 0.062
i-136e00c0 4.1 100.0 0.0 0.0 0.0 1.520* 1.088 0.883 0.524 0.104
i-126e00c1 2.2 100.0 0.0 0.0 0.0 1.334* 0.791 0.760 0.344 0.197
i-8b2cf575 2.3 100.0 0.0 0.0 0.0 1.162* 0.867 0.698 0.477 0.076
```
[**CPU**] セクションには、各インスタンスのオペレーティングシステムメトリクスが表示されます。出力はオペレーティングシステムによって異なります。Linux 環境での出力を次に示します。
```
instance-id type az running load 1 load 5 user% nice% system% idle% iowait% cpu
i-d581497d t2.micro 1a 12 mins 0.0 0.03 0.2 0.0 0.0 99.7 0.1
i-d481497c t2.micro 1a 12 mins 0.0 0.03 0.3 0.0 0.0 99.7 0.0
i-136e00c0 t2.micro 1b 12 mins 0.0 0.04 0.1 0.0 0.0 99.9 0.0
i-126e00c1 t2.micro 1b 12 mins 0.01 0.04 0.2 0.0 0.0 99.7 0.1
i-8b2cf575 t2.micro 1c 1 hour 0.0 0.01 0.2 0.0 0.1 99.6 0.1
```
Windows 環境での出力を次に示します。
```
instance-id type az running % user time % privileged time % idle time
i-065716fba0e08a351 t2.large 1b 4 hours 0.2 0.0 99.8
```
サーバーとオペレーティングシステムのメトリクスの詳細については、「[インスタンスメトリクス](health-enhanced-metrics.md)」を参照してください。
最終セクション [**deployments**] には、各インスタンスのデプロイステータスが表示されます。ローリングデプロイが失敗した場合は、表示されたデプロイ ID、ステータス、バージョンラベルを使って、間違ったバージョンを実行している環境のインスタンスを特定できます。
```
instance-id status id version ago deployments
i-d581497d Deployed 1 Sample Application 12 mins
i-d481497c Deployed 1 Sample Application 12 mins
i-136e00c0 Deployed 1 Sample Application 12 mins
i-126e00c1 Deployed 1 Sample Application 12 mins
i-8b2cf575 Deployed 1 Sample Application 1 hour
```
## インタラクティブヘルスビュー
**eb health** コマンドは、環境の状態のスナップショットを表示します。表示される情報が 10 秒ごとに更新されるようにするには、`--refresh` オプションを使用します。
```
$ eb health --refresh
elasticBeanstalkExa-env Ok 2015-07-09 22:10:04 (1 secs)
WebServer Ruby 2.1 (Puma)
total ok warning degraded severe info pending unknown
5 5 0 0 0 0 0 0
instance-id status cause health
Overall Ok
i-bb65c145 Ok Application deployment completed 35 seconds ago and took 26 seconds
i-ba65c144 Ok Application deployment completed 17 seconds ago and took 25 seconds
i-f6a2d525 Ok Application deployment completed 53 seconds ago and took 26 seconds
i-e8a2d53b Ok Application deployment completed 32 seconds ago and took 31 seconds
i-e81cca40 Ok
instance-id r/sec %2xx %3xx %4xx %5xx p99 p90 p75 p50 p10 requests
Overall 671.8 100.0 0.0 0.0 0.0 0.003 0.002 0.001 0.001 0.000
i-bb65c145 143.0 1430 0 0 0 0.003 0.002 0.001 0.001 0.000
i-ba65c144 128.8 1288 0 0 0 0.003 0.002 0.001 0.001 0.000
i-f6a2d525 125.4 1254 0 0 0 0.004 0.002 0.001 0.001 0.000
i-e8a2d53b 133.4 1334 0 0 0 0.003 0.002 0.001 0.001 0.000
i-e81cca40 141.2 1412 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% cpu
i-bb65c145 t2.micro 1a 12 mins 0.0 0.03 0.2 0.0 0.0 99.7 0.1
i-ba65c144 t2.micro 1a 12 mins 0.0 0.03 0.3 0.0 0.0 99.7 0.0
i-f6a2d525 t2.micro 1b 12 mins 0.0 0.04 0.1 0.0 0.0 99.9 0.0
i-e8a2d53b t2.micro 1b 12 mins 0.01 0.04 0.2 0.0 0.0 99.7 0.1
i-e81cca40 t2.micro 1c 1 hour 0.0 0.01 0.2 0.0 0.1 99.6 0.1
instance-id status id version ago deployments
i-bb65c145 Deployed 1 Sample Application 12 mins
i-ba65c144 Deployed 1 Sample Application 12 mins
i-f6a2d525 Deployed 1 Sample Application 12 mins
i-e8a2d53b Deployed 1 Sample Application 12 mins
i-e81cca40 Deployed 1 Sample Application 1 hour
(Commands: Help,Quit, ▼ ▲ ◄ ►)
```
この例は、最近、インスタンスを 1 個から 5 個にスケールアップした環境を示しています。スケーリングオペレーションが完了し、すべてのインスタンスがヘルスチェックに合格したら、リクエストを受け取ることができるようになります。対話モードでは、ヘルスステータスが 10 秒ごとに更新されます。右上隅で、タイマーが次の更新までカウントダウンされます。
左下隅で、レポートがオプションのリストを表示します。インタラクティブモードを終了するには、**Q** キーを押します。スクロールするには、矢印キーを押します。他のコマンドのリストを表示するには、**H** キーを押します。
## インタラクティブヘルスビューのオプション
環境の状態をインタラクティブに表示する場合、キーボードのキーを使用して、表示を調整したり、個々のインスタンスを置換または再起動するように Elastic Beanstalk に指示したりできます。インタラクティブモードでヘルスレポートを表示しているときに使用できるコマンドのリストを表示するには、**H** キーを押します。
```
up,down,home,end Scroll vertically
left,right Scroll horizontally
F Freeze/unfreeze data
X Replace instance
B Reboot instance
<,> Move sort column left/right
-,+ Sort order descending/ascending
P Save health snapshot data file
Z Toggle color/mono mode
Q Quit this program
Views
1 All tables/split view
2 Status Table
3 Request Summary Table
4 CPU%/Load Table
H This help menu
(press Q or ESC to return)
```
# ベーシックヘルスレポート
このトピックでは、Elastic Beanstalk の基本ヘルスが提供する機能について説明します。
AWS Elastic Beanstalk は、複数のソースからの情報を使用して、環境が利用可能かどうかを判断し、インターネットからのリクエストを処理します。環境の状態は 4 つの色のいずれかで表され、Elastic Beanstalk コンソールの [[環境の概要](environments-console.md)] ページに表示されます。また、[DescribeEnvironments](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_DescribeEnvironments.html) API から、および [EB CLI](eb-cli3.md) を使用して **eb status** を呼び出すことによっても利用できます。
基本的なヘルスレポートシステムは、Elastic Beanstalk 環境におけるインスタンスのヘルスに関する情報を提供します。ロードバランシング環境の場合は Elastic Load Balancing、単一インスタンス環境の場合は Amazon Elastic Compute Cloud によって実行されるヘルスチェックに基づいて、Elastic Beanstalk 環境におけるインスタンスの状態に関する情報を提供します。
EC2 インスタンスのヘルスチェックに加えて、Elastic Beanstalk は、対象環境内のその他のリソースのモニタリングも行い、不足しているリソースや、誤設定のためユーザーに使用不可となったリソースをレポートします。
対象環境内のリソースによって収集されたメトリクスは、5 分間隔で Amazon CloudWatch に発行されます。これには、EC2 からのオペレーティングシステムメトリクス、Elastic Load Balancing からのリクエストメトリクスが含まれます。環境コンソールの [[Monitoring (モニタリング)] ページ](environment-health-console.md)で、これらの CloudWatch メトリクスに基づいてグラフを表示できます。基本ヘルスの場合、これらのメトリクスは環境のヘルスステータスを判断するために使用されません。
**Topics**
+ [ヘルスステータスの色](#using-features.healthstatus.colors)
+ [Elastic Load Balancing のヘルスチェック](#using-features.healthstatus.understanding)
+ [単一インスタンスおよびワーカー枠環境のヘルスチェック](#monitoring-basic-healthcheck-singleinstance)
+ [追加のチェック](#monitoring-basic-additionalchecks)
+ [Amazon CloudWatch メトリクス](#monitoring-basic-cloudwatch)
## ヘルスステータスの色
Elastic Beanstalk は、ウェブサーバーの環境のヘルスステータスを、そのサーバーで実行中のアプリケーションによるヘルスチェックへの応答に基づいてレポートします。Elastic Beanstalk は、以下の表に示しているように、4 色のいずれかでステータスを表します。
****
| カラー | 説明 |
| --- | --- |
| Grey | 環境が更新中です。 |
| Green | 環境が最新のヘルスチェックで合格になりました。環境内の少なくとも 1 つのインスタンスが使用可能であり、リクエストを受け取っています。 |
| 黄色 | 対象環境が 1 つ以上のヘルスチェックで失格になりました。環境へのいくつかのリクエストが失敗しています。 |
| 赤 | 対象環境が 3 つ以上のヘルスチェックで失格になったか、環境のリソースが使用不可になっています。リクエストは一貫して失敗しています。 |
これらの説明は、基本ヘルスレポートを使用している環境にのみ適用されます。拡張ヘルスの詳細については、「[状態の色とステータス](health-enhanced-status.md)」を参照してください。
## Elastic Load Balancing のヘルスチェック
負荷が分散されている環境では、インスタンスが正常であることを確認するために、Elastic Load Balancing は環境内の各インスタンスに 10 秒ごとにリクエストを送信します。デフォルトでは、ロードバランサーはポート 80 で TCP 接続を開くように設定されています。インスタンスが接続に応答した場合、そのインスタンスは正常と見なされます。
アプリケーションで既存のリソースを指定することによって、この設定をオーバーライドすることもできます。`/health` などのパスを指定した場合、ヘルスチェック URL は `HTTP:80/health` に設定されます。ヘルスチェック URL は、常にアプリケーションによって処理されるパスに設定する必要があります。アプリケーションの前にあるウェブサーバーによって処理またはキャッシュされる静的なページに設定すると、ヘルスチェックはアプリケーションサーバーまたはウェブコンテナで発生する問題を検出しません。ヘルスチェック URL の変更方法については、[ヘルスチェック](environments-cfg-clb.md#using-features.managing.elb.healthchecks) を参照してください。
ヘルスチェック URL が設定されている場合、Elastic Load Balancing では、送信する GET リクエストで `200 OK` の応答が返される必要があります。5 秒以内に応答が返されなかった場合、または他の HTTP ステータスコードで応答が返された場合、アプリケーションはヘルスチェックで失格になります。5 回連続してヘルスチェックで失格になった後、Elastic Load Balancing はそのインスタンスをサービスから除外します。
Elastic Load Balancing ヘルスチェックの詳細については、*Elastic Load Balancing ユーザーガイド*の「[ヘルスチェック](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/TerminologyandKeyConcepts.html#healthcheck)」を参照してください。
**注記**
ヘルスチェック URL を設定しても、環境の Auto Scaling グループのヘルスチェック動作は変わりません。正常でないインスタンスはロードバランサーから削除されますが、インスタンス置き換えの判断基準として Elastic Load Balancing ヘルスチェックを使用するように Amazon EC2 Auto Scaling を設定していない場合、そのインスタンスは Amazon EC2 Auto Scaling によって自動的に置き換えられることはありません。Elastic Load Balancing ヘルスチェックに失敗したインスタンスを置き換えるように Amazon EC2 Auto Scaling を設定するには、「[Elastic Beanstalk 環境用の Auto Scaling ヘルスチェック設定](environmentconfig-autoscaling-healthchecktype.md)」を参照してください。
## 単一インスタンスおよびワーカー枠環境のヘルスチェック
単一インスタンスまたはワーカー枠環境では、Elastic Beanstalk は Amazon EC2 インスタンスのステータスをモニタリングして、インスタンスの状態を決定します。HTTP ヘルスチェック URL を含む Elastic Load Balancing のヘルス設定は、これらの環境タイプでは使用できません。
Amazon EC2 インスタンスのステータスチェックの詳細については、「Amazon EC2 ユーザーガイド」の「[ステータスチェックでインスタンスをモニタリングする](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html)」を参照してください。
## 追加のチェック
Elastic Load Balancing ヘルスチェックに加えて、Elastic Beanstalk は、対象環境内のリソースのモニタリングを行い、デプロイに失敗したリソースや、誤設定されたリソース、使用不可になったリソースが見つかった場合、そのリソースのヘルスステータスを赤色に変更します。これらのチェックでは、以下のことが確認されます。
+ 環境の Auto Scaling グループと少なくとも 1 つのインスタンスが使用可能である。
+ 環境のセキュリティグループが使用可能で、ポート 80 で受信トラフィックを許可するように設定されている。
+ 環境 CNAME が存在し、正しいロードバランサーを指している。
+ ワーカー環境では、Amazon Simple Queue Service (Amazon SQS) キューは少なくとも 3 分に 1 回ポーリングされています。
## Amazon CloudWatch メトリクス
基本的なヘルスレポートでは、Elastic Beanstalk サービスは Amazon CloudWatch にメトリクスを公開しません。環境コンソールの [[Monitoring (モニタリング)] ページ](environment-health-console.md)でグラフの生成に使用される CloudWatch メトリクスは、対象環境内のリソースによって発行されます。
たとえば、EC2 は対象環境の Auto Scaling グループのインスタンスについて以下のメトリクスを発行します。
`CPUUtilization`
現在使用中のコンピューティングユニットのパーセンテージ。
`DiskReadBytes``DiskReadOps``DiskWriteBytes``DiskWriteOps`
読み取りおよび書き込みバイトの数、読み取りおよび書き込みオペレーションの数。
`NetworkIn``NetworkOut`
送信および受信バイトの数。
Elastic Load Balancing は対象環境のロードバランサーについて以下のメトリクスを発行します。
`BackendConnectionErrors`
対象環境のロードバランサーとインスタンスとの接続失敗の数。
`HTTPCode_Backend_2XX``HTTPCode_Backend_4XX`
対象環境内のインスタンスによって生成された成功（2XX）とクライアントエラー（4XX）の応答コードの数。
`Latency`
ロードバランサーがインスタンスにリクエストを中継してから応答を受信するまでの秒数。
`RequestCount`
完了したリクエストの数。
これらのリストにはすべてのメトリクスが含まれているわけではありません。これらのリソースについてレポート可能なメトリクスの完全なリストについては、Amazon CloudWatch 開発者ガイドの以下のトピックを参照してください。
**メトリクス**
| 名前空間 | トピック |
| --- | --- |
| AWS::ElasticLoadBalancing::LoadBalancer | [Elastic Load Balancing のメトリクスとリソース](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/elb-metricscollected.html) |
| AWS::AutoScaling::AutoScalingGroup | [Amazon Elastic Compute Cloud のメトリクスとリソース](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/ec2-metricscollected.html) |
| AWS::SQS::Queue | [Amazon SQS メトリクスおよびリソース](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/sqs-metricscollected.html) |
| AWS::RDS::DBInstance | [Amazon RDS のディメンションおよびメトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/rds-metricscollected.html) |
### ワーカー環境ヘルスメトリクス
ワーカー環境でのみ、SQS デーモンは CloudWatch に環境ヘルスのカスタムメトリクスを発行します (値 1 は Green です)。`ElasticBeanstalk/SQSD` 名前空間を使用してアカウントの CloudWatch ヘルスメトリクスデータを確認できます。メトリクスディメンションは `EnvironmentName`、メトリクス名は `Health` です。すべてのインスタンスが、同じ名前空間にメトリクスを公開します。
デーモンがメトリクスを発行できるように、環境のインスタンスプロファイルに、`cloudwatch:PutMetricData` を呼び出す権限を付与する必要があります。この権限は、デフォルトのインスタンスプロファイルに含まれます。詳細については、「」を参照してください[Elastic Beanstalk インスタンスプロファイルの管理](iam-instanceprofile.md)
# Elastic Beanstalk の拡張ヘルスレポートおよびモニタリング
このセクションでは、Elastic Beanstalk 拡張ヘルス機能について説明します。
拡張ヘルスレポートは、環境で を有効にして、 が環境内のリソースに関する追加情報 AWS Elastic Beanstalk を収集できるようにする機能です。Elastic Beanstalk は、収集された情報を分析して環境全体の状態をより的確に示し、アプリケーションの使用を妨げる可能性のある問題を特定するために役立ちます。
色で状態を示す機能が変更されたことに加え、拡張ヘルスレポートには*ステータス*記述子が追加されています。これは、環境の状態が黄色または赤色の場合に検出された問題の重大度を示します。現在のステータスに関する詳細情報があるときは、[**Causes**] ボタンを選択して、[[Health] ページ](health-enhanced-console.md)にヘルスに関する詳細情報を表示できます。
環境内で実行されている Amazon EC2 インスタンスに関する詳細なヘルス情報を提供するため、Elastic Beanstalk は、拡張ヘルスをサポートする各プラットフォームのバージョンの Amazon マシンイメージ (AMI) に[ヘルスエージェント](#health-enhanced-agent)を含めます。状態エージェントは、ウェブサーバーログとシステムメトリクスを監視して、Elastic Beanstalk サービスに中継します。Elastic Beanstalk は、これらのメトリクスと、Elastic Load Balancing と Amazon EC2 Auto Scaling から取られたデータを分析し、環境の状態に関する全体像を提示します。
環境のリソースに関する情報の収集および提示に加えて、Elastic Beanstalk は何種類かのエラー状態に備えて環境内のリソースを監視し、通知を提供します。これは、障害を回避し、設定の問題を解決するために役立ちます。[お客様の環境のヘルスに影響を与える要因](#health-enhanced-factors)としては、アプリケーションによって処理された各リクエストの結果、お客様のインスタンスのオペレーティングシステムからのメトリクス、最新のデプロイのステータスなどがあります。
Elastic Beanstalk コンソールで[環境の概要](health-enhanced-console.md)ページを使用するか、[Elastic Beanstalk コマンドラインインターフェイス](eb-cli3.md) (EB CLI) で [eb health](health-enhanced-ebcli.md) コマンドを実行することで、ヘルスステータスをリアルタイムで確認できます。Elastic Beanstalk によって収集された拡張ヘルスレポートのための情報を Amazon CloudWatch にカスタムメトリクスとしてパブリッシュするように環境を設定することで、環境とインスタンスの状態を記録し、追跡することができます。無料の `EnvironmentHealth` 以外のすべてのメトリクスには、カスタムメトリクスに対する CloudWatch [料金](https://aws.amazon.com/cloudwatch/pricing/)がかかります。
**Windows プラットフォームのメモ**
Windows Server 環境で拡張ヘルスレポートを有効にするときは、[IIS ログ設定](https://docs.microsoft.com/en-us/iis/manage/provisioning-and-managing-iis/configure-logging-in-iis)は変更しないでください。拡張ヘルスモニタリングを正しく動作させるには、IIS のログ記録を **W3C** 形式および **ETW イベントのみ**または**ログファイルと ETW イベントの両方**のログイベント送信先で設定する必要があります。
さらに、いずれの環境のインスタンスでも、[Elastic Beanstalk ヘルスエージェント](#health-enhanced-agent)の Windows サービスを無効化または停止しないでください。インスタンスで拡張ヘルス情報を収集および報告するには、このサービスが有効で実行中である必要があります。
初めて環境を作成すると、必要なロールを作成するよう Elastic Beanstalk から求められ、デフォルトで拡張ヘルスレポートが有効になります。拡張ヘルスレポートの詳しいしくみについては、この後の説明を参照してください。すぐに開始するには、「[Elastic Beanstalk の拡張ヘルスレポートの有効化](health-enhanced-enable.md)」を参照してください。
**Topics**
+ [Elastic Beanstalk のヘルスエージェント](#health-enhanced-agent)
+ [インスタンスと環境の状態を判断するための要素](#health-enhanced-factors)
+ [ヘルスチェックルールのカスタマイズ](#health-enhanced.rules)
+ [拡張ヘルスレポートのロール](#health-enhanced-roles)
+ [拡張ヘルス認可](#health-enhanced-authz)
+ [拡張ヘルスレポートのイベント](#health-enhanced-events)
+ [更新、デプロイ、およびスケーリング中の拡張ヘルスレポートの動作](#health-enhanced-effects)
+ [Elastic Beanstalk の拡張ヘルスレポートの有効化](health-enhanced-enable.md)
+ [環境管理コンソールでの拡張ヘルスモニタリング](health-enhanced-console.md)
+ [状態の色とステータス](health-enhanced-status.md)
+ [インスタンスメトリクス](health-enhanced-metrics.md)
+ [環境の拡張ヘルスルールの設定](health-enhanced-rules.md)
+ [環境の Amazon CloudWatch カスタムメトリクスの発行](health-enhanced-cloudwatch.md)
+ [Elastic Beanstalk API での拡張ヘルスレポートの使用](health-enhanced-api.md)
+ [拡張ヘルスログ形式](health-enhanced-serverlogs.md)
+ [通知とトラブルシューティング](environments-health-enhanced-notifications.md)
+ [AI を活用した環境分析](health-ai-analysis.md)
## Elastic Beanstalk のヘルスエージェント
Elastic Beanstalk のヘルスエージェントは、環境内の各 Amazon EC2 インスタンスで実行されるデーモンプロセス (または Windows 環境のサービス) であり、オペレーティングシステムおよびアプリケーションレベルのヘルスメトリクスをモニタリングし、問題を Elastic Beanstalk に報告します。ヘルスエージェントは、各プラットフォームのバージョン 2.0 以降、すべてのプラットフォームのバージョンに含まれています。
状態エージェントからの報告内容は、[ベーシックヘルスレポート](using-features.healthstatus.md)の一部として Amazon EC2 Auto Scaling および Elastic Load Balancing によって [CloudWatch に公開される](using-features.healthstatus.md#monitoring-basic-cloudwatch)メトリクスと似ており、CPU 負荷、HTTP コード、レイテンシーなどが含まれます。ただし、状態エージェントによるレポートは、ベーシックヘルスレポートより高い詳細度と頻度で直接 Elastic Beanstalk に送信されます。
ベーシックヘルスレポートの場合、これらのメトリクスは、5 分間隔で公開され、環境マネジメントコンソールのグラフで確認できます。拡張ヘルスでは、Elastic Beanstalk ヘルスエージェントは 10 秒ごとに Elastic Beanstalk にメトリクスを報告します。Elastic Beanstalk は状態エージェントから提供されたメトリクスを使用して、環境内の各インスタンスのヘルスステータスを判断します。さらに、他の[要素](#health-enhanced-factors)と組み合わせて、環境全体の状態を判断します。
環境全体の状態は、Elastic Beanstalk によって 60 秒間隔で CloudWatch に公開され、Elastic Beanstalk コンソールの環境の概要ページでリアルタイムで確認できます。状態エージェントによって報告された詳細なメトリクスは、[EB CLI](eb-cli3.md) の [**eb health**](health-enhanced-ebcli.md) コマンドを使用してリアルタイムで確認できます。
個々のインスタンスおよび環境レベルのメトリクスを 60 秒間隔で CloudWatch に公開することもできます (追加料金が必要です)。CloudWatch に公開されたメトリクスを使用すると、[環境マネジメントコンソール](environments-console.md)で[モニタリンググラフ](environment-health-console.md#environment-health-console-customize)を作成できます。
拡張ヘルスレポートで料金が発生するのは、拡張ヘルスレポートのメトリクスを CloudWatch に公開するオプションを選択した場合のみです。拡張ヘルスレポートを使用していて、拡張ヘルスレポートのメトリクスを公開するオプションを選択していなくても、ベーシックヘルスレポートのメトリクスは無料で公開できます。
状態エージェントによって報告されるメトリクスの詳細については、「[インスタンスメトリクス](health-enhanced-metrics.md)」を参照してください。拡張ヘルスメトリクスのメトリクスを CloudWatch に公開する方法の詳細については、「」を参照してください[環境の Amazon CloudWatch カスタムメトリクスの発行](health-enhanced-cloudwatch.md)
## インスタンスと環境の状態を判断するための要素
Elastic Beanstalk 拡張ヘルスレポートは、基本的なヘルスレポートのシステムチェック ([Elastic Load Balancing のヘルスチェック](using-features.healthstatus.md#using-features.healthstatus.understanding) および[リソースモニタリング](using-features.healthstatus.md#monitoring-basic-additionalchecks)など) に加えて、環境内のインスタンスの状態に関する追加のデータを収集します。これには、オペレーティングシステムのメトリクス、サーバーログ、およびデプロイや更新などの進行中の環境オペレーションの状態が含まれます。Elastic Beanstalk ヘルスレポートサービスは、利用可能なすべてのソースからの情報を組み合わせて分析し、環境全体の状態を判断します。
### オペレーションとコマンド
環境内でオペレーション (アプリケーションの新しいバージョンのデプロイなど) を実行する場合、Elastic Beanstalk では、環境のヘルスステータスに影響するいくつかの変更が行われます。
たとえば、複数のインスタンスを実行する環境にアプリケーションの新しいバージョンをデプロイする場合、[EB CLI](health-enhanced-ebcli.md) で環境の状態をモニタリングしていると、次のようなメッセージが表示されることがあります。
```
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 ずつ増えます。デプロイに関する情報を使用して、[ローリングデプロイ](using-features.rolling-version-deploy.md)の失敗後にアプリケーションの間違ったバージョンを実行しているインスタンスを特定できます。
Elastic Beanstalk は、原因を示す列に、成功したオペレーションに関する情報メッセージと、複数のヘルスチェックにおけるその他のヘルスステータスを表示しますが、これらは無期限に保存されるわけではありません。環境の異常な状態の原因を示す情報が保存されるのは、環境の状態が正常に戻るまでです。
### コマンドタイムアウト
インスタンスが正常な状態に移行できるように、Elastic Beanstalk では、オペレーションが開始した時点からコマンドタイムアウトが適用されます。このコマンドタイムアウトは、環境の更新およびデプロイ設定 ([aws:elasticbeanstalk:command](command-options-general.md#command-options-general-elasticbeanstalkcommand) 名前空間) で設定されており、デフォルト値は 10 分です。
ローリング更新の実行中、Elastic Beanstalk は、オペレーション内の各バッチに別々のタイムアウトを適用します。このタイムアウトは環境のローリング更新の一部として ([aws:autoscaling:updatepolicy:rollingupdate](command-options-general.md#command-options-general-autoscalingupdatepolicyrollingupdate) 名前空間で) 設定されます。バッチ内のすべてのインスタンスがローリング更新タイムアウト内で正常に実行されている場合は、オペレーションが次のバッチに進みます。それ以外の場合、オペレーションは失敗となります。
**注記**
アプリケーションがヘルスチェックで **OK** ステータスにならなくても、別のレベルで安定する場合は、[`HealthCheckSuccessThreshold`](command-options-general.md#command-options-general-elasticbeanstalkcommand) で `aws:elasticbeanstalk:command namespace` オプションを設定して、Elastic Beanstalk でインスタンスが正常と見なされるレベルに変更できます。
ウェブサーバー環境が正常であると見なされるには、環境内またはバッチ内の各インスタンスが 2 分間にわたって連続して行われる 12 のヘルスチェックに合格する必要があります。ワーカー枠環境の場合は、各インスタンスが 18 のヘルスチェックに合格する必要があります。Elastic Beanstalk は、ヘルスチェックで異常が検出されても、コマンドタイムアウトの前には、環境のヘルスステータスを引き下げません。環境内のインスタンスがコマンドタイムアウト内に正常な状態である場合、オペレーションは成功となります。
### HTTP リクエスト
環境で進行中のオペレーションがない場合、インスタンスと環境の状態に関する情報のプライマリソースは、各インスタンスのウェブサーバーログです。インスタンスの状態と環境全体の状態を判断するためには、リクエストの数、各リクエストの結果、各リクエストが解決された速度が考慮されます。
Linux ベースのプラットフォームでは、Elastic Beanstalk はウェブサーバーのログを読み取り、解析して HTTP リクエストに関する情報を取得します。Windows Server プラットフォームでは、Elastic Beanstalk はこの情報を [IIS ウェブサーバーから直接](health-enhanced-metrics-server-iis.md)受け取ります。
環境にはアクティブなウェブサーバーがない可能性があります。たとえば、複数コンテナ Docker プラットフォームにはウェブサーバーは含まれません。その他のプラットフォームにはウェブサーバーがあり、アプリケーションがこれを無効にする可能性があります。このような場合、環境では、ヘルス情報を Elastic Beanstalk サービスに中継するために必要な形式のログを [Elastic Beanstalk ヘルスエージェント](#health-enhanced-agent)に提供するための、追加の設定が必要です。詳細については、「[拡張ヘルスログ形式](health-enhanced-serverlogs.md)」を参照してください。
### オペレーティングシステムのメトリクス
Elastic Beanstalk は、状態エージェントから報告されたオペレーティング システムのメトリクスを監視し、継続的にシステムリソースが不足しているインスタンスを特定します。
状態エージェントによって報告されるメトリクスの詳細については、「[インスタンスメトリクス](health-enhanced-metrics.md)」を参照してください。
## ヘルスチェックルールのカスタマイズ
Elastic Beanstalk 拡張ヘルスレポートは、環境のヘルスを判断するための一連のルールに依存しています。これらのルールの一部は、特定のアプリケーションに適していない場合があります。よくあるケースは、仕様により頻繁に HTTP 4xx エラーを返すアプリケーションです。Elastic Beanstalk は、デフォルトのルールの 1 つを使用して、何かが間違っていると判断すると、エラーレートに応じて、環境のヘルスステータスを、OK から警告、パフォーマンス低下、または重大へと変化させます。このケースを正しく処理するために、Elastic Beanstalk ではこのルールを正しく設定して、アプリケーション HTTP 4xx エラーを無視するように設定できます。詳細については、「[環境の拡張ヘルスルールの設定](health-enhanced-rules.md)」を参照してください。
## 拡張ヘルスレポートのロール
拡張ヘルスレポートには、2 つのロールが必要です。Elastic Beanstalk 用のサービスロールと、環境用のインスタンスプロファイルです。サービスロールを使用すると、Elastic Beanstalk はユーザーに代わって他の AWS サービスとやり取りして、環境内のリソースに関する情報を収集できます。インスタンスプロファイルを使用すると、環境内のインスタンスがログを Amazon S3 に書き込んだり、拡張ヘルス情報を Elastic Beanstalk サービスに伝達したりできます。
Elastic Beanstalk コンソールまたは EB CLI を使用して Elastic Beanstalk 環境を作成すると、Elastic Beanstalk はデフォルトのサービスロールを作成し、必要な管理ポリシーを環境のデフォルトのインスタンスプロファイルにアタッチします。
API、 SDK、または を使用して環境を作成する場合は、これらのロール AWS CLI を事前に作成し、環境の作成時に指定して拡張ヘルスを使用する必要があります。環境に適切なロールを作成する方法については、「」を参照してください[Elastic Beanstalk サービスロール、インスタンスプロファイル、ユーザーポリシー](concepts-roles.md)
インスタンスプロファイルとサービスロールには*管理ポリシー*を使用することをお勧めします。管理ポリシーは、Elastic Beanstalk が管理する AWS Identity and Access Management (IAM) ポリシーです。管理ポリシーを使用すると、環境が適切に機能するために必要なすべてのアクセス許可を持つことが保証されます。
インスタンスプロファイルでは、[ウェブサーバー層](concepts-webserver.md)または[ワーカー層](concepts-worker.md)環境に対して、`AWSElasticBeanstalkWebTier` または `AWSElasticBeanstalkWorkerTier` 管理ポリシーをそれぞれ使用できます。これら 2 つのマネージドインスタンスプロファイルポリシーの詳細については、「[Elastic Beanstalk インスタンスプロファイルの管理](iam-instanceprofile.md)」を参照してください。
## 拡張ヘルス認可
Elastic Beanstalk インスタンスプロファイルマネージドポリシーには、`elasticbeanstalk:PutInstanceStatistics` アクションに対するアクセス許可が含まれています。このアクションは Elastic Beanstalk API の一部ではありません。これは、環境インスタンスが拡張ヘルス情報を Elastic Beanstalk サービスに伝達するために内部的に使用する別の API の一部です。この 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](command-options-general.md#command-options-general-elasticbeanstalkhealthreporting) 名前空間の `EnhancedHealthAuthEnabled` オプションを `false` に設定して無効にします。このオプションが無効になっている場合、前述のアクセス許可は必要ありません。アプリケーションと環境への[最小特権アクセス](security-best-practices.md#security-best-practices.preventive.least-priv)のために、これらをインスタンスプロファイルから削除できます。
**注記**
以前の `EnhancedHealthAuthEnabled` のデフォルト設定は `false` であったため、`elasticbeanstalk:PutInstanceStatistics` アクションに対する認可でもデフォルトでは無効となっています。既存の環境でこのアクションを有効にするには、[aws:elasticbeanstalk:healthreporting:system](command-options-general.md#command-options-general-elasticbeanstalkhealthreporting) 名前空間の `EnhancedHealthAuthEnabled` オプションを `true` に設定します。このオプションは、[設定ファイル](ebextensions.md)の[オプション設定](ebextensions-optionsettings.md)を使用して設定できます。
## 拡張ヘルスレポートのイベント
拡張ヘルスレポートのシステムでは、環境の状態が変化するとイベントが生成されます。次の例は、環境の状態が **Info**、**OK**、**Severe** の間で変化した場合に出力されたイベントを示しています。
![\[拡張ヘルスの最近のイベントを示す Elastic Beanstalk コンソールの Elastic Beanstalk 環境概要ページ\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/enhanced-health-events.png)
現在より悪い状態に変化した場合は、変化の原因を示すメッセージが拡張ヘルスイベントに含められます。
インスタンスレベルでのステータスの変化がすべて Elastic Beanstalk によるイベントの出力になるわけではありません。Elastic Beanstalk では、誤ったアラームを回避するために、複数のチェックで同じ問題が生じている場合のみ、状態に関連したイベントを出力します。
ステータス、色、原因など、環境レベルのリアルタイムの状態情報は、Elastic Beanstalk コンソールの[環境の概要](environments-dashboard.md)ページおよび [EB CLI](eb-cli3.md) から利用できます。EB CLI を環境にアタッチして [**eb health**](health-enhanced-ebcli.md) コマンドを実行すると、環境内のインスタンスに関するリアルタイムのステータスを表示することもできます。
## 更新、デプロイ、およびスケーリング中の拡張ヘルスレポートの動作
拡張ヘルスレポートを有効にすると、設定更新中およびデプロイ中の環境の動作に影響が及ぶ可能性があります。Elastic Beanstalk は、すべてのインスタンスが一貫してヘルスチェックに合格するまで、更新のバッチを完了しません。また、拡張ヘルスレポートはより高い標準をヘルスに適用し、より多くの要素をモニタリングするため、基本ヘルスレポートの [ELB ヘルスチェック](using-features.healthstatus.md#using-features.healthstatus.understanding)に合格したインスタンスが、必ずしも拡張ヘルスレポートに合格するとは限りません。ヘルスチェックがアップデート処理にどのように影響するかについては、[ローリング設定更新](using-features.rollingupdates.md)および[ローリングデプロイ](using-features.rolling-version-deploy.md)のトピックを参照してください。
拡張ヘルスレポートは、Elastic Load Balancing の[ヘルスチェック URL](environments-cfg-clb.md#using-features.managing.elb.healthchecks) を適切に設定する必要があることについても指摘します。要求に対応するために環境がスケールアップすると、新しいインスタンスは、十分な数の ELB ヘルスチェックに合格するとすぐにリクエストの受け取りを開始します。ヘルスチェック URL が設定されていなければ、新しいインスタンスが TCP 接続を受け付けてからわずか 20 秒で開始することがあります。
ロードバランサーによってアプリケーションが正常であり、トラフィックを受け取っても問題がないと宣言されるまでにアプリケーションの起動が終了していない場合、大量のリクエストが失敗し、環境がヘルスチェックに合格しなくなります。アプリケーションによって処理されるパスをヒットするヘルスチェック URL が、この問題を防止できます。ヘルスチェック URL への GET リクエストが 200 ステータスコードを返すまで、ELB ヘルスチェックに合格しません。
# Elastic Beanstalk の拡張ヘルスレポートの有効化
このトピックでは、拡張ヘルスレポートを有効にする方法について説明します。Elastic Beanstalk コンソール、EB CLI、および .ebextensions 設定を使用して、環境の拡張ヘルス機能を有効にする手順を示します。
最新の[プラットフォームバージョン](concepts.platforms.md)で作成された新しい環境には、拡張ヘルスレポートをサポートする AWS Elastic Beanstalk [ヘルスエージェント](health-enhanced.md#health-enhanced-agent)が含まれています。Elastic Beanstalk コンソールまたは EB CLI を使用して環境を作成する場合は、拡張ヘルスレポートがデフォルトで有効になっています。[設定ファイル](ebextensions.md)を使用して、アプリケーションのソースコードでヘルスレポートの設定を変更することもできます。
拡張ヘルスレポートには、一連の標準のアクセス権限に加えて、[インスタンスプロファイル](concepts-roles-instance.md)と[サービスロール](concepts-roles-service.md)が必要です。Elastic Beanstalk コンソールで環境を作成すると、Elastic Beanstalk によって自動的に必要なロールが作成されます。最初の環境を作成する手順については、「[Elastic Beanstalk の使用を開始する方法について説明します](GettingStarted.md)」を参照してください。
**Topics**
+ [Elastic Beanstalk コンソールを使用した拡張ヘルスレポートの有効化](#health-enhanced-enable-console)
+ [EB CLI を使用した拡張ヘルスレポートの有効化](#health-enhanced-enable-ebcli)
+ [設定ファイルを使用した拡張ヘルスレポートの有効化](#health-enhanced-enable-config)
## Elastic Beanstalk コンソールを使用した拡張ヘルスレポートの有効化
**Elastic Beanstalk コンソールを使用して実行中の環境で拡張ヘルスレポートを有効にするには**
1. [Elastic Beanstalk コンソール](https://console.aws.amazon.com/elasticbeanstalk)を開き、**リージョン**リストで を選択します AWS リージョン。
1. ナビゲーションペインで、[**環境**] を選択し、リストから環境の名前を選択します。
1. ナビゲーションペインで、[**設定**] を選択します。
1. [**モニタリング**] 設定カテゴリで、[**編集**] を選択します。
1. [**ヘルスレポート**] の [**システム**] で [**Enhanced (拡張)**] を選択します。
**注記**
[サポートしていないプラットフォームまたはバージョン](health-enhanced.md)を使用している場合、拡張ヘルスレポートのオプションは表示されません。
1. ページの最下部で **[適用]** を選択し変更を保存します。
Elastic Beanstalk コンソールでは、バージョン 2 (v2) プラットフォーム設定で新しい環境を作成するときにデフォルトで拡張ヘルスレポートが有効になります。環境の作成中にヘルスレポートオプションを変更することによって、拡張ヘルスレポートを無効にすることができます。
**Elastic Beanstalk コンソールを使用して環境を作成しているときに拡張ヘルスレポートを無効にするは**
1. [Elastic Beanstalk コンソール](https://console.aws.amazon.com/elasticbeanstalk)を開き、**リージョン**リストで を選択します AWS リージョン。
1. [新しいアプリケーションを作成](applications.md)するか、既存のアプリケーションを選択します。
1. [環境を作成します](using-features.environments.md)。[**新しい環境の作成**] ページで、[**環境の作成**] を選択する前に、[**さらにオプションを設定**] を選択します。
1. [**モニタリング**] 設定カテゴリで、[**編集**] を選択します。
1. [**Health reporting**] の [**System**] で [**Basic**] を選択します。
1. **[保存]** を選択します。
## EB CLI を使用した拡張ヘルスレポートの有効化
**eb create** コマンドを使用して新しい環境を作成すると、EB CLI では拡張ヘルスレポートがデフォルトで有効になり、デフォルトのインスタンスプロファイルとサービスロールが適用されます。
`--service-role` オプションを使用して、異なるサービスロールを名前で指定できます。
v2 プラットフォームバージョンで基本ヘルスレポートが使用されている環境を実行している場合、拡張ヘルスに切り替えるには、以下のステップを実行します。
**[EB CLI](eb-cli3.md) を使用して実行中の環境の拡張ヘルスレポートを有効にするには**
1. **eb config** コマンドを使用して、設定ファイルをデフォルトのテキストエディタで開きます。
```
~/project$ eb config
```
1. 設定セクションで、`aws:elasticbeanstalk:environment` 名前空間を見つけます。`ServiceRole` の値が null ではなく、[サービスロール](concepts-roles-service.md)の名前と一致していることを確認します。
```
aws:elasticbeanstalk:environment:
EnvironmentType: LoadBalanced
ServiceRole: aws-elasticbeanstalk-service-role
```
1. `aws:elasticbeanstalk:healthreporting:system:` 名前空間で、`SystemType` の値を **enhanced** に変更します。
```
aws:elasticbeanstalk:healthreporting:system:
SystemType: enhanced
```
1. 設定ファイルを保存し、テキストエディタを閉じます。
1. EB CLI によって環境の更新が開始されて、設定の変更が適用されます。オペレーションの完了を待つか、**Ctrl\$1C** キーを押して安全に終了します。
```
~/project$ eb config
Printing Status:
INFO: Environment update is starting.
INFO: Health reporting type changed to ENHANCED.
INFO: Updating environment no-role-test's configuration settings.
```
## 設定ファイルを使用した拡張ヘルスレポートの有効化
ソースバンドルに[設定ファイル](ebextensions.md)を含めることで、拡張ヘルスレポートを有効にすることができます。以下の例では、拡張ヘルスレポートを有効にし、デフォルトのサービスとインスタンスプロファイルを環境に割り当てる、設定ファイルを示しています。
**Example .ebextensions/enhanced-health.config**
```
option_settings:
aws:elasticbeanstalk:healthreporting:system:
SystemType: enhanced
aws:autoscaling:launchconfiguration:
IamInstanceProfile: aws-elasticbeanstalk-ec2-role
aws:elasticbeanstalk:environment:
ServiceRole: aws-elasticbeanstalk-service-role
```
独自のインスタンスプロファイルやサービスロールを作成した場合は、強調表示されたテキストをそれらのロールの名前に置き換えます。
# 環境管理コンソールでの拡張ヘルスモニタリング
で拡張ヘルスレポートを有効にすると AWS Elastic Beanstalk、環境[マネジメントコンソールで環境](environments-console.md)のヘルスをモニタリングできます。
**Topics**
+ [環境の概要](#health-enhanced-console-overview)
+ [環境の状態ページ](#health-enhanced-console-healthpage)
+ [モニタリングページ](#health-enhanced-console-monitoringpage)
## 環境の概要
[環境の概要](environments-dashboard.md)には、環境の[ヘルスステータス](health-enhanced-status.md)が表示され、ヘルスステータスの最新の変更に関する情報を提供するイベントが示されます。
**環境の概要を表示するには**
1. [Elastic Beanstalk コンソール](https://console.aws.amazon.com/elasticbeanstalk)を開き、**リージョン**リストで を選択します AWS リージョン。
1. ナビゲーションペインで、[**環境**] を選択し、リストから環境の名前を選択します。
現在の環境のヘルスに関する詳細情報を確認するには、[**Causes (原因)**] を選択して [**ヘルス**] ページを開きます。または、ナビゲーションペインで [**ヘルス**] を選択します。
## 環境の状態ページ
[**Health (ヘルス)**] ページには、環境とその環境内の各 Amazon EC2 インスタンスについてヘルスステータス、メトリクス、原因が表示されます。
**注記**
Elastic Beanstalk では、環境に対して[拡張ヘルスモニタリングを有効にした](health-enhanced-enable.md)場合にのみ、**[Health]** (ヘルス) ページが表示されます。
次の図は、Linux 環境の [**ヘルス**] ページを示しています。
![\[Linux 環境の環境ヘルスページ\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/enhanced-health-instances.png)
次の図は、Windows 環境の [**ヘルス**] ページを示しています。CPU のメトリクスは、Linux 環境とは異なることに注意してください。
![\[Windows 環境の [環境のヘルス] ページ。\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/enhanced-health-instances-win.png)
ページの上部には、環境インスタンスの合計数と、ステータスごとのインスタンス数が表示されます。特定のステータスのインスタンスのみを表示するには、[**Filter By (フィルタ条件)**] を選択してから [[status (ステータス)](health-enhanced-status.md)] を選択します。
![\[表示するインスタンスのステータスを選択するためのメニューによるフィルターを表示する環境ヘルスページ\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/enhanced-health-instances-status.png)
正常でないインスタンスを再起動/終了するには、[**Instance Actions**]、[**Reboot**]、[**Terminate**] の順に選択します。
![\[異常なインスタンスを再起動または終了するのための [インスタンスのアクション] メニューが表示された [環境のヘルス] ページ。\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/enhanced-health-instances-actions.png)
Elastic Beanstalk では、[**Health (ヘルス)**] ページが 10 秒ごとに更新されます。このページでは、環境とインスタンスのヘルスに関する情報をレポートします。
環境内の各 Amazon EC2 インスタンスについて、このページには、インスタンスの ID と[ステータス](health-enhanced-status.md)、インスタンスが起動されてからの時間、インスタンスで実行された最新のデプロイの ID、インスタンスが処理したリクエストのレスポンスとレイテンシー、およびロードと CPU 使用率の情報が表示されます。[**Overall (全体)**] 行には、環境全体の平均レスポンスとレイテンシー情報が表示されます。
このページには、非常に横長のテーブルに多くの詳細が表示されます。一部の列を非表示にするには、![\[the cog icon.\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/cog.png) ([**Preferences (設定)**]) を選択します。列名を選択または選択解除し、[**Confirm (確認)**] を選択します。
![\[環境ヘルスページに表示する列の選択\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/enhanced-health-console-preferences.png)
任意のインスタンスの [**Instance ID (インスタンスの ID)**] を選択すると、アベイラビリティーゾーンやインスタンスタイプなど、インスタンスの詳細情報が表示されます。
![\[[環境ヘルス] ページのサーバーのメトリクスとインスタンス情報\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/enhanced-health-console-instance.png)
インスタンスの [**Deployment ID (デプロイ ID)**] を選択して、インスタンスへの前回の[デプロイ](using-features.deploy-existing-version.md)に関する情報を表示します。
![\[[環境ヘルス] ページのサーバーメトリクスとデプロイ情報\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/enhanced-health-console-deployment.png)
デプロイに関する情報は以下のとおりです。
+ **Deployment ID (デプロイ ID)**—[デプロイ](using-features.deploy-existing-version.md)の一意の識別子。デプロイ ID は 1 から始まり、新しいアプリケーションバージョンをデプロイするか、お客様の環境内のインスタンスで動作するソフトウェアやオペレーティングシステムに影響を与える構成設定を変更するたびに、1 ずつ増えます。
+ **Version (バージョン)**—デプロイで使用されるアプリケーションのソースコードのバージョンラベル。
+ **Status (ステータス)**—デプロイのステータス。`In Progress`、`Deployed`、または `Failed` になります。
+ **Time (時間)**—進行中のデプロイの場合は、デプロイが開始した時間。完了したデプロイの場合は、デプロイが終了した時間。
環境で [X-Ray 統合を有効に](environment-configuration-debugging.md)し、 AWS X-Ray SDK を使用してアプリケーションを計測する場合、**ヘルス**ページは概要行に AWS X-Ray コンソールへのリンクを追加します。
![\[[環境のヘルス] ページでのメトリクスのリクエスト\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/enhanced-health-console-xray.png)
リンクを選択すると、強調表示された統計に関連するトレースが AWS X-Ray コンソールに表示されます。
## モニタリングページ
[**Monitoring (モニタリング)**] ページには、拡張ヘルスレポートシステムによって生成された Amazon CloudWatch カスタムメトリクスの統計サマリーとグラフが表示されます。このページにグラフと統計情報を追加する手順については、「[AWS マネジメントコンソールでの環境の状態のモニタリング](environment-health-console.md)」を参照してください。
# 状態の色とステータス
拡張ヘルスレポートは、[基本ヘルスレポート](using-features.healthstatus.md)と同様に、インスタンスと環境全体の状態を 4 色を使って表します。また、拡張ヘルスレポートは、単一の単語で示される 7 つのヘルスステータスも表示します。これにより、環境の状態をより的確に把握できます。
## インスタンスのステータスと環境ステータス
Elastic Beanstalk が環境のヘルスチェックを実行するたびに、拡張ヘルスレポートは、使用できるすべての[データ](health-enhanced.md#health-enhanced-factors)を分析することによって、環境内の各インスタンスの状態をチェックします。低いレベルのチェックに合格しなければ、Elastic Beanstalk はインスタンスの状態をダウングレードします。
Elastic Beanstalk は、環境全体のヘルス情報 (色、ステータス、および原因) を[環境マネジメントコンソール](environments-console.md)に表示します。この情報は、EB CLI でも使用できます。個々のインスタンスのヘルスステータスと原因のメッセージは、10 秒ごとに更新され、[EB CLI](eb-cli3.md) から [**eb health**](health-enhanced-ebcli.md) を使用してヘルスステータスを表示するときに確認できます。
Elastic Beanstalk は、インスタンスの状態の変化に基づいて環境の状態を評価しますが、環境のヘルスステータスをすぐに変更するわけではありません。インスタンスが 1 分間に 3 回以上ヘルスチェックに不合格になると、Elastic Beanstalk は環境の状態をダウングレードする場合があります。環境内のインスタンスの数と特定された問題によっては、1 つのインスタンスに異常があるだけで、Elastic Beanstalk が情報メッセージを表示する、または環境のヘルスステータスを緑色 (**OK**) から黄色 (**Warning**) または赤色 (**Degraded** または **Severe**) に変更できます。
## OK (緑色)
このステータスは、以下の場合に表示されます。
+ インスタンスはヘルスチェックに合格し、ヘルスエージェントは問題を報告していない。
+ 環境内のほとんどのインスタンスがヘルスチェックに合格し、ヘルスエージェントは重大な問題を報告していない。
+ インスタンスはヘルスチェックに合格し、リクエストを正常に完了している。
*例:* 環境がデプロイされたばかりであり、リクエストを正常に受け取っていない。5% のリクエストが 400 シリーズのエラーを返している。各インスタンスでデプロイが正常に完了した。
*メッセージ (インスタンス):* Application deployment completed 23 seconds ago and took 26 seconds。
## Warning (黄色)
このステータスは、以下の場合に表示されます。
+ ヘルスエージェントが、ある程度の数のリクエストが不合格であったこと、あるいはインスタンスまたは環境にその他の問題があることを報告している。
+ インスタンスで進行中の操作に、非常に長い時間がかかっている。
*例:* 環境内の 1 つのインスタンスのステータスが **Severe** である。
*メッセージ (環境):* Impaired services on 1 out of 5 instances
## Degraded (赤色)
このステータスが表示されるのは、ヘルスエージェントが、非常に多くのリクエストが不合格であったこと、あるいはインスタンスまたは環境にその他の問題があることを報告している場合です。
*例:* 環境が 5 つのインスタンスへのスケールアップを処理している。
*メッセージ (環境):* 4 active instances is below Auto Scaling group minimum size 5.
## Severe (赤色)
このステータスが表示されるのは、ヘルスエージェントが、非常に多くのリクエストが不合格であったこと、あるいはインスタンスまたは環境にその他の問題があることを報告している場合です。
*例:* Elastic Beanstalk は、ロードバランサーにアクセスしてインスタンスの状態を取得することができません。
*メッセージ (環境):* ELB health is failing or not available for all instances。None of the instances are sending data。Unable to assume role "arn:aws:iam::123456789012:role/aws-elasticbeanstalk-service-role"。Verify that the role exists and is configured correctly。
*メッセージ (インスタンス)*: Instance ELB health has not been available for 37 minutes。No data。Last seen 37 minutes ago。
## Info (緑色)
このステータスは、以下の場合に表示されます。
+ インスタンスで操作が進行中である。
+ 環境内の複数のインスタンスで操作が進行中である。
*例:* 実行中のインスタンスに新しいアプリケーションバージョンがデプロイされている。
*メッセージ (環境):* Command is executing on 3 out of 5 instances。
*メッセージ (インスタンス):* Performing application deployment (running for 3 seconds)。
## Pending (灰色)
このステータスが表示されるのは、[コマンドタイムアウト](health-enhanced.md#health-enhanced-factors-timeout)の時間内でインスタンスでの操作が進行中のときです。
*例:* 環境を最近作成したばかりであり、インスタンスのブートストラップが行われている。
*メッセージ:* Performing initialization (running for 12 seconds)。
## Unknown (灰色)
このステータスが表示されるのは、Elastic Beanstalk とヘルスエージェントが、インスタンスのデータの量が不足していることを報告したときです。
*例:* データを受け取っていない。
## 停止 (グレー)
このステータスが表示されるのは、Elastic Beanstalk が環境のヘルス状態のモニタリングを停止したときです。環境は正常に動作しない可能性があります。一部の重大なヘルス条件が長期間存在する場合、Elastic Beanstalk により環境が**停止**状態になります。
*例:* Elastic Beanstalk が環境の[サービスロール](iam-servicerole.md)にアクセスできない。
*例:* 環境に対して Elastic Beanstalk によって作成された [Auto Scaling グループ](using-features.managing.as.md)が削除された。
*メッセージ:* 環境のヘルスステータスが [**OK**] から [**重大**] に移行されました。インスタンスはありません。Auto Scaling グループの希望する容量が 1 に設定されます。
# インスタンスメトリクス
インスタンスメトリクスは、環境にあるインスタンスの健全性に関する情報を提供します。[Elastic Beanstalk ヘルスエージェント](health-enhanced.md#health-enhanced-agent)は、各インスタンスで実行されます。ヘルスエージェントはインスタンスに関するメトリクスを収集し、中継された Elastic Beanstalk はそのメトリクスを分析して環境内のインスタンスの状態を特定します。
オンインスタンス Elastic Beanstalk ヘルスエージェントは、ウェブサーバーログとオペレーティングシステムからインスタンスに関するメトリクスを収集します。Linux ベースのプラットフォームでウェブサーバー情報を取得するために、Elastic Beanstalk はウェブサーバーのログを読み取り、解析します。Windows Server プラットフォームでは、Elastic Beanstalk はこの情報を IIS ウェブサーバーから直接受け取ります。ウェブサーバーは、着信 HTTP リクエストに関する情報 (届いたリクエストの数、エラーとなった数、解決までの時間) を提供します。オペレーティング システムはインスタンスのリソース状態についてのスナップショット情報を提供します。プロセスタイプごとの CPU 負荷および配信経過時間。
ヘルスエージェントはウェブサーバーとオペレーティングシステムのメトリクスを収集し、10 秒ごとに Elastic Beanstalk に中継します。Elastic Beanstalk は中継されたデータを分析し、その結果を使用して、各インスタンスと環境のヘルスステータスを更新します。
**Topics**
+ [ウェブサーバーのメトリクス](#health-enhanced-metrics-server)
+ [オペレーティングシステムのメトリクス](#health-enhanced-metrics-os)
+ [Windows サーバー上の IIS でのウェブサーバーメトリクスキャプチャ](health-enhanced-metrics-server-iis.md)
## ウェブサーバーのメトリクス
Linux ベースのプラットフォームで、Elastic Beanstalk ヘルスエージェントは、ウェブコンテナまたは環境内の各インスタンスでリクエストを処理するサーバーによって生成されたログからウェブサーバーメトリクスを読み取ります。Elastic Beanstalk プラットフォームは、人間が読み取れる形式と機械による読み取りが可能な形式の 2 つのログを生成するように設定されています。機械による読み取りが可能なログは、ヘルスエージェントによって 10 秒ごとに Elastic Beanstalk に中継されます。
Elastic Beanstalk で使用されるログ形式の詳細については、「[拡張ヘルスログ形式](health-enhanced-serverlogs.md)」を参照してください。
Windows Server プラットフォームでは、Elastic Beanstalk は IIS ウェブサーバーのリクエストパイプラインにモジュールを追加し、HTTP リクエスト時間と応答コードに関するメトリクスを取得します。モジュールは、高性能のプロセス間通信 (IPC) チャネルを使用して、これらのメトリクスをインスタンス上のヘルスエージェントに送信します。実装の詳細については、「[Windows サーバー上の IIS でのウェブサーバーメトリクスキャプチャ](health-enhanced-metrics-server-iis.md)」を参照してください。報告されたウェブサーバーのメトリクス
`RequestCount`
直前の 10 秒間にウェブサーバーによって処理されたリクエストの 1 秒あたりの数。EB CLI と [環境の状態ページ](health-enhanced-console.md#health-enhanced-console-healthpage) に表示される平均 `r/sec` (1 秒ごとのリクエスト) として表示されます。
`Status2xx``Status3xx``Status4xx``Status5xx`
直前の 10 秒間に各タイプのステータスコードが返されたリクエストの数。たとえば、正常なリクエストには 200 OK、リダイレクトには 301 が返され、アプリケーション内のどのリソースとも一致しない URL が入力された場合は 404 が返されます。
EB CLI と [環境の状態ページ](health-enhanced-console.md#health-enhanced-console-healthpage) は、インスタンスへのリクエスト未処理数、そして環境内の総体的なリクエストのパーセンテージとしてこれらのメトリクスを示します。
`p99.9``p99``p95``p90``p85``p75``p50``p10`
最近 10 秒間で最も遅かったリクエストの *x* パーセントの平均レイテンシー。*x* はこの数値と 100 との差異です。たとえば、`p99 1.403` は、直前の 10 秒間に応答が返るのが最も遅かったリクエストの 1% の平均レイテンシーが 1.403 秒であったことを示します。
## オペレーティングシステムのメトリクス
Elastic Beanstalk ヘルスエージェントは、以下のオペレーティングシステムメトリクスを報告します。Elastic Beanstalk は、これらのメトリクスを使用して、継続的に重い負荷がかかっているインスタンスを識別します。メトリクスはオペレーティングシステムによって異なります。報告されているオペレーティングシステム (Linux)
`Running`
インスタンスが起動してから経過した時間。
`Load 1``Load 5`
直前の 1 分間と 5 分間の平均負荷。この期間に実行されていたプロセスの平均数を小数値で示します。表示された数が使用可能な vCPU（スレッド）の数よりも多い場合、余りは待機中だったプロセスの平均数です。
たとえば、インスタンスタイプが 4 vCPU であり、負荷が 4.5 である場合、その期間において、平均で .5 のプロセスが待機していたことになり、その期間の 50% にわたって 1 つのプロセスが待機していたことを意味します。
`User %``Nice %``System %``Idle %``I/O Wait %`
過去 10 秒間に CPU が各状態で費やした時間のパーセンテージ。報告されているオペレーティングシステム (Windows)
`Running`
インスタンスが起動してから経過した時間。
`% User Time``% Privileged Time``% Idle Time`
過去 10 秒間に CPU が各状態で費やした時間のパーセンテージ。
# Windows サーバー上の IIS でのウェブサーバーメトリクスキャプチャ
Windows Server プラットフォームでは、Elastic Beanstalk は IIS ウェブサーバーのリクエストパイプラインにモジュールを追加し、HTTP リクエスト時間と応答コードに関するメトリクスを取得します。モジュールは、高性能のプロセス間通信 (IPC) チャネルを使用して、これらのメトリクスをインスタンス上のヘルスエージェントに送信します。ヘルスエージェントは、これらのメトリクスを集計し、オペレーティングシステムメトリクスと組み合わせて、Elastic Beanstalk サービスに送信します。
## 実装の詳細
IIS からメトリクスを取得するために、Elastic Beanstalk はマネージド型 [https://msdn.microsoft.com/en-us/library/system.web.ihttpmodule%28v=vs.110%29.aspx](https://msdn.microsoft.com/en-us/library/system.web.ihttpmodule%28v=vs.110%29.aspx) を実装して、[https://msdn.microsoft.com/en-us/library/system.web.httpapplication.beginrequest(v=vs.110).aspx](https://msdn.microsoft.com/en-us/library/system.web.httpapplication.beginrequest(v=vs.110).aspx) および [https://msdn.microsoft.com/en-us/library/system.web.httpapplication.endrequest(v=vs.110).aspx](https://msdn.microsoft.com/en-us/library/system.web.httpapplication.endrequest(v=vs.110).aspx) イベントをサブスクライブします。これにより、モジュールのレイテンシーと応答コード HTTP リクエストを報告するウェブリクエストはすべて IIS によって処理されます。モジュールを IIS のリクエストパイプラインに追加するために、Elastic Beanstalk は IIS の設定ファイル、`%windir%\System32\inetsrv\config\applicationHost.config` の [https://docs.microsoft.com/en-us/iis/configuration/system.webserver/modules/](https://docs.microsoft.com/en-us/iis/configuration/system.webserver/modules/) セクションにモジュールを登録します。
IIS の Elastic Beanstalk モジュールは、キャプチャされたウェブリクエストモジュールメトリクスを、`HealthD` という名前の Windows サービスであるインスタンス上のヘルスエージェントに送信します。このデータを送信するために、モジュールは [https://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding(v=vs.110).aspx](https://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding(v=vs.110).aspx) を使用します。これは、マシン上の通信に最適化された安全で信頼性の高いバインディングを提供します。
# 環境の拡張ヘルスルールの設定
AWS Elastic Beanstalk 拡張ヘルスレポートは、環境のヘルスを判断するために一連のルールに依存します。これらのルールの一部は、特定のアプリケーションに適していない場合があります。一般的な例をいくつか以下に示します。
+ クライアント側のテストツールを使用する。この場合、HTTP クライアント (4xx) エラーが頻発することが予想されます。
+ [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/) を環境の Application Load Balancer と併用して不要な着信トラフィックをブロックします。この場合、Application Load Balancer は着信メッセージを拒否するたびに HTTP 403 を返します。
デフォルトでは、Elastic Beanstalk はアプリケーションのすべての HTTP 4xx エラーを反映して環境のヘルスを判断します。これにより、環境のヘルスステータスが **[OK]** から **[警告]**、**[低下]**、または **[重大]** へと、エラー率に応じて変更されます。上のような例に正しく対処するために、Elastic Beanstalk ではいくつかの拡張ヘルスルールを設定できます。環境のインスタンスでアプリケーションの HTTP 4xx エラーを無視するか、環境のロードバランサーから返された HTTP 4xx エラーを無視するかを選択できます。このトピックでは、これらの設定変更を行う方法について説明します。
**注記**
現在利用できる拡張ヘルスルールのカスタマイズは以上のみです。4xx 以外の HTTP エラーを無視するように拡張ヘルスを設定することはできません。
## Elastic Beanstalk コンソールを使用した拡張ヘルスレポートの設定
Elastic Beanstalk コンソールを使用して環境で拡張ヘルスルールを設定できます。
**Elastic Beanstalk コンソールを使用して HTTP 4xx ステータスコードのチェックを設定するには**
1. [Elastic Beanstalk コンソール](https://console.aws.amazon.com/elasticbeanstalk)を開き、**リージョン**リストで を選択します AWS リージョン。
1. ナビゲーションペインで、[**環境**] を選択し、リストから環境の名前を選択します。
1. ナビゲーションペインで、[**設定**] を選択します。
1. [**モニタリング**] 設定カテゴリで、[**編集**] を選択します。
1. [**Health monitoring rule customization**] で、該当する [**Ignore**] オプションを有効または無効にします。
![\[Elastic Beanstalk コンソールのモニタリング設定ページのヘルスモニタリングルールのカスタマイズセクション\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/enhanced-health-rule-customization.png)
1. ページの最下部で **[適用]** を選択し変更を保存します。
## EB CLI を使用して拡張ヘルスルールを設定する
EB CLI を使用すると、環境の設定をローカルに保存し、拡張ヘルスルールを設定するエントリを追加してから、その設定を Elastic Beanstalk にアップロードすることによって、拡張ヘルスルールを設定できます。保存した設定は、環境を作成する前または作成した後に環境に適用できます。
**EB CLI および保存済みの設定を使用して HTTP 4xx ステータスコードのチェックを設定するには**
1. [**eb init**](eb-cli3-configuration.md) でプロジェクトフォルダを初期化します。
1. **eb create** コマンドを実行して、環境を作成します。
1. **eb config save** コマンドを実行して、設定テンプレートをローカルに保存します。次の例では、`--cfg` オプションを使用して、設定の名前が指定されています。
```
$ eb config save --cfg 01-base-state
Configuration saved at: ~/project/.elasticbeanstalk/saved_configs/01-base-state.cfg.yml
```
1. 保存した設定ファイルをテキストエディタで開きます。
1. `OptionSettings` > `aws:elasticbeanstalk:healthreporting:system:` で、設定する各拡張ヘルスルールを一覧表示する `ConfigDocument` キーを追加します。次の `ConfigDocument` では、ロードバランサーの HTTP 4xx コードのチェックを有効にしたままで、アプリケーションの HTTP 4xx ステータスコードのチェックを無効にします。
```
OptionSettings:
...
aws:elasticbeanstalk:healthreporting:system:
ConfigDocument:
Rules:
Environment:
Application:
ApplicationRequests4xx:
Enabled: false
ELB:
ELBRequests4xx:
Enabled: true
Version: 1
SystemType: enhanced
...
```
**注記**
同じ `ConfigDocument` オプション設定で、`Rules` と `CloudWatchMetrics` を組み合わせることができます。`CloudWatchMetrics` については、「[環境の Amazon CloudWatch カスタムメトリクスの発行](health-enhanced-cloudwatch.md)」で説明しています。
以前に `CloudWatchMetrics` を有効にしている場合、**eb config save** コマンドを使用して取得した設定ファイルには、すでに `ConfigDocument` キーが `CloudWatchMetrics` セクションにあります。*削除しないでください*。同じ `ConfigDocument` オプション値に `Rules` セクションを追加します。
1. 設定ファイルを保存し、テキストエディタを閉じます。この例では、更新した設定ファイルは、ダウンロードした設定ファイルとは異なる名前 (`02-cloudwatch-enabled.cfg.yml`) で保存されています。このファイルがアップロードされると、別の保存済み設定が作成されます。ダウンロードしたファイル同じ名前を使用すると、新しいキーペアを作成せずに既存の設定を上書きできます。
1. **eb config put** コマンドを使用して、更新した設定ファイルを Elastic Beanstalk にアップロードします。
```
$ eb config put 02-cloudwatch-enabled
```
保存した設定に対して **eb config** `get` コマンドと `put` コマンドを使用するときは、ファイル名の拡張子を含めないでください。
1. 実行中の環境に、保存済みの設定を適用します。
```
$ eb config --cfg 02-cloudwatch-enabled
```
`--cfg` オプションは、環境に適用される名前付き設定ファイルを指定します。設定ファイルはローカルまたは Elastic Beanstalk に保存できます。指定した名前を持つ設定ファイルが両方の場所に存在する場合、EB CLI はローカルファイルを使用します。
## 設定ドキュメントを使用して拡張ヘルスルールを設定する
拡張ヘルスルールの設定 (config) ドキュメントは、設定するルールを一覧表示した JSON ドキュメントです。
次の例に示す設定ドキュメントでは、アプリケーションの HTTP 4xx ステータスコードのチェックを無効にし、ロードバランサーの HTTP 4xx ステータスコードのチェックを有効にします。
```
{
"Rules": {
"Environment": {
"Application": {
"ApplicationRequests4xx": {
"Enabled": false
}
},
"ELB": {
"ELBRequests4xx": {
"Enabled": true
}
}
}
},
"Version": 1
}
```
の場合 AWS CLI、 ドキュメントをオプション設定引数の`Value`キーの値として渡します。これは、それ自体が JSON オブジェクトです。この場合、埋め込まれているドキュメントの引用符はエスケープする必要があります。次のコマンドは、設定が有効であるかどうかを確認します。
```
$ aws elasticbeanstalk validate-configuration-settings --application-name my-app --environment-name my-env --option-settings '[
{
"Namespace": "aws:elasticbeanstalk:healthreporting:system",
"OptionName": "ConfigDocument",
"Value": "{\"Rules\": { \"Environment\": { \"Application\": { \"ApplicationRequests4xx\": { \"Enabled\": false } }, \"ELB\": { \"ELBRequests4xx\": {\"Enabled\": true } } } }, \"Version\": 1 }"
}
]'
```
YAML の `.ebextensions` 設定ファイルの場合は、JSON ドキュメントをそのまま提供できます。
```
option_settings:
- namespace: aws:elasticbeanstalk:healthreporting:system
option_name: ConfigDocument
value: {
"Rules": {
"Environment": {
"Application": {
"ApplicationRequests4xx": {
"Enabled": false
}
},
"ELB": {
"ELBRequests4xx": {
"Enabled": true
}
}
}
},
"Version": 1
}
```
# 環境の Amazon CloudWatch カスタムメトリクスの発行
AWS Elastic Beanstalk 拡張ヘルスレポートによって収集されたデータをカスタムメトリクスとして Amazon CloudWatch に公開できます。CloudWatch にメトリクスをパブリッシュすることにより、時間の経過に伴うアプリケーションのパフォーマンスの変化をモニタリングできるほか、リソースの使用状況やリクエストのレイテンシーが負荷に応じてどのようにスケーリングするかを追跡することによって、発生する可能性のある問題を特定できます。
また、CloudWatch にメトリクスをパブリッシュすることにより、[モニタリンググラフ](environment-health-console.md#environment-health-console-graphs)と[アラーム](using-features.alarms.md)でメトリクスを使用できます。無料のメトリクスである *EnvironmentHealth* は、拡張ヘルスレポートを使用するとき、自動的に有効になります。*EnvironmentHealth* 以外のカスタムメトリクスを使用する場合、[CloudWatch の標準料金](https://aws.amazon.com/cloudwatch/pricing/)が課金されます。
環境の CloudWatch カスタムメトリクスをパブリッシュするには、まず環境で拡張ヘルスレポートを有効にする必要があります。手順については「[Elastic Beanstalk の拡張ヘルスレポートの有効化](health-enhanced-enable.md)」を参照してください。
**Topics**
+ [拡張ヘルスレポートのメトリクス](#health-enhanced-cloudwatch-metrics)
+ [Elastic Beanstalk コンソールを使用した CloudWatch メトリクスの設定](#health-enhanced-cloudwatch-console)
+ [EB CLI を使用した CloudWatch カスタムメトリクスの設定](#health-enhanced-cloudwatch-ebcli)
+ [カスタムメトリクス設定ドキュメントの提供](#health-enhanced-cloudwatch-configdocument)
## 拡張ヘルスレポートのメトリクス
環境で拡張ヘルスレポートを有効にすると、拡張ヘルスレポートシステムが [CloudWatch カスタムメトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/publishingMetrics.html)の 1 つである *EnvironmentHealth* を自動的にパブリッシュします。追加のメトリクスを CloudWatch にパブリッシュするには、[Elastic Beanstalk コンソール](#health-enhanced-cloudwatch-console)、[EB CLI](#health-enhanced-cloudwatch-ebcli)、または [.ebextensions](command-options.md) を使用して、これらのメトリクスで環境を設定します。
環境から、次の拡張ヘルスメトリクスを CloudWatch にパブリッシュすることができます。使用可能なメトリクス - すべてのプラットフォーム
`EnvironmentHealth`
*環境のみが対象。*他のメトリクスを設定していなければ、拡張ヘルスレポートシステムからパブリッシュされる唯一の CloudWatch メトリクスです。環境の状態は、7 種類の[ステータス](health-enhanced-status.md)のいずれかで表されます。CloudWatch コンソールでは、これらのステータスは以下の値にマッピングされます。
+ 0 – OK
+ 1 – Info
+ 5 – Unknown
+ 10 – No data
+ 15 – Warning
+ 20 – Degraded
+ 25 – Severe
`InstancesSevere``InstancesDegraded``InstancesWarning``InstancesInfo``InstancesOk``InstancesPending``InstancesUnknown``InstancesNoData`
*環境のみが対象。*これらのメトリクスは、各ヘルスステータスにある環境内のインスタンスの数を示します。`InstancesNoData` は、データを受け取っていないインスタンスの数を示します (該当する場合)。
`ApplicationRequestsTotal``ApplicationRequests5xx``ApplicationRequests4xx``ApplicationRequests3xx``ApplicationRequests2xx`
*インスタンスと環境が対象。*インスタンスまたは環境で完了したリクエストの総数と、各ステータスコードカテゴリで完了したリクエストの数を示します。
`ApplicationLatencyP10``ApplicationLatencyP50``ApplicationLatencyP75``ApplicationLatencyP85``ApplicationLatencyP90``ApplicationLatencyP95``ApplicationLatencyP99``ApplicationLatencyP99.9`
*インスタンスと環境が対象。*リクエストのうち、早い方から *x* パーセントの完了にかかった平均時間を直ちに示します。
`InstanceHealth`
*インスタンスのみが対象。*インスタンスの現在のヘルスステータスを示します。インスタンスの状態は、7 種類の[ステータス](health-enhanced-status.md)のいずれかで表されます。CloudWatch コンソールでは、これらのステータスは以下の値にマッピングされます。
+ 0 – OK
+ 1 – Info
+ 5 – Unknown
+ 10 – No data
+ 15 – Warning
+ 20 – Degraded
+ 25 – Severe使用可能なメトリクス - Linux
`CPUIrq``CPUIdle``CPUUser``CPUSystem``CPUSoftirq``CPUIowait``CPUNice`
*インスタンスのみが対象。*過去 1 分間に CPU が各状態で消費した時間の割合を示します。
`LoadAverage1min`
*インスタンスのみが対象。*インスタンスに関する過去 1 分間の CPU 負荷の平均値。
`RootFilesystemUtil`
*インスタンスのみが対象。*使用中のディスク容量の割合を示します。利用可能なメトリクス - Windows
`CPUIdle``CPUUser``CPUPrivileged`
インスタンスのみが対象。過去 1 分間に CPU が各状態で消費した時間の割合を示します。
## Elastic Beanstalk コンソールを使用した CloudWatch メトリクスの設定
Elastic Beanstalk コンソールを使用して、拡張ヘルスレポートのメトリクスを CloudWatch にパブリッシュし、モニタリンググラフとアラームで使用できるように環境を設定できます。
**Elastic Beanstalk コンソールで CloudWatch カスタムメトリクスを設定するには**
1. [Elastic Beanstalk コンソール](https://console.aws.amazon.com/elasticbeanstalk)を開き、**リージョン**リストで を選択します AWS リージョン。
1. ナビゲーションペインで、[**環境**] を選択し、リストから環境の名前を選択します。
1. ナビゲーションペインで、[**設定**] を選択します。
1. [**モニタリング**] 設定カテゴリで、[**編集**] を選択します。
1. [**Health reporting (ヘルプレポート)**] で、CloudWatch に公開するインスタンスと環境のメトリクスを選択します。複数のメトリクスを選択するには、**Ctrl** キーを押して選択します。
1. ページの最下部で **[適用]** を選択し変更を保存します。
CloudWatch カスタムメトリクスを有効にすると、[[**Monitoring (モニタリング)**] ページ](environment-health-console.md)で使用できるメトリクスのリストにこれらのメトリクスが追加されます。
## EB CLI を使用した CloudWatch カスタムメトリクスの設定
EB CLI を使用すると、環境の設定をローカルに保存し、パブリッシュするメトリクスを定義するエントリを追加してから、その設定を Elastic Beanstalk にアップロードすることによって、カスタムメトリクスを設定できます。保存した設定は、環境を作成する前または作成した後に環境に適用できます。
**EB CLI と保存した設定を使用して CloudWatch カスタムメトリクスを設定するには**
1. [**eb init**](eb-cli3-configuration.md) でプロジェクトフォルダを初期化します。
1. **eb create** コマンドを実行して、環境を作成します。
1. **eb config save** コマンドを実行して、設定テンプレートをローカルに保存します。次の例では、`--cfg` オプションを使用して、設定の名前が指定されています。
```
$ eb config save --cfg 01-base-state
Configuration saved at: ~/project/.elasticbeanstalk/saved_configs/01-base-state.cfg.yml
```
1. 保存した設定ファイルをテキストエディタで開きます。
1. `OptionSettings` > `aws:elasticbeanstalk:healthreporting:system:` で、CloudWatch メトリクスを個別に有効にする `ConfigDocument` キーを追加します。たとえば、次に示す `ConfigDocument` は、環境レベルで `ApplicationRequests5xx` メトリクスと `ApplicationRequests4xx` メトリクスをパブリッシュし、インスタンスレベルで `ApplicationRequestsTotal` メトリクスをパブリッシュします。
```
OptionSettings:
...
aws:elasticbeanstalk:healthreporting:system:
ConfigDocument:
CloudWatchMetrics:
Environment:
ApplicationRequests5xx: 60
ApplicationRequests4xx: 60
Instance:
ApplicationRequestsTotal: 60
Version: 1
SystemType: enhanced
...
```
この例では、60 は測定間隔の秒数を示しています。これは、現在サポートされている唯一の値です。
**注記**
同じ `ConfigDocument` オプション設定で、`CloudWatchMetrics` と `Rules` を組み合わせることができます。`Rules` については、「[環境の拡張ヘルスルールの設定](health-enhanced-rules.md)」で説明しています。
以前に `Rules` を使用して拡張ヘルスルールを設定している場合、**eb config save** コマンドを使用して取得される設定ファイルには、既に `ConfigDocument` キーが `Rules` セクションにあります。*削除しないでください*。同じ `ConfigDocument` オプション値に `CloudWatchMetrics` セクションを追加します。
1. 設定ファイルを保存し、テキストエディタを閉じます。この例では、更新した設定ファイルは、ダウンロードした設定ファイルとは異なる名前 (`02-cloudwatch-enabled.cfg.yml`) で保存されています。このファイルがアップロードされると、別の保存済み設定が作成されます。ダウンロードしたファイル同じ名前を使用すると、新しいキーペアを作成せずに既存の設定を上書きできます。
1. **eb config put** コマンドを使用して、更新した設定ファイルを Elastic Beanstalk にアップロードします。
```
$ eb config put 02-cloudwatch-enabled
```
保存した設定に対して **eb config** `get` コマンドと `put` コマンドを使用するときは、ファイル拡張子を含めないでください。
1. 実行中の環境に、保存済みの設定を適用します。
```
$ eb config --cfg 02-cloudwatch-enabled
```
`--cfg` オプションは、環境に適用される名前付き設定ファイルを指定します。設定ファイルはローカルまたは Elastic Beanstalk に保存できます。指定した名前を持つ設定ファイルが両方の場所に存在する場合、EB CLI はローカルファイルを使用します。
## カスタムメトリクス設定ドキュメントの提供
Amazon CloudWatch カスタムメトリクスの設定 (config) ドキュメントは、環境レベルとインスタンスレベルでパブリッシュするメトリクスを一覧表示する JSON ドキュメントです。次の例は、すべての利用可能なカスタムメトリクスを Linux で有効にする設定ドキュメントを示しています。
```
{
"CloudWatchMetrics": {
"Environment": {
"ApplicationLatencyP99.9": 60,
"InstancesSevere": 60,
"ApplicationLatencyP90": 60,
"ApplicationLatencyP99": 60,
"ApplicationLatencyP95": 60,
"InstancesUnknown": 60,
"ApplicationLatencyP85": 60,
"InstancesInfo": 60,
"ApplicationRequests2xx": 60,
"InstancesDegraded": 60,
"InstancesWarning": 60,
"ApplicationLatencyP50": 60,
"ApplicationRequestsTotal": 60,
"InstancesNoData": 60,
"InstancesPending": 60,
"ApplicationLatencyP10": 60,
"ApplicationRequests5xx": 60,
"ApplicationLatencyP75": 60,
"InstancesOk": 60,
"ApplicationRequests3xx": 60,
"ApplicationRequests4xx": 60
},
"Instance": {
"ApplicationLatencyP99.9": 60,
"ApplicationLatencyP90": 60,
"ApplicationLatencyP99": 60,
"ApplicationLatencyP95": 60,
"ApplicationLatencyP85": 60,
"CPUUser": 60,
"ApplicationRequests2xx": 60,
"CPUIdle": 60,
"ApplicationLatencyP50": 60,
"ApplicationRequestsTotal": 60,
"RootFilesystemUtil": 60,
"LoadAverage1min": 60,
"CPUIrq": 60,
"CPUNice": 60,
"CPUIowait": 60,
"ApplicationLatencyP10": 60,
"LoadAverage5min": 60,
"ApplicationRequests5xx": 60,
"ApplicationLatencyP75": 60,
"CPUSystem": 60,
"ApplicationRequests3xx": 60,
"ApplicationRequests4xx": 60,
"InstanceHealth": 60,
"CPUSoftirq": 60
}
},
"Version": 1
}
```
の場合 AWS CLI、 ドキュメントをオプション設定引数の`Value`キーの値として渡します。これは、それ自体が JSON オブジェクトです。この場合、埋め込まれているドキュメントの引用符はエスケープする必要があります。
```
$ aws elasticbeanstalk validate-configuration-settings --application-name my-app --environment-name my-env --option-settings '[
{
"Namespace": "aws:elasticbeanstalk:healthreporting:system",
"OptionName": "ConfigDocument",
"Value": "{\"CloudWatchMetrics\": {\"Environment\": {\"ApplicationLatencyP99.9\": 60,\"InstancesSevere\": 60,\"ApplicationLatencyP90\": 60,\"ApplicationLatencyP99\": 60,\"ApplicationLatencyP95\": 60,\"InstancesUnknown\": 60,\"ApplicationLatencyP85\": 60,\"InstancesInfo\": 60,\"ApplicationRequests2xx\": 60,\"InstancesDegraded\": 60,\"InstancesWarning\": 60,\"ApplicationLatencyP50\": 60,\"ApplicationRequestsTotal\": 60,\"InstancesNoData\": 60,\"InstancesPending\": 60,\"ApplicationLatencyP10\": 60,\"ApplicationRequests5xx\": 60,\"ApplicationLatencyP75\": 60,\"InstancesOk\": 60,\"ApplicationRequests3xx\": 60,\"ApplicationRequests4xx\": 60},\"Instance\": {\"ApplicationLatencyP99.9\": 60,\"ApplicationLatencyP90\": 60,\"ApplicationLatencyP99\": 60,\"ApplicationLatencyP95\": 60,\"ApplicationLatencyP85\": 60,\"CPUUser\": 60,\"ApplicationRequests2xx\": 60,\"CPUIdle\": 60,\"ApplicationLatencyP50\": 60,\"ApplicationRequestsTotal\": 60,\"RootFilesystemUtil\": 60,\"LoadAverage1min\": 60,\"CPUIrq\": 60,\"CPUNice\": 60,\"CPUIowait\": 60,\"ApplicationLatencyP10\": 60,\"LoadAverage5min\": 60,\"ApplicationRequests5xx\": 60,\"ApplicationLatencyP75\": 60,\"CPUSystem\": 60,\"ApplicationRequests3xx\": 60,\"ApplicationRequests4xx\": 60,\"InstanceHealth\": 60,\"CPUSoftirq\": 60}},\"Version\": 1}"
}
]'
```
YAML の `.ebextensions` 設定ファイルの場合は、JSON ドキュメントをそのまま提供できます。
```
option_settings:
- namespace: aws:elasticbeanstalk:healthreporting:system
option_name: ConfigDocument
value: {
"CloudWatchMetrics": {
"Environment": {
"ApplicationLatencyP99.9": 60,
"InstancesSevere": 60,
"ApplicationLatencyP90": 60,
"ApplicationLatencyP99": 60,
"ApplicationLatencyP95": 60,
"InstancesUnknown": 60,
"ApplicationLatencyP85": 60,
"InstancesInfo": 60,
"ApplicationRequests2xx": 60,
"InstancesDegraded": 60,
"InstancesWarning": 60,
"ApplicationLatencyP50": 60,
"ApplicationRequestsTotal": 60,
"InstancesNoData": 60,
"InstancesPending": 60,
"ApplicationLatencyP10": 60,
"ApplicationRequests5xx": 60,
"ApplicationLatencyP75": 60,
"InstancesOk": 60,
"ApplicationRequests3xx": 60,
"ApplicationRequests4xx": 60
},
"Instance": {
"ApplicationLatencyP99.9": 60,
"ApplicationLatencyP90": 60,
"ApplicationLatencyP99": 60,
"ApplicationLatencyP95": 60,
"ApplicationLatencyP85": 60,
"CPUUser": 60,
"ApplicationRequests2xx": 60,
"CPUIdle": 60,
"ApplicationLatencyP50": 60,
"ApplicationRequestsTotal": 60,
"RootFilesystemUtil": 60,
"LoadAverage1min": 60,
"CPUIrq": 60,
"CPUNice": 60,
"CPUIowait": 60,
"ApplicationLatencyP10": 60,
"LoadAverage5min": 60,
"ApplicationRequests5xx": 60,
"ApplicationLatencyP75": 60,
"CPUSystem": 60,
"ApplicationRequests3xx": 60,
"ApplicationRequests4xx": 60,
"InstanceHealth": 60,
"CPUSoftirq": 60
}
},
"Version": 1
}
```
# Elastic Beanstalk API での拡張ヘルスレポートの使用
AWS Elastic Beanstalk 拡張ヘルスレポートにはロールとソリューションスタックの要件があるため、拡張ヘルスレポートをリリースする前に使用したスクリプトとコードを更新する必要があります。下位互換性を維持するため、拡張ヘルスレポートは、Elastic Beanstalk API を使用して環境を作成するとき、デフォルトでは有効になりません。
環境のサービスロール、インスタンスプロファイル、および Amazon CloudWatch 設定オプションを設定することによって、拡張ヘルスレポートを設定します。これは、`.ebextensions` フォルダーで設定オプションを設定する、保存されている設定を使用する、または `create-environment` 呼び出しの `option-settings` パラメータで直接設定オプションを設定することによって行うことができます。
API、SDKs、または AWS コマンドラインインターフェイス (CLI) を使用して拡張ヘルスをサポートする環境を作成するには、以下を実行する必要があります。
+ 適切な[アクセス権限](concepts-roles.md)を含むサービスロールとインスタンスプロファイルを作成する
+ 新しい[プラットフォームのバージョン](concepts.platforms.md)で新しい環境を作成する
+ ヘルスシステムのタイプ、インスタンスプロファイル、サービスロールの[設定オプション](command-options.md)を設定する
`aws:elasticbeanstalk:healthreporting:system`、`aws:autoscaling:launchconfiguration`、および `aws:elasticbeanstalk:environment` の 3 つの名前空間で以下の設定オプションを使用して、拡張ヘルスレポートの環境を設定します。
## 拡張ヘルスの設定オプション
**SystemType**
名前空間: `aws:elasticbeanstalk:healthreporting:system`
拡張ヘルスレポートを有効にするには、「**enhanced**」に設定します。
**IamInstanceProfile**
名前空間: `aws:autoscaling:launchconfiguration`
Elastic Beanstalk 用に設定されたインスタンスプロファイルの名前に設定します。
**ServiceRole**
名前空間: `aws:elasticbeanstalk:environment`
Elastic Beanstalk 用に設定されたサービスロールの名前に設定します。
**ConfigDocument** (オプション)
名前空間: `aws:elasticbeanstalk:healthreporting:system`
インスタンスと CloudWatch にパブリッシュする環境メトリクスを定義する JSON ドキュメント。次に例を示します。
```
{
"CloudWatchMetrics":
{
"Environment":
{
"ApplicationLatencyP99.9":60,
"InstancesSevere":60
}
"Instance":
{
"ApplicationLatencyP85":60,
"CPUUser": 60
}
}
"Version":1
}
```
**注記**
設定ドキュメントでは、Elastic Beanstalk への提供方法に応じて、引用符のエスケープなどの特別なフォーマットが必要になることがあります。例については、「[カスタムメトリクス設定ドキュメントの提供](health-enhanced-cloudwatch.md#health-enhanced-cloudwatch-configdocument)」を参照してください。
# 拡張ヘルスログ形式
AWS Elastic Beanstalk プラットフォームは、カスタムウェブサーバーログ形式を使用して、HTTP リクエストに関する情報を拡張ヘルスレポートシステムに効率的に中継します。システムはログを分析し、問題を特定して、それに基づいてインスタンスと環境ヘルスを設定します。対象環境でウェブサーバープロキシを無効にし、ウェブコンテナから直接リクエストを処理する場合でも、[Elastic Beanstalk ヘルスエージェント](health-enhanced.md#health-enhanced-agent)によって使用される場所と形式でログを出力するようにサーバーを設定することで、拡張ヘルスレポートを最大限に活用できます。
**注記**
このページの情報は、Linux ベースのプラットフォームにのみ関係します。Windows Server プラットフォームでは、Elastic Beanstalk は HTTP リクエストに関する情報を IIS ウェブサーバーから直接受け取ります。詳細については、「[Windows サーバー上の IIS でのウェブサーバーメトリクスキャプチャ](health-enhanced-metrics-server-iis.md)」を参照してください。
## ウェブサーバーログ設定
Elastic Beanstalk プラットフォームは、HTTP リクエストに関する情報を含む 2 つのログを出力するように設定されています。最初のログは、詳細形式であり、リクエストに関する詳細な情報（リクエスタのユーザーエージェント情報や人間が読み取れる形式のタイムスタンプなど）を提供します。
**/var/log/nginx/access.log**
以下の例は、Ruby ウェブサーバー環境で実行されている nginx プロキシのものですが、その形式は Apache のものに似ています。
```
172.31.24.3 - - [23/Jul/2015:00:21:20 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
172.31.24.3 - - [23/Jul/2015:00:21:21 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
172.31.24.3 - - [23/Jul/2015:00:21:22 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
172.31.24.3 - - [23/Jul/2015:00:21:22 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
172.31.24.3 - - [23/Jul/2015:00:21:22 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
```
2 つ目のログは、簡易形式です。これは、拡張ヘルスレポートに関連する情報のみを提供します。このログは、`healthd` という名前のサブフォルダに出力され、1 時間ごとにローテーションされます。古いログは、ローテーション直後に削除されます。
**/var/log/nginx/healthd/application.log.2015-07-23-00**
次の例は、機械による読み取りが可能な形式のログを示しています。
```
1437609879.311"/"200"0.083"0.083"177.72.242.17
1437609879.874"/"200"0.347"0.347"177.72.242.17
1437609880.006"/bad/path"404"0.001"0.001"177.72.242.17
1437609880.058"/"200"0.530"0.530"177.72.242.17
1437609880.928"/bad/path"404"0.001"0.001"177.72.242.17
```
拡張ヘルスログ形式には、以下の情報が含まれます。
+ リクエストの時間 (Unix 時間)。
+ リクエストのパス
+ 結果に対応する HTTP ステータスコード
+ リクエスト時間
+ アップストリーム時間
+ `X-Forwarded-For` HTTP ヘッダー
nginx プロキシでは、時間は小数点以下 3 桁の浮動小数点の秒数で表示されます。Apache では、整数で表したミリ秒数が使用されます。
**注記**
次のような警告 (`DATE-TIME` は日付と時刻) がログファイルに表示される場合で、マルチコンテナ Docker 環境などでカスタムプロキシを使用しているときは、`healthd` がログファイルを読み込むことができるように、.ebextension を使用して環境を設定する必要があります。
```
W, [DATE-TIME #1922] WARN -- : log file "/var/log/nginx/healthd/application.log.DATE-TIME" does not exist
```
.ebextension は[マルチコンテナ Docker のサンプル](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/samples/docker-multicontainer-v2.zip)から開始できます。
**/etc/nginx/conf.d/webapp\$1healthd.conf**
この例は、`healthd` ログ形式が強調表示されている nginx のログ設定を示しています。
```
upstream my_app {
server unix:///var/run/puma/my_app.sock;
}
log_format healthd '$msec"$uri"'
'$status"$request_time"$upstream_response_time"'
'$http_x_forwarded_for';
server {
listen 80;
server_name _ localhost; # need to listen to localhost for worker tier
if ($time_iso8601 ~ "^(\d{4})-(\d{2})-(\d{2})T(\d{2})") {
set $year $1;
set $month $2;
set $day $3;
set $hour $4;
}
access_log /var/log/nginx/access.log main;
access_log /var/log/nginx/healthd/application.log.$year-$month-$day-$hour healthd;
location / {
proxy_pass http://my_app; # match the name of upstream directive which is defined above
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /assets {
alias /var/app/current/public/assets;
gzip_static on;
gzip on;
expires max;
add_header Cache-Control public;
}
location /public {
alias /var/app/current/public;
gzip_static on;
gzip on;
expires max;
add_header Cache-Control public;
}
}
```
**/etc/httpd/conf.d/healthd.conf**
次の例は、Apache のログ設定を示します。
```
LogFormat "%{%s}t\"%U\"%s\"%D\"%D\"%{X-Forwarded-For}i" healthd
CustomLog "|/usr/sbin/rotatelogs /var/log/httpd/healthd/application.log.%Y-%m-%d-%H 3600" healthd
```
## 拡張ヘルスレポート用のログの生成
ヘルスエージェントにログを提供するには、以下の操作を行う必要があります。
+ 前のセクションで示したように、正しい形式でログを出力する
+ ログを `/var/log/nginx/healthd/` に出力する
+ `application.log.$year-$month-$day-$hour`
+ ログを 1 時間に 1 回ローテーションさせる
+ ログは切り捨てないでください
# 通知とトラブルシューティング
**AI アシストによるトラブルシューティングのために Amazon Q Developer CLI を試す**
Amazon Q Developer CLI は、環境の問題を迅速にトラブルシューティングするのに役立ちます。Q CLI は、環境ステータスのチェック、イベントの確認、ログの分析、および明確化のための質問を行うことでソリューションを提供します。詳細と詳細なチュートリアルについては、 AWS ブログの[「Amazon Q Developer CLI を使用した Elastic Beanstalk 環境のトラブルシューティング](https://aws.amazon.com/blogs/devops/troubleshooting-elastic-beanstalk-environments-with-amazon-q-developer-cli/)」を参照してください。
このページには、一般的な問題に対するメッセージと詳細情報へのリンクが一覧表示されます。いくつかのチェックにわたって持続的に状態に問題があることが検出されると、メッセージが Elastic Beanstalk コンソールの [環境の概要のペイン](environments-dashboard-envoverview.md) に表示され、[イベント](using-features.events.md)に記録されます。
## デプロイ
Elastic Beanstalk は、環境のデプロイ後の整合性を監視します。ローリングデプロイに失敗した場合、環境のインスタンスで実行されているアプリケーションバージョンが異なっている可能性があります。これは、デプロイが 1 つあるいは複数のバッチで成功しても、すべてのバッチへのデプロイが完了する前に失敗した場合に起こります。
5 つのインスタンスのうち 2 つで正しくないアプリケーションバージョンが検出された。予想されるバージョン「v1」(デプロイ 1)。
環境インスタンスのアプリケーションバージョンが正しくない。予想されるバージョン「v1」(デプロイ 1)。
予想されるアプリケーションバージョンが、環境内のいくつかの、あるいはすべてのインスタンスで起動していない。
正しくないアプリケーションバージョン「v2」(デプロイ 2)。予想されるバージョン「v1」(デプロイ 1)。
インスタンスにデプロイされているアプリケーションが、予想されるバージョンとは異なります。デプロイが失敗すると、予想されるバージョンがもっとも直近の成功したデプロイのバージョンにリセットされます。上記の例では、最初のデプロイ（バージョン「v1」）は成功し、2 番目デプロイ（バージョン「v2」）は失敗しています。「v2」を実行するインスタンスは、正常な状態ではないみなされます。
この問題を解決し、別のデプロイを開始します。機能していた[前のバージョンを再度デプロイ](using-features.deploy-existing-version.md)するか、環境をデプロイ中は[ヘルスチェックを無視する](using-features.rolling-version-deploy.md#environments-cfg-rollingdeployments-console)ように設定し、デプロイを強制的に完了させるため新しいバージョンを再度デプロイします。
また、間違ったアプリケーションバージョンを実行しているインスタンスを特定し、終了することもできます。Elastic Beanstalk は、正しいバージョンのインスタンスを起動し、終了させたインスタンスと置き換えます。[EB CLI ヘルスコマンド](health-enhanced-ebcli.md)を使って、間違ったアプリケーションバージョンを実行しているインスタンスを識別します。
## アプリケーションサーバー
*15% of requests are erroring with HTTP 4xx*
*20% of the requests to the ELB are erroring with HTTP 4xx.*
インスタンスまたは環境に対する HTTP リクエストの多くが 4xx エラーを原因として失敗しています。
400 シリーズのステータスコードは、ユーザーが存在しないページをリクエスト（404 File Not Found）するなどの不適切なリクエストをした、またはユーザーにはアクセスする権利がない（403 Forbidden）ことを示します。404 の数が低いことは珍しくありませんが、その数が多いと、存在しないページへの内部リンクまたは外部リンクがあることを意味する場合があります。このような問題は、不適切な内部リンクを修正し、不適切な外部リンクにリダイレクトを追加することによって解決できます。
*5% of the requests are failing with HTTP 5xx*
*3% of the requests to the ELB are failing with HTTP 5xx.*
インスタンスまたは環境に対する HTTP リクエストの多くが 500 シリーズのステータスコードを原因として失敗しています。
500 シリーズのステータスコードは、アプリケーションサーバーで内部エラーが発生したことを示します。このような問題は、アプリケーションコードにエラーがあり、迅速にエラーを特定し、修正する必要があることを示します。
*95% of CPU is in use*
インスタンスについて、ヘルスエージェントが非常に高い CPU 使用率をレポートしており、インスタンスのヘルスステータスが **Warning** または **Degraded** に設定されています。
環境をスケールしてインスタンスの負荷を軽減します。
## ワーカーインスタンス
*20 messages waiting in the queue (25 seconds ago)*
リクエストの処理速度よりも速くリクエストがワーカー環境のキューに追加されています。環境をスケールして処理能力を向上させます。
*5 messages in Dead Letter Queue (15 seconds ago)*
ワーカーリクエストが繰り返し失敗しており、[デッドレターキュー](using-features-managing-env-tiers.md#worker-deadletter) に追加されています。デッドレターキュー内のリクエストをチェックして、失敗している理由を確認します。
## その他のリソース
*4 active instances is below Auto Scaling group minimum size 5*
環境内で実行されているインスタンスの数が、Auto Scaling グループに対して設定されている最小数に達していません。
*Auto Scaling group (groupname) notifications have been deleted or modified*
Auto Scaling グループに対して設定されている通知が Elastic Beanstalk 外部で修正されています。
# AI を活用した環境分析
AWS Elastic Beanstalkの AI を活用した分析は根本原因を特定し、環境のヘルス問題に対する解決策を推奨します。環境で問題が発生した場合は、 `RequestEnvironmentInfo`および `RetrieveEnvironmentInfo` API オペレーションと `analyze`情報タイプを使用して AI 分析をリクエストし、AI 生成のインサイトと推奨されるソリューションを取得できます。
**注記**
AI 分析は、2026 年 2 月 16 日以降にリリースされた、サポートされている Amazon Linux 2 および AL2023 プラットフォームバージョンでのみ使用できます。
## 仕組み
AI 分析をリクエストすると、Elastic Beanstalk は環境内のインスタンスでスクリプトを実行し、最近のイベント、インスタンスの状態、ログ (最大 170,000 トークンのデータ) を収集[します](https://docs.aws.amazon.com/bedrock/latest/userguide/key-definitions.html)。次に、このデータをアカウントの Amazon Bedrock に送信し、インサイトと推奨される次のステップを返します。
## 前提条件
AI 分析を使用する前に、環境が次の要件を満たしていることを確認してください。
+ [サポートされているプラットフォームバージョン](#health-ai-analysis-supported-platforms)を実行している環境
+ 必要なアクセス許可を持つ[インスタンスプロファイル](iam-instanceprofile.md) ([必要なアクセス許可](#health-ai-analysis-permissions)以下を参照)
+ **Anthropic ユースケースの詳細** – AI 分析では、Amazon Bedrock を介して Anthropic Claude モデルを使用します。Anthropic では、モデルを呼び出す前に 1 回限りのユースケースの詳細フォームを送信する必要があります。このフォームを送信するには、[Amazon Bedrock コンソール](https://console.aws.amazon.com/bedrock/)のモデルカタログから Anthropic モデルを選択するか、 [https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutUseCaseForModelAccess.html](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutUseCaseForModelAccess.html) API を呼び出します。これを行う必要があるのは AWS 、アカウントごとに 1 回のみです。 AWS Organizations 管理アカウントからフォームを送信すると、組織内のすべてのメンバーアカウントが自動的にカバーされます。詳細については、[「Amazon Bedrock 基盤モデルにアクセスする](https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html)」を参照してください。
+ **GovCloud リージョン** – AWS GovCloud (米国) リージョンを使用している場合は、AI 分析を使用する前に、Amazon Bedrock で最新の Anthropic Claude Sonnet および/または Opus モデルへのアクセスを有効にする必要があります。GovCloud リージョンでモデルアクセスを有効にする手順については、[「Amazon Bedrock 基盤モデルへのアクセスを管理する](https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html#model-access-govcloud)」を参照してください。利用可能な最新の Anthropic Claude Sonnet および/または Opus モデルの詳細については、[「推論プロファイルでサポートされているリージョンとモデル](https://docs.aws.amazon.com/bedrock/latest/userguide/inference-profiles-support.html)」を参照してください。
## 必要なアクセス許可
AI 分析を使用するには、環境の Amazon EC2 インスタンスプロファイルに Amazon Bedrock を呼び出すアクセス許可が必要です。インスタンスプロファイルに次のアクセス許可を追加します。
+ `bedrock:InvokeModel`
+ `bedrock:ListFoundationModels`
+ `elasticbeanstalk:DescribeEvents`
+ `elasticbeanstalk:DescribeEnvironmentHealth`
インスタンスプロファイルの設定の詳細については、「」を参照してください[Elastic Beanstalk インスタンスプロファイルの管理](iam-instanceprofile.md)。
## コンソールでの AI 分析の使用
**環境の概要から**
環境のヘルスステータスが **Warning**、**Degraded**、または **Severe** の場合、**AI 分析**ボタンが環境概要セクションに表示されます。このボタンをクリックして、環境の AI 分析を開始します。
**ログページから**
ナビゲーションペインの**ログ**ページから AI 分析にアクセスすることもできます。**AI 分析**ボタンをクリックして、環境の現在の状態の AI を活用した分析をリクエストします。
## での AI 分析の使用 AWS CLI
を通じて Elastic Beanstalk API を使用して、プログラムで AI 分析 AWS CLI をリクエストおよび取得できます。
**AI 分析をリクエストする**
`InfoType` パラメータを に設定して [https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RequestEnvironmentInfo.html](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RequestEnvironmentInfo.html)オペレーションを使用します`analyze`。
**Example AWS CLI - AI 分析をリクエストする**
```
aws elasticbeanstalk request-environment-info \
--environment-name my-env \
--info-type analyze \
--region us-east-1
```
**AI 分析を取得する**
`InfoType` パラメータを に設定して [https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RetrieveEnvironmentInfo.html](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RetrieveEnvironmentInfo.html)オペレーション`analyze`を使用して、分析結果を取得します。
**Example AWS CLI - AI 分析を取得する**
```
aws elasticbeanstalk retrieve-environment-info \
--environment-name my-env \
--info-type analyze \
--region us-east-1
```
レスポンスには、環境の現在の状態の AI 生成分析と、特定された問題に対する推奨される解決策が含まれます。
## EB CLI での AI 分析の使用
EB CLI を使用する場合は、 **eb logs** コマンドの `--analyze` (`-ai`) オプションを使用して AI 分析をリクエストできます。コマンドは分析をリクエストし、分析が完了するまで待機し、結果を表示します。
**Example EB CLI - AI 分析をリクエストする**
```
$ eb logs --analyze
```
`--analyze` オプションは、`--instance`、、`--all`、`--zip`または と互換性がありません`--log-group`。コマンドの完全なリファレンスについては、「」を参照してください[**eb logs**](eb3-logs.md)。
**注記**
`--analyze` オプションには、EB CLI バージョン 3.27 以降が必要です。
## 重要な考慮事項
+ **料金** – AI 分析では Amazon Bedrock を使用して環境データを処理します。モデル呼び出しには標準の Amazon Bedrock 料金が適用されます。料金の詳細については、「[Amazon Bedrock の料金](https://aws.amazon.com/bedrock/pricing/)」を参照してください。
+ **プラットフォーム要件** – AI 分析は、2026 年 2 月 16 日以降にリリースされた Amazon Linux 2 および AL2023 ベースのプラットフォームバージョンでのみ使用できます。この機能を使用するには、サポートされているプラットフォームバージョンに環境を更新します。詳細については、「[Elastic Beanstalk 環境のプラットフォームバージョンの更新](using-features.platform.upgrade.md)」を参照してください。
+ アクセス**許可** – AI 分析を使用する前に、インスタンスプロファイルに必要な Amazon Bedrock アクセス許可 (`bedrock:InvokeModel` および `bedrock:ListFoundationModels`) と Elastic Beanstalk アクセス許可 (`elasticbeanstalk:DescribeEvents` および ) があることを確認してください`elasticbeanstalk:DescribeEnvironmentHealth`。
+ **データプライバシー** – 分析は、処理のために アカウントの Amazon Bedrock に環境イベントとログを送信します。Amazon Bedrock がデータを処理する方法については、[「Amazon Bedrock Security and Compliance](https://aws.amazon.com/bedrock/security-compliance/)」を参照してください。
+ **サービスクォータ** – AI 分析では、Amazon Bedrock の Anthropic Claude モデルを使用します。このモデルには、1 分あたりのリクエスト数と 1 分あたりのトークン数のデフォルトのクォータがあります。スロットリングエラーが発生した場合は、クォータの引き上げをリクエストできます。詳細については、「[Requesting a quota increase](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)」(クォータ引き上げのリクエスト) を参照してください。
## サポートされるプラットフォームのバージョン
AI 分析は、2026 年 2 月 16 日以降にリリースされた Amazon Linux 2 および AL2023 [RELEASE_NOTES_URL](RELEASE_NOTES_URL)ベースのプラットフォームバージョンでサポートされています。プラットフォームのバージョンを確認するには、[「Elastic Beanstalk リリースノート](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/welcome.html)」を参照してください。
# アラームを管理する
このトピックでは、モニタリングしているメトリクスのアラームを作成する手順について説明します。また、既存のアラームを表示し、その状態を確認する手順も示します。
Elastic Beanstalk コンソールを使用して、モニタリングしているメトリクスに対するアラームを作成できます。アラームは、 AWS Elastic Beanstalk 環境の変化をモニタリングするのに役立ちます。これにより、問題が発生する前に問題を簡単に特定して軽減できます。たとえば、環境の CPU 使用率が特定のしきい値を超えた場合に通知するアラームを設定し、潜在的な問題が発生する前に気づくことができます。詳細については、「[「Amazon CloudWatch で Elastic Beanstalk を使用する」](AWSHowTo.cloudwatch.md)」を参照してください。
**注記**
Elastic Beanstalk はモニタリングとアラームに CloudWatch を使用します。つまり、CloudWatch のコストは、使用するアラームの AWS アカウントに適用されます。
特定のメトリクスのモニタリングの詳細については、「[ベーシックヘルスレポート](using-features.healthstatus.md)」を参照してください。
**アラームの状態をチェックする**
1. [Elastic Beanstalk コンソール](https://console.aws.amazon.com/elasticbeanstalk)を開き、**リージョン**リストで を選択します AWS リージョン。
1. ナビゲーションペインで、[**環境**] を選択し、リストから環境の名前を選択します。
1. ナビゲーションペインで、**[Alarms]** (アラーム) を選択します。
このページには、既存のアラームのリストが表示されます。アラーム状態にあるアラームには、警告アイコン (![\[Image of the warning icon.\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/warning.png)) のフラグが立ちます。
1. アラームをフィルタリングするには、ドロップダウンメニューを選択してから、[フィルター] を選択します。
1. アラームを編集または削除するには、それぞれ編集アイコン (![\[Image of a cog, which serves as the edit icon.\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/cog.png)) または削除アイコン (![\[Image of an x, which servers as the delete icon.\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/x.png)) を選択します。
**アラームを作成する**
1. [Elastic Beanstalk コンソール](https://console.aws.amazon.com/elasticbeanstalk)を開き、**リージョン**リストで を選択します AWS リージョン。
1. ナビゲーションペインで、[**環境**] を選択し、リストから環境の名前を選択します。
1. ナビゲーションペインで、[**モニタリング**] を選択します。
1. アラームを作成するメトリクスを見つけて、アラームアイコン (![\[Image of a bell, which serves as the alarm icon.\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/bell.png)) を選択します。[**アラームの追加**] ページが表示されます。
1. アラームについての詳細を入力します:
+ [**Name**]: このアラームの名前。
+ [**Description**] (オプション): このアラームの内容の短い説明。
+ [**Period**]: 読み取り間隔。
+ [**Threshold**]: アラームがトリガーされるためのメトリクスの動作と超えるべき値を指定します。
+ [**Change state after**]: アラームの状態変更をトリガーするしきい値を超えた後の時間。
+ [**通知**]: アラームの状態が変更された時に通知される Amazon SNS トピック。
+ [**Notify when state changes to**]:
+ [**OK**]: メトリクスの値が、定義されたしきい値の範囲内にあります。
+ [**Alarm**]: 定義したしきい値を超えたメトリクス。
+ [**Insufficient data**]: アラームが開始されたか、メトリクスが利用可能でないか、またはメトリクスがアラームの状態を決定するためのデータが不足しています。
1. **[Add]** (追加) を選択します。環境の更新中は環境ステータスがグレーになります。作成したアラームを表示するには、ナビゲーションペインで [**Alarms (アラーム)**] を選択します。
# Elastic Beanstalk 環境の変更履歴の表示
このトピックでは、Elastic Beanstalk 環境に対して行われた設定変更の履歴を Elastic Beanstalk コンソールを使用して表示する方法について説明します。
Elastic Beanstalk は、[AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) に記録されたイベントから変更履歴を抽出し、それらをナビゲーションとフィルタリングが容易な形で一覧表示します。
[変更履歴] パネルには、環境に対し加えられた変更に関する、次のような情報が表示されます。
+ 変更が行われた日付と時刻
+ 変更を担当した IAM ユーザー
+ 変更に使用されたソースツール (Elastic Beanstalk コマンドラインインターフェイス (EB CLI) またはコンソール)
+ 設定パラメータと、それに対し設定された新しい値
データベースユーザーの名前など、変更が行われたことにより影響を受ける機密データは、変更の内容に含まれていてもパネルには表示されません。
**変更履歴を表示するには**
1. [Elastic Beanstalk コンソール](https://console.aws.amazon.com/elasticbeanstalk)を開き、**リージョン**リストで を選択します AWS リージョン。
1. ナビゲーションペインで [**変更履歴**] をクリックします。
[変更履歴] ページには、Elastic Beanstalk 環境に対して行われた設定変更のリストが表示されます。
このページの情報の操作に関する以下の点に注意してください。
+ [**<**] (前へ) または [**>**] ( 次へ) をクリックするか、特定のページ番号を選択して、リスト内のページを切り替えて表示することができます。
+ [**設定変更**] 列で矢印アイコンをクリックすると、[**行われた変更**] 見出しの下の変更内容のリストを、展開したり折りたたんだりできます。
+ 検索バーを使用すると、変更履歴リストから結果をフィルタリングできます。任意の文字列を入力して、一覧表示される変更の内容を絞り込むことが可能です。
表示結果のフィルタリングについては、次の点に注意してください。
+ 検索のフィルタリングでは、大文字と小文字が区別されません。
+ [**設定変更**] 列の情報に基づいて、表示される変更内容をフィルタリングできます。これは、[**行われた変更**] 内で折りたたまれているために表示されていない場合でも適用されます。
+ フィルタできるのは、そこに表示されている結果のみです。ただし、さらに多くの結果を表示するために別のページに移動した場合でも、フィルターは同じ状態に維持されます。フィルタリングされた結果は、移動先のページの結果セットにも追加されます。
以下の例は、以前の画面に表示されたデータをフィルタする方法を示しています。
+ 検索ボックスに **GettingStartedApp-env** と入力すると、*GettingStartedApp-env* という名前の環境に加えられた変更のみを表示するように結果が絞り込まれます。
+ 検索ボックスに **example3** と入力すると、ユーザー名に *example3* という文字列を含む IAM ユーザーによって行われた変更のみを表示するように結果が絞り込まれます。
+ 検索ボックスに **2020-10** と入力した場合は、2020 年 10 月に行われた変更のみを表示するように結果が絞り込まれます。結果をさらに絞り込み、2020 年 10 月 16 日に行われた変更のみを表示するには、検索ボックスの値を **2020-10-16** に変更します。
+ また、*aws:elasticbeanstalk:environment:proxy:staticfiles* という名前のネームスペースに加えられた変更のみが表示されるように結果を絞り込むには、検索ボックスに **proxy:staticfiles** と入力します。フィルタリングされた結果が、行として表示されます。これは、[**行われた変更**] に折りたたまれている結果に対しても当てはまります。
# Elastic Beanstalk 環境のイベントストリームの表示
このトピックでは、アプリケーションに関連付けられたイベントや通知にアクセスする方法について説明します。
## Elastic Beanstalk コンソールでのイベントの表示
**Elastic Beanstalk コンソールでイベントを表示するには**
1. [Elastic Beanstalk コンソール](https://console.aws.amazon.com/elasticbeanstalk)を開き、**リージョン**リストで を選択します AWS リージョン。
1. ナビゲーションペインで、[**環境**] を選択し、リストから環境の名前を選択します。
1. ナビゲーションペインの [**Events**] を選択してください。
イベントページに、環境で記録されたすべてのイベントが一覧表示されます。[**<**] (前)、[**>**] (次)、または [ページ番号] を選択して、一覧からページを移動できます。[**重要度**] ドロップダウンリストを使用すると、イベントのタイプをフィルターできます。
## コマンドラインツールを使用してイベントを表示する
[EB CLI](eb-cli3.md) と [AWS CLI](https://aws.amazon.com/cli/) はどちらも、イベントを取得するためのコマンドを提供しています。EB CLI を使用して環境を管理する場合に、イベントの一覧を出力するには、[**eb events**](eb3-events.md) を使用します。このコマンドには、**Ctrl\$1C** を押して出力を停止するまで新しいイベントの表示を続行する `--follow` オプションもあります。
を使用してイベントをプルするには AWS CLI、 `describe-events` コマンドを使用して、名前または ID で環境を指定します。
```
$ aws elasticbeanstalk describe-events --environment-id e-gbjzqccra3
{
"Events": [
{
"ApplicationName": "elastic-beanstalk-example",
"EnvironmentName": "elasticBeanstalkExa-env",
"Severity": "INFO",
"RequestId": "a4c7bfd6-2043-11e5-91e2-9114455c358a",
"Message": "Environment update completed successfully.",
"EventDate": "2015-07-01T22:52:12.639Z"
},
...
```
コマンドラインツールの詳細については、「[Elastic Beanstalk コマンドラインインターフェイス (EB CLI) をセットアップして Elastic Beanstalk を管理する](eb-cli3.md)」を参照してください。
# サーバーインスタンスの一覧表示と接続
このトピックでは、Elastic Beanstalk アプリケーション環境を実行している Amazon EC2 インスタンスのリストを表示する方法と、それらに接続する方法について説明します。
Elastic Beanstalk コンソールを使用して、 AWS Elastic Beanstalk アプリケーション環境を実行している Amazon EC2 インスタンスのリストを表示できます。インスタンスは、SSH クライアントを使用して接続できます。Windows の Remote Desktop を使用してインスタンスに接続することもできます。
**重要**
Elastic Beanstalk によってプロビジョニングされた Amazon EC2 インスタンスにアクセスする前に、Amazon EC2 キーペアを作成し、Elastic Beanstalk によってプロビジョニングされた Amazon EC2インスタンスを、Amazon EC2 キーペアを使用するように設定する必要があります。Amazon EC2 キーペアをセットアップするには、[AWS マネジメントコンソール](https://console.aws.amazon.com/)を使用します。Amazon EC2 のキーペアを作成する方法については、*Amazon EC2 入門ガイド*を参照してください。Amazon EC2 インスタンスを設定して Amazon EC2 キーペアを使用する方法の詳細については、[EC2 キーペア](using-features.managing.security.md#using-features.managing.security.keypair) を参照してください。
デフォルトでは、Elastic Beanstalk は、レガシー Windows コンテナ以外の Windows コンテナ内にある EC2 インスタンスへのリモート接続を有効にしません。(Elastic Beanstalk は、RDP 接続用にポート 3389 を使用するようにレガシー Windows コンテナ内の EC2 インスタンスを設定します)。インスタンスへのインバウンドトラフィックを許可するセキュリティグループにルールを追加することにより、Windows を実行している EC2 インスタンスへのリモート接続の有効にすることができます。リモート接続を終了するときにこのルールを削除することを強くお勧めします。次回リモートでログインする必要があるときには、ルールを再度追加できます。詳細については、『[Microsoft Windows 用 Amazon Elastic Compute Cloud ユーザーガイド](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/authorizing-access-to-an-instance.html#authorizing-access-to-an-instance-rdp)』の「[Windows インスタンスに対するインバウンド RDP トラフィックのルールの追加](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2Win_GetStarted.html#connecting_to_windows_instance)」および「*Windows インスタンスへの接続*」を参照してください。
**環境の Amazon EC2 インスタンスを表示して接続するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. コンソールのナビゲーションペインで、[**Load Balancers**] を選択します。
1. Elastic Beanstalk によって作成されたロードバランサーの名前には [**awseb**] が含まれます。お使いの環境のロードバランサーを探し、クリックしてください。
1. コンソールの下部のペインで、[**Instances**] タブを選択します。
Elastic Beanstalk 環境のロードバランサーが使用するインスタンスのリストが表示されます。接続したいインスタンス ID をメモしてください。
1. Amazon EC2 コンソールのナビゲーションペインで [**Instances (インスタンス)**] を選択し、リストで目的のインスタンス ID を見つけます。
1. お使いの環境のロードバランサーで実行されている Amazon EC2 インスタンスのインスタンス ID を右クリックし、[**Connect (接続)**] を選択します。
1. [**Description**] タブにある、インスタンスのパブリック DNS アドレスをメモしてください。
1. 選択した SSH クライアントを使用して Linux を実行しているインスタンスに接続するには、[**ssh -i .ec2/mykeypair.pem ec2-user@**] と入力します。
Amazon EC2 Linux インスタンスへの接続の詳細については、「Amazon EC2 ユーザーガイド」の「[Amazon EC2 Linux インスタンスの開始方法](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html)」を参照してください。
Elastic Beanstalk 環境で [Windows Server の .NET プラットフォーム](create_deploy_NET.container.console.md)を使用している場合は、「Amazon EC2 ユーザーガイド」の「[Amazon EC2 Windows インスタンスの開始方法](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2_GetStarted.html)」を参照してください。
# Elastic Beanstalk 環境の Amazon EC2 インスタンスからのログの表示
このトピックでは、Elastic Beanstalk が提供するインスタンスログのタイプについて説明します。また、これらの取得と管理に関する詳細な手順についても説明します。
Elastic Beanstalk 環境の Amazon EC2 インスタンスでは、アプリケーションまたは設定ファイルに関する問題を解決する際に確認するためのログが生成されます。ウェブサーバー、アプリケーションサーバー、Elastic Beanstalk プラットフォームスクリプトによって作成されたログ CloudFormation は、個々のインスタンスにローカルに保存されます。それらは、[環境管理コンソール](environments-console.md)または EB CLI を使用して簡単に検索できます。また、Amazon CloudWatch Logs にリアルタイムでログがストリーミングされるように環境を設定することもできます。
テールログは、最も一般的に使用されるログファイル (Elastic Beanstalk 運用ログ、ウェブサーバーやアプリケーションサーバーのログ) の最後の 100 行です。環境マネジメントコンソールまたは **eb logs** を使用してテールログをリクエストすると、環境のインスタンスにより、最新のログエントリを単一のテキストファイルに連結したものが Amazon S3 にアップロードされます。
バンドルログは、yum および cron のログおよび CloudFormationの複数のログを含むさまざまなログファイルのフルログです。バンドルログをリクエストすると、環境内のインスタンスでは完全ログファイルが ZIP アーカイブとしてパッケージ化され、Amazon S3 にアップロードされます。
ローテーションされたログを Amazon S3 にアップロードするには、環境内のインスタンスの [インスタンスプロファイル](concepts-roles-instance.md)に、Elastic Beanstalk Amazon S3 バケットに書き込むためのアクセス許可が必要になります。これらのアクセス許可は、デフォルトのインスタンスプロファイルに含まれています。このプロファイルは、Elastic Beanstalk コンソールで初めて環境を起動する際に、作成するよう Elastic Beanstalk から求められるものです。
**インスタンスログを取得するには**
1. [Elastic Beanstalk コンソール](https://console.aws.amazon.com/elasticbeanstalk)を開き、**リージョン**リストで を選択します AWS リージョン。
1. ナビゲーションペインで、[**環境**] を選択し、リストから環境の名前を選択します。
1. ナビゲーションペインで [**ログ**] を選択します。
1. [**ログのリクエスト**] を選択し、取得するログの種類を選択します。ログ末尾を取得するには、[**Last 100 Lines**] を選択します。バンドルログを取得するには、[**Full Logs**] を選択します。
1. Elastic Beanstalk でログの取得が完了したら、[**ダウンロード**] を選択します。
Elastic Beanstalk は、テールログとバンドルログを Amazon S3 バケットに保存し、ログにアクセスするために使用できる署名済みの Amazon S3 URL を生成します。Elastic Beanstalk は、15 分の持続時間が経過すると、Amazon S3 からファイルを削除します。
**警告**
このファイルには、署名済み Amazon S3 URL を所有していれば誰でも、削除前にアクセスできます。URL を使用できるように指定するのは、信頼されたパーティに対してのみにしてください。
**注記**
ユーザーポリシーには、`s3:DeleteObject` アクセス許可が必要です。Elastic Beanstalk は、ユーザーのアクセス許可を使用して Amazon S3 からログを削除します。
ログを保持するためには、ログのローテーション後、自動的に Amazon S3 に発行されるように環境を設定できます。Amazon S3 へのログのローテーションを有効にするには、「[インスタンスログ表示の設定](environments-cfg-logging.md#environments-cfg-logging-console)」の手順に従ってください。環境のインスタンスは 1 時間に一度ローテーションされるログをアップロードしようと試みます。
アプリケーションが、環境のプラットフォームのデフォルトの設定の一部ではない場所にあるログを生成する場合、設定ファイル (`[.ebextensions](ebextensions.md)`) を使用してデフォルトの設定を拡張できます。アプリケーションのログファイルをログ末尾、バンドルログ、またはログローテーションに追加できます。
ログのリアルタイムストリーミングや長期保存を行う場合は、[Amazon CloudWatch Logs にログがストリーミング](#health-logs-cloudwatchlogs)されるよう環境を設定します。
環境ログ、イベント、インスタンスの状態を AI で分析して、ヘルス問題の根本原因と解決策を特定するには、「」を参照してください[AI を活用した環境分析](health-ai-analysis.md)。
**Topics**
+ [Amazon EC2 インスタンス上のログの場所](#health-logs-instancelocation)
+ [Amazon S3 のログの場所](#health-logs-s3location)
+ [Linux でのログのローテーション設定](#health-logs-logrotate)
+ [デフォルトのログタスク設定の拡張](#health-logs-extend)
+ [Amazon CloudWatch Logs へのログファイルのストリーミング](#health-logs-cloudwatchlogs)
## Amazon EC2 インスタンス上のログの場所
ログは、環境内の Amazon EC2 インスタンスで標準の場所に保存されます。Elastic Beanstalk では、以下のログが生成されます。
**Amazon Linux 2**
+ `/var/log/eb-engine.log`
**Amazon Linux AMI (AL1)**
**注記**
[2022 年 7 月 18 日](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2022-07-18-linux-al1-retire.html)に、Elastic Beanstalk では Amazon Linux AMI (AL1) に基づくプラットフォームブランチのステータスがすべて**廃止**に設定されました。現在および完全にサポートされている Amazon Linux 2023 プラットフォームブランチへの移行の詳細については、「[Elastic Beanstalk Linux アプリケーションを Amazon Linux 2023 または Amazon Linux 2 に移行する](using-features.migration-al.md)」を参照してください。
+ `/var/log/eb-activity.log`
+ `/var/log/eb-commandprocessor.log`
**Windows Server**
+ `C:\Program Files\Amazon\ElasticBeanstalk\logs\`
+ `C:\cfn\log\cfn-init.log`
これらのログには、設定ファイルに関するメッセージなど、デプロイメントアクティビティに関するメッセージが含まれます ([`.ebextensions`](ebextensions.md))。
各アプリケーションとウェブサーバーは、固有フォルダにログを保存します。
+ **Apache** – `/var/log/httpd/`
+ **IIS** – `C:\inetpub\wwwroot\`
+ **Node.js** – `/var/log/nodejs/`
+ **nginx** – `/var/log/nginx/`
+ **Passenger** – `/var/app/support/logs/`
+ **Puma** – `/var/log/puma/`
+ **Python** – `/opt/python/log/`
+ **Tomcat** – `/var/log/tomcat/`
## Amazon S3 のログの場所
環境のテールログまたはバンドルログをリクエストした場合や、ローテーションされたログをインスタンスがアップロードした場合、ログは Amazon S3 の Elastic Beanstalk バケットに格納されます。Elastic Beanstalk は、環境を作成する AWS リージョン`elasticbeanstalk-region-account-id`ごとに という名前のバケットを作成します。このバケット内では、ログはパス `resources/environments/logs/logtype/environment-id/instance-id` 内に保存されます。
たとえば、アカウント の`e-mpcwnwheky` AWS リージョン `i-0a1fd158`の Elastic Beanstalk 環境`us-west-2`のインスタンス からのログは`123456789012`、次の場所に保存されます。
+ **テールログ** –
`s3://elasticbeanstalk-us-west-2-123456789012/resources/environments/logs/tail/e-mpcwnwheky/i-0a1fd158`
+ **バンドルログ** –
`s3://elasticbeanstalk-us-west-2-123456789012/resources/environments/logs/bundle/e-mpcwnwheky/i-0a1fd158`
+ **ローテーションされたログ** –
`s3://elasticbeanstalk-us-west-2-123456789012/resources/environments/logs/publish/e-mpcwnwheky/i-0a1fd158`
**注記**
環境 ID は、環境管理コンソールに表示されます。
Elastic Beanstalk は、テールログとバンドルログを作成から 15 分後に Amazon S3 から自動的に削除します。ローテーションされたログは、削除するか Amazon Glacier に移動するまで保持されます。
## Linux でのログのローテーション設定
Linux プラットフォームでは、Elastic Beanstalk は `logrotate` を使用して定期的にログのローテーションを行います。設定されている場合､ログがローカルでローテーションされると、そのログはローテーションタスクにより Amazon S3 にアップロードされます。ローカルにローテーションされたログは、ログの末尾またはバンドルログにはデフォルトで表示されません。
`logrotate` 用の Elastic Beanstalk 設定ファイルは `/etc/logrotate.elasticbeanstalk.hourly/` にあります。これらのローテーション設定はプラットフォームに固有で、今後のプラットフォームのバージョンで変更される場合があります。使用できる設定の設定と例の詳細については、`man logrotate` を実行してください。
設定ファイルは、`/etc/cron.hourly/` の cron ジョブで呼び出されます。`cron` の詳細については、「`man cron`」を実行してください。
## デフォルトのログタスク設定の拡張
Elastic Beanstalk は Amazon EC2 インスタンス上の `/opt/elasticbeanstalk/tasks` (Linux) または `C:\Program Files\Amazon\ElasticBeanstalk\config` (Windows Server) のサブフォルダにあるファイルを使用して、テールログ、バンドルログ、およびログローテーションを設定します。
Amazon Linux で
+ **テールログ** –
`/opt/elasticbeanstalk/tasks/taillogs.d/`
+ **バンドルログ** –
`/opt/elasticbeanstalk/tasks/bundlelogs.d/`
+ **ローテーションされたログ** –
`/opt/elasticbeanstalk/tasks/publishlogs.d/`
**Windows Server の場合:**
+ **テールログ** –
`c:\Program Files\Amazon\ElasticBeanstalk\config\taillogs.d\`
+ **バンドルログ** –
`c:\Program Files\Amazon\ElasticBeanstalk\config\bundlelogs.d\`
+ **ローテーションされたログ** –
`c:\Program Files\Amazon\ElasticBeanstalk\config\publogs.d\`
たとえば、Linux のファイル `eb-activity.conf` が 2 つのログファイルを末尾ログのタスクに追加します。
**`/opt/elasticbeanstalk/tasks/taillogs.d/eb-activity.conf `**
```
/var/log/eb-commandprocessor.log
/var/log/eb-activity.log
```
環境設定ファイル (`[.ebextensions](ebextensions.md)`) を使用して、独自の `.conf` ファイルをこれらのフォルダに追加できます。`.conf` ファイルでは、お客様のアプリケーションに固有のログファイルが表示されます。これは Elastic Beanstalk によってログファイルタスクに追加されます。
`files` セクションを使用して、変更するタスクに設定ファイルを追加します。たとえば、次の設定テキストは､ログ設定ファイルを環境の各インスタンスに追加します。このログ設定ファイル `cloud-init.conf` は､ログ末尾に `/var/log/cloud-init.log` を追加します。
```
files:
"/opt/elasticbeanstalk/tasks/taillogs.d/cloud-init.conf" :
mode: "000755"
owner: root
group: root
content: |
/var/log/cloud-init.log
```
このテキストを `.config` ファイル名拡張子をもつファイルに追加して `.ebextensions` という名前のフォルダ内のソースバンドルに追加します。
```
~/workspace/my-app
|-- .ebextensions
| `-- tail-logs.config
|-- index.php
`-- styles.css
```
Linux プラットフォームでは、ログのタスク設定でワイルドカード文字を使用することもできます。この設定ファイルは `.log` ファイル名拡張子をもつすべてのファイルをアプリケーションのルートにある `log` フォルダからバンドルログに追加します。
```
files:
"/opt/elasticbeanstalk/tasks/bundlelogs.d/applogs.conf" :
mode: "000755"
owner: root
group: root
content: |
/var/app/current/log/*.log
```
ログタスク設定では、Windows プラットフォームでワイルドカード文字はサポートされません。
**注記**
ログのカスタマイズ手順に慣れるために、[EB CLI](eb-cli3.md) を使用してサンプルアプリケーションをデプロイできます。このために、EB CLI によって、サンプル設定の `.ebextentions` サブディレクトリを含むローカルアプリケーションディレクトリが作成されます。サンプルアプリケーションのログファイルを使用して、このトピックで説明されているログ取得機能をさまざまに試すこともできます。
設定ファイルの使用方法の詳細については、「[設定ファイル (`.ebextensions`) による高度な環境のカスタマイズ](ebextensions.md)」を参照してください。
ログ末尾やバンドルログを拡張するのと同様に、設定ファイルを使用してログのローテーションを拡張できます。Elastic Beanstalk で、独自のログのローテーションと Amazon S3 へのアップロードが行われる際には、追加のログもローテーションおよびアップロードされます。ログのローテーション拡張は、プラットフォームのオペレーティングシステムによって動作が異なります。以下のセクションでは、2 つのケースについて説明します。
### Linux でのログのローテーション拡張
「[Linux でのログのローテーション設定](#health-logs-logrotate)」で説明したように、Linux プラットフォームでは Elastic Beanstalk が `logrotate` を使用してログをローテーションします。ログのローテーションについてアプリケーションのログファイルを設定すると、アプリケーションはログファイルのコピーを作成する必要はありません。Elastic Beanstalk は `logrotate` を設定し、ローテーションごとにアプリケーションのログファイルのコピーを作成します。したがって、アプリケーションはログファイルにアクティブに書き込んでいないときは、ログファイルをロック解除した状態を維持する必要があります。
### Windows サーバーでのログのローテーション拡張
Windows Server では、アプリケーションのログファイルでログのローテーションを設定する場合、アプリケーションはログファイルを定期的にローテーションする必要があります。Elastic Beanstalk は、設定されたパターンで始まる名前を持つファイルを探し、Amazon S3 へのアップロードのためにそれらのファイルを選択します。さらに、ファイル名のピリオドは無視され、Elastic Beanstalk は、名前のピリオドまでがログファイルのベース名であると見なします。
Elastic Beanstalk は、最新のものを除くすべてのバージョンのベースログファイルをアップロードします。これは、最新のファイルがアクティブなアプリケーションログファイルであり、ロックされる可能性があると見なされるためです。したがって、アプリケーションはローテーション間でアクティブなログファイルのロックを維持できます。
たとえば、アプリケーションが `my_log.log` というログファイルに書き込み、この名前を `.conf` ファイルで指定するとします。アプリケーションは定期的にファイルをローテーションします。アプリケーションは Elastic Beanstalk のローテーションサイクル中に、ログファイルのフォルダーで `my_log.log`、`my_log.0800.log`、`my_log.0830.log` の各ファイルを検索します。Elastic Beanstalk は、すべてがベース名 `my_log` のバージョンであると見なします。ファイル `my_log.log` の変更時刻が最新であるため、Elastic Beanstalk は他の 2 つのファイル `my_log.0800.log` および `my_log.0830.log` のみをアップロードします。
## Amazon CloudWatch Logs へのログファイルのストリーミング
Amazon CloudWatch Logs にログがストリーミングされるように環境を設定するには、Elastic Beanstalk コンソールまたは[設定オプション](command-options.md)を使用します。CloudWatch Logs では、環境の各インスタンスがロググループにログをストリーミングします。ロググループは、環境の終了後も数週間または数年間保持するよう設定できます。
ストリーミングされるログのセットは環境によって異なりますが、アプリケーションの前面で実行される nginx または Apache プロキシサーバーからの `eb-engine.log` とアクセスログが常に含まれます。
Elastic Beanstalk コンソールでは、[環境の作成時](environments-create-wizard.md#environments-create-wizard-software)または[既存の環境](environments-cfg-logging.md#environments-cfg-logging-console)のいずれかに､ログのストリーミングを設定できます。コンソールから次のオプションを設定できます。CloudWatch Logs へのログストリーミングの有効化/無効化、保持日数の設定、Lifecyle オプションからの選択。次の例では、環境が終了した場合でもログは最大 7 日間保存されます。
![\[Elastic Beanstalk コンソールの CloudWatch Logs 設定の画面イメージ。\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/log-streaming-screen.png)
次の[設定ファイル](ebextensions.md)では、環境が終了した場合でも 180 日間はログストリーミングが可能になります。
**Example .ebextensions/log-streaming.config**
```
option_settings:
aws:elasticbeanstalk:cloudwatch:logs:
StreamLogs: true
DeleteOnTerminate: false
RetentionInDays: 180
```
# Elastic Beanstalk 環境のデプロイログの表示
Elastic Beanstalk は、環境へのデプロイごとにデプロイログを生成します。デプロイログには、依存関係のインストール、ビルド出力、アプリケーションの起動、発生したエラーなど、デプロイ中に何が起こったかの統合された時系列ビューが表示されます。デプロイログを使用すると、SSH をインスタンスにしたり、複数のログファイルを関連付けたりすることなく、失敗したデプロイをすばやく診断できます。
デプロイログは各インスタンスにローカルに書き込まれます。コンソール、CLI、API、またはマネージド更新を介してトリガーされたデプロイの場合、1 つのインスタンスはデプロイ中にログを Amazon S3 に継続的にアップロードします。Elastic Beanstalk コンソールは Amazon S3 からログを読み取るため、インスタンスに接続せずに進行状況をモニタリングできます。
デプロイログは簡潔に設計されています。成功すると、ログには概要メッセージ (実行および完了したコマンドなど) のみが表示されます。失敗した場合、ログには失敗したステップから最大 50 行の出力が含まれるため、詳細な出力をふるい分けることなくエラーを確認できます。
**注記**
デプロイログは、2026 年 3 月 11 日以降にリリースされた [Amazon Linux](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2026-03-11-al2.html) 2 および Amazon Linux 2023 プラットフォームバージョンで利用できます。 [https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2026-03-11-al2023.html](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2026-03-11-al2023.html)Windows プラットフォームは現在サポートされていません。
## サポートされているオペレーション
デプロイログは、次のオペレーションに対して生成されます。
+ **アプリケーションのデプロイ —** 環境に新しいアプリケーションバージョンをデプロイします。
+ **設定の更新** – インスタンスの更新を必要とする環境設定の変更。
+ **環境の作成** – 新しい環境を作成するときの最初のデプロイ。
+ **アプリケーションサーバーの再起動** – インスタンスでアプリケーションサーバーを再起動します。
ログのリクエスト、CNAMEs のスワップ、タグの更新など、インスタンスのアプリケーションまたは設定状態を変更しないオペレーションは、デプロイログを生成しません。
## デプロイログの内容
デプロイログは、デプロイ中に次の情報をキャプチャします。
+ **デプロイライフサイクル** – や など、各デプロイフェーズの開始`Starting Application deployment`メッセージと完了メッセージ`Completed Application deployment`。
+ **.ebextensions output** – 成功すると、実行されたコマンドの名前。失敗した場合、問題の診断に役立つ最後の 50 行の`cfn-init`出力。
+ **プラットフォームフック出力** – 成功すると、実行されたフックスクリプトの名前。失敗した場合、フック出力の最後の 50 行。
+ **依存関係のインストール** — **npm install**、**pip install**、、 などのパッケージマネージャーからの出力**composer install****bundle 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 秒後にキャプチャされます。初期起動メッセージのみが含まれます。アプリケーションが出力の生成に時間がかかる場合、デプロイログには表示されません。完全なアプリケーションログを表示するには、バンドルログをリクエストするか、インスタンスに直接接続します。詳細については、「[インスタンスログの表示](using-features.logging.md)」を参照してください。
デプロイステップが失敗すると、ログはそれを でマーク`[ERROR]`し、失敗したステップから最大 50 行の出力を含めます。デプロイログに十分な詳細が含まれていない場合は、 ログ****タブから完全なインスタンスログ (`eb-engine.log`、`eb-hooks.log`、およびアプリケーションログを含む) を取得できます。詳細については、「[Elastic Beanstalk 環境の Amazon EC2 インスタンスからのログの表示](using-features.logging.md)」を参照してください。
## コンソールでのデプロイログの表示
Elastic Beanstalk コンソールには、**デプロイ**履歴とログを表示できるデプロイタブが環境ダッシュボードに表示されます。
### デプロイ履歴の表示
**デプロイ履歴を表示するには**
1. [Elastic Beanstalk コンソール](https://console.aws.amazon.com/elasticbeanstalk)を開き、**リージョン**リストで を選択します AWS リージョン。
1. ナビゲーションペインで、[**環境**] を選択し、リストから環境の名前を選択します。
1. 環境ダッシュボードで、**デプロイタブ**を選択します。
デプロイタブには、環境のデプロイのテーブルが表示されます。各行には以下の情報が含まれます。
+ **リクエスト ID** – デプロイの一意の識別子。
+ **ステータス** – *成功*、*失敗*、または*進行中*。
+ **タイプ** – *環境の作成*、*アプリケーションのデプロイ*、*設定の更新*、*マネージドプラットフォームの更新*、*アプリケーションサーバーの再起動*、*環境の再構築*、*環境の復元*、*環境ドメインのスワップ*、*環境の終了*などのデプロイタイプ。
+ **開始時刻** – デプロイが開始された時刻。
+ **期間** – デプロイの完了にかかった時間。
デプロイが進行中の場合、タブは自動的に更新をポーリングします。更新ボタンを選択して、リストを手動で再ロードすることもできます。
### デプロイの詳細とログの表示
**デプロイの詳細を表示するには**
1. **デプロイタブ**で、検査するデプロイの**リクエスト ID** リンクを選択します。
1. デプロイの詳細ページには、リクエスト ID、ステータス、デプロイタイプ、開始時刻、期間、デプロイポリシーを含む概要セクションが表示されます。デプロイポリシー (*一度にすべて*、*ローリング*、*追加のバッチによるローリング*、*イミュータブ*ル、*トラフィック分割*など) は、デプロイイベントから判断できる場合に表示されます。
1. 概要の下で、次のいずれかのタブを選択します。
+ **イベント** – このデプロイに関連するイベントのタイムライン。選択したデプロイのイベントのみを表示するようにフィルタリングされます。
+ **デプロイログ** – インスタンスからの統合デプロイログ。ログレベルによる検索、フィルタリング、ログファイルのダウンロードを行うことができます。
進行中のデプロイの場合、ログタブは自動的に更新され、新しいログエントリが書き込まれると表示されます。デプロイが完了すると、コンソールは最終的なログ状態を取得し、完全な出力を確認します。
**重要**
コンソールでデプロイログを表示するには、環境の Amazon S3 ストレージバケット () に対する`s3:GetObject`アクセス許可が必要です`elasticbeanstalk-region-account-id`。IAM ポリシーにこのアクセス許可が含まれていない場合、デプロイ履歴とイベントは引き続き使用できますが、ログタブにエラーが表示されます。
## インスタンスのデプロイログファイル
デプロイログは、各インスタンスの `/var/log/deployments/` ディレクトリに書き込まれます。ログファイル名は、デプロイのトリガー方法によって異なります。
+ **ワークフロー制御のデプロイ** (コンソール、CLI、または API を介してトリガー) – `eb-deployment-request-id.log`。*request-id* は一意のデプロイリクエスト ID です。
+ **自己起動デプロイ** (インスタンス起動または再起動アプリケーションサーバー) – `eb-deployment-unix-timestamp.log`。
Elastic Beanstalk はこれらのファイルを自動的にローテーションし、各インスタンスの最新のデプロイログを 50 個保持します。
ワークフロー制御のデプロイの場合、ログは次のパスで Amazon S3 にアップロードされます。
```
s3://elasticbeanstalk-region-account-id/resources/environments/logs/deployments/environment-id/log-filename
```
マルチインスタンス環境では、アップロードを開始する最初のインスタンスがデプロイ全体のロールを要求します。そのインスタンスは、デプロイの期間中、ログを Amazon S3 にアップロードします。すべてのインスタンスは、引き続きデプロイログをローカルに書き込みます。
**重要**
Amazon S3 にデプロイログをアップロードするには、インスタンスプロファイル内の環境の Amazon S3 ストレージバケットに対する`s3:PutObject`アクセス許可が必要であり、VPC 設定では Amazon S3 への接続を許可する必要があります。
デプロイログのアップロードは、ファイルあたり 1 MB に制限されます。デプロイログがこのサイズを超えると、アップロードされたバージョンは、インスタンスで完全なログが使用可能であることを示すメッセージで切り捨てられます。
### S3 ログアップロードの無効化
デプロイログが 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。