- 重要な情報
- はじめに
- 用語集
- ガイド
- エージェント
- インテグレーション
- OpenTelemetry
- 開発者
- API
- CoScreen
- アプリ内
- Service Management
- インフラストラクチャー
- アプリケーションパフォーマンス
- 継続的インテグレーション
- ログ管理
- セキュリティ
- UX モニタリング
- 管理
AWS Elastic Beanstalk は、Apache、Nginx、Passenger、IIS などの使い慣れたサーバーで、Java、.NET、PHP、Node.js、Python、Ruby、Go、および Docker を使用して開発された Web アプリケーションやサービスをデプロイおよびスケーリングするための使いやすいサービスです。
まだ行っていない場合は、まず Amazon Web Services インテグレーション をセットアップします。Elastic Beanstalk メトリクスを受信するには、ご使用の環境で拡張ヘルスレポート機能を有効 にし、拡張ヘルスメトリクスを CloudWatch に公開 するように環境を構成する必要があります。
注: これらの設定により、CloudWatch カスタムメトリクス料金が加算されます。
aws.elasticbeanstalk.application_latency_p_1_0 (gauge) | The average time to complete the fastest 10 percent of requests. Shown as second |
aws.elasticbeanstalk.application_latency_p_5_0 (gauge) | The average time to complete the fastest 50 percent of requests. Shown as second |
aws.elasticbeanstalk.application_latency_p_7_5 (gauge) | The average time to complete the fastest 75 percent of requests. Shown as second |
aws.elasticbeanstalk.application_latency_p_8_5 (gauge) | The average time to complete the fastest 85 percent of requests. Shown as second |
aws.elasticbeanstalk.application_latency_p_9_0 (gauge) | The average time to complete the fastest 90 percent of requests. Shown as second |
aws.elasticbeanstalk.application_latency_p_9_5 (gauge) | The average time to complete the fastest 95 percent of requests. Shown as second |
aws.elasticbeanstalk.application_latency_p_9_9 (gauge) | The average time to complete the fastest 99 percent of requests. Shown as second |
aws.elasticbeanstalk.application_latency_p_9_9_9 (gauge) | The average time to complete the fastest 99.9 percent of requests. Shown as second |
aws.elasticbeanstalk.application_requests_2xx (count) | The number of requests that completed with a 2XX status code. Shown as request |
aws.elasticbeanstalk.application_requests_3xx (count) | The number of requests that completed with a 3XX status code. Shown as request |
aws.elasticbeanstalk.application_requests_4xx (count) | The number of requests that completed with a 4XX status code. Shown as request |
aws.elasticbeanstalk.application_requests_5xx (count) | The number of requests that completed with a 5XX status code. Shown as request |
aws.elasticbeanstalk.application_requests_total (count) | The number of requests completed by the instance or environment. Shown as request |
aws.elasticbeanstalk.cpuidle (gauge) | [Instance] The percentage of time the CPU was in the idle state in the last minute. Shown as percent |
aws.elasticbeanstalk.cpuiowait (gauge) | [Instance] The percentage of time the CPU was in the iowait state in the last minute. Shown as percent |
aws.elasticbeanstalk.cpuirq (gauge) | [Instance] The percentage of time the CPU was in the interrupt request state in the last minute. Shown as percent |
aws.elasticbeanstalk.cpunice (gauge) | [Instance] The percentage of time the CPU was in the nice state in the last minute. Shown as percent |
aws.elasticbeanstalk.cpusoftirq (gauge) | [Instance] The percentage of time the CPU was in the soft interrupt request state in the last minute. Shown as percent |
aws.elasticbeanstalk.cpusystem (gauge) | [Instance] The percentage of time the CPU was in the system state in the last minute. Shown as percent |
aws.elasticbeanstalk.cpuuser (gauge) | [Instance] The percentage of time the CPU was in the user state in the last minute. Shown as percent |
aws.elasticbeanstalk.environment_health (gauge) | [Environment] The health status of the environment. The possible values are 0 (OK) 1 (Info) 5 (Unknown) 10 (No data) 15 (Warning) 20 (Degraded) and 25 (Severe). |
aws.elasticbeanstalk.instance_health (gauge) | [Instance] The health status of the instance. Shown as instance |
aws.elasticbeanstalk.instances_degraded (count) | [Environment] The number of instances with Degraded health status. Shown as instance |
aws.elasticbeanstalk.instances_info (count) | [Environment] The number of instances with Info health status. Shown as instance |
aws.elasticbeanstalk.instances_no_data (count) | [Environment] The number of instances with no health status data. Shown as instance |
aws.elasticbeanstalk.instances_ok (count) | [Environment] The number of instances with OK health status. Shown as instance |
aws.elasticbeanstalk.instances_pending (count) | [Environment] The number of instances with Pending health status. Shown as instance |
aws.elasticbeanstalk.instances_severe (count) | [Environment] The number of instances with Severe health status. Shown as instance |
aws.elasticbeanstalk.instances_unknown (count) | [Environment] The number of instances with Unknown health status. Shown as instance |
aws.elasticbeanstalk.instances_warning (count) | [Environment] The number of instances with Warning health status. Shown as instance |
aws.elasticbeanstalk.load_average_1min (gauge) | [Instance] The average CPU load over the last minute. |
aws.elasticbeanstalk.load_average_5min (gauge) | [Instance] The average CPU load over the last five minutes. |
aws.elasticbeanstalk.root_filesystem_util (gauge) | [Instance] The percentage of disk space in use. Shown as percent |
AWS から取得される各メトリクスには、ホスト名やセキュリティ グループなど、AWS コンソールに表示されるのと同じタグが割り当てられます。
AWS Elastic Beanstalk インテグレーションには、イベントは含まれません。
AWS Elastic Beanstalk インテグレーションには、サービスのチェック機能は含まれません。
次のステップでは、Elastic Beanstalk VM に Datadog Agent をデプロイし、AWS インテグレーションによってクロールされるメトリクスに加えて、ホストメトリクスもレポートするようにします。詳しくは、クラウドインスタンスに Datadog Agent をインストールするメリットは何ですか? をお読みください。
インストール方法を選択して、Elastic Beanstalk 環境に Agent を構成します。
コンテナなしのセットアップの場合、コンフィギュレーションファイル (.ebextensions) による高度な環境のカスタマイズ を使用して、Datadog Agent を Elastic Beanstalk にインストールします。
.ebextensions
という名前のフォルダーを作成します。.ebextensions
フォルダに入れます。/etc/datadog-agent/datadog.yaml
のファイルテンプレート内の api_key
の値を、お使いの Datadog API キー
で変更します。/etc/datadog-agent/datadog.yaml
の site
の値を Datadog リージョンに変更します (例: {{< region-param key=“dd_site” code=“true” >}})。option_settings
の下に DD_AGENT_VERSION
を設定して特定の Agent バージョンを固定します。Agent の設定は /etc/datadog-agent/datadog.yaml
に追加することができます。
例えば、ライブプロセスモニタリングを有効にするには
process_config:
enabled: "true"
アプリケーションがコンテナ化されておらず、Datadog Agent が 99datadog.config
で構成されているとき、アプリケーションがトレーシングライブラリセットアップ
でインスツルメントされている場合は、追加のコンフィギュレーションなしでトレーシングが有効になります。
コンテナなしのセットアップの場合、コンフィギュレーションファイル (.ebextensions) による高度な環境のカスタマイズ を使用して、Datadog Agent を Elastic Beanstalk にインストールします。
.ebextensions
という名前のフォルダーを作成します。.ebextensions
フォルダに移動します。99datadog-windows.config
で、APIKEY
の値を Datadog API キー
に置き換えます。99datadog-windows.config
ファイルは、トレースを生成するために .NET APM トレースライブラリを追加します。APM を有効にしない場合は、packages
セクション、02_setup-APM1
セクション、03_setup-APM2
セクションを削除します。99datadog-windows.config
の 00_setup-env1
セクションで環境変数を設定します。環境変数を設定する必要がない場合は、このセクションを削除してもかまいません。アプリケーションがコンテナ化されておらず、Datadog Agent が 99datadog-windows.config
で構成されているとき、追加のコンフィギュレーションなしでトレーシングが有効になります。トレーシングのインスツルメンテーションについては、Datadog APM のセットアップ
を参照してください。
単一の Docker コンテナのセットアップの場合、コンフィギュレーションファイル (.ebextensions) による高度な環境のカスタマイズ を使用して、Datadog Agent を Elastic Beanstalk にインストールします。
注: このセットアップでは、API キーをソースコードの一部である .ebextensions ディレクトリに配置する必要があります。AWS Secret Manager などのシークレット管理ツールを用いて、API キーを保護してください。
.ebextensions
という名前のフォルダーを作成します。.ebextensions
フォルダに入れます。/etc/datadog-agent/datadog.yaml
のファイルテンプレート内の api_key
の値を、お使いの Datadog API キー
で変更します。/etc/datadog-agent/datadog.yaml
の site
の値を Datadog リージョンに変更します (例: {{< region-param key=“dd_site” code=“true” >}})。option_settings
の下に DD_AGENT_VERSION
を設定して特定の Agent バージョンを固定します。Agent の設定は /etc/datadog-agent/datadog.yaml
に追加することができます。
例えば、ライブプロセスモニタリングを有効にするには
process_config:
enabled: "true"
単一の Docker コンテナのトレースを有効にするには
99datadog.config
ファイルの /etc/datadog-agent/datadog.yaml
セクションを apm_non_local_traffic
で更新し、次のようなフォーマットにします。
apm_config:
enabled: "true"
apm_non_local_traffic: "true"
トレーシングライブラリをセットアップして、トレースが ブリッジネットワークの Gateway IP
に送られるようにします。アプリケーションコンテナ内からのデフォルトが 172.17.0.1
になります (これが Gateway IP かどうかわからない場合は、docker inspect <container id>
を実行して確認します)。
すべての言語で、環境変数 DD_AGENT_HOST
をゲートウェイ IP に設定します。または、以下の言語の場合、次を使用してプログラムでホスト名を設定します。
from ddtrace import tracer
tracer.configure(hostname="172.17.0.1")
const tracer = require('dd-trace');
tracer.init({ hostname: "172.17.0.1" });
require 'ddtrace'
Datadog.configure do |c|
c.tracer hostname: "172.17.0.1")
end
package main
import (
"gopkg.in/DataDog/dd-trace-go.v1/ddtrace/tracer"
)
func main() {
tracer.Start(tracer.WithAgentAddr("172.17.0.1"))
defer tracer.Stop()
// ...
}
複数の Docker コンテナの場合、コンテナ化された Datadog Agent を使用して、Dockerrun.aws.json
という名前のファイルで Docker の使用状況を監視します。
Dockerrun.aws.json
ファイルは Elastic Beanstalk 固有の JSON ファイルで、Docker コンテナセットを Elastic Beanstalk アプリケーションとしてデプロイする方法を記述します。このファイルをマルチコンテナ Docker 環境に使用できます。Dockerrun.aws.json
は、環境内の各コンテナインスタンスにデプロイされるコンテナと、マウントするコンテナのホストインスタンス上に作成されるデータボリュームを記述します。
Dockerrun.aws.json
ファイルは、単独で使用することも、他のソースコードと共にアーカイブに圧縮して使用することもできます。Dockerrun.aws.json
と共にアーカイブされるソースコードは、コンテナインスタンスにデプロイされ、/var/app/current/
ディレクトリでアクセスできます。構成の volumes
セクションを使用して、インスタンスで実行されるコンテナのマウントポイントを提供します。また、埋め込みコンテナ定義の mountPoints
セクションを使用して、コンテナからマウントポイントをマウントします。
以下のコードサンプルは、Datadog Agent を宣言する Dockerrun.aws.json
を示しています。containerDefinitions
セクションを、ご使用の Datadog API キー
、タグ (オプション)、および追加のコンテナ定義で更新してください。必要に応じて、このファイルを上述の追加コンテンツと共に圧縮できます。このファイルの構文の詳細については、マルチコンテナ Docker コンフィギュレーション
を参照してください。
注:
agent:7
を Docker イメージ
の特定のマイナーバージョンに変更することをお勧めします。DD_SITE
を
に設定して、Agent が正しい Datadog の場所にデータを送信するようにします。{
"AWSEBDockerrunVersion": 2,
"volumes": [
{
"name": "docker_sock",
"host": {
"sourcePath": "/var/run/docker.sock"
}
},
{
"name": "proc",
"host": {
"sourcePath": "/proc/"
}
},
{
"name": "cgroup",
"host": {
"sourcePath": "/cgroup/"
}
}
],
"containerDefinitions": [
{
"name": "dd-agent",
"image": "gcr.io/datadoghq/agent:7",
"environment": [
{
"name": "DD_API_KEY",
"value": "<YOUR_DD_API_KEY>"
},
{
"name": "DD_SITE",
"value": "<YOUR_DD_SITE>"
},
{
"name": "DD_TAGS",
"value": "<SIMPLE_TAG>, <KEY:VALUE_TAG>"
}
],
"memory": 256,
"mountPoints": [
{
"sourceVolume": "docker_sock",
"containerPath": "/var/run/docker.sock",
"readOnly": false
},
{
"sourceVolume": "proc",
"containerPath": "/host/proc",
"readOnly": true
},
{
"sourceVolume": "cgroup",
"containerPath": "/host/sys/fs/cgroup",
"readOnly": true
}
]
}
]
}
コンテナ定義が完了したら、それを Elastic Beanstalk に送信します。具体的な手順については、AWS Elastic Beanstalk ドキュメント内の マルチコンテナ Docker 環境 を参照してください。
マルチコンテナ Docker 環境
で DogStatsD を使用してアプリケーションコンテナからカスタムメトリクスを収集するには、Dockerrun.aws.json
に以下の追加を行います。
dd-agent
コンテナの下に環境変数 DD_DOGSTATSD_NON_LOCAL_TRAFFIC
を追加します。
{
"name": "DD_DOGSTATSD_NON_LOCAL_TRAFFIC",
"value": "true"
}
アプリケーションコンテナの下に dd-agent
コンテナへのリンクを追加します。
"links": [ "dd-agent:dd-agent"]
詳細については、DogStatsD と Docker を参照してください。
Dockerrun.aws.json
で、datadog/agent
イメージを使用して Datadog Agent コンテナを追加します。以下を追加します。portMappings
セクションで、containerPort
8126 と hostPort
8126 を追加します。environment
セクションで、DD_APM_ENABLED
と DD_APM_NON_LOCAL_TRAFFIC
を true
に設定します。environment
セクションで、DD_AGENT_HOST
と呼ばれる環境変数を Datadog Agent コンテナの名前に追加します。links
セクションで、Agent コンテナを環境変数として使用されるように設定します。以下の例を参照してください。
"containerDefinitions": [ {
"name": "dd-agent",
"image": "datadog/agent:latest",
"environment": [
{
"name": "DD_API_KEY",
"value": "<api key>"
},
{
"name": "DD_APM_ENABLED",
"value": "true"
},
{
"name": "DD_APM_NON_LOCAL_TRAFFIC",
"value": "true"
},
# その他必要な環境変数
],
"portMappings": [
{
"hostPort": 8126,
"containerPort": 8126
}
],
"memory": 256,
"mountPoints": [
# 必要なマウントポイント
}
]
},
{
"name": "application-container",
"image": "<application image name>",
"environment": [
{
"name": "DD_AGENT_HOST",
"value": "dd-agent",
# その他必要な環境変数
}
],
"links": [
"dd-agent:dd-agent"
],
ご不明な点は、Datadog のサポートチーム までお問合せください。
お役に立つドキュメント、リンクや記事: