View a markdown version of this page

Beanstalk クラスター環境のモニタリング - AWS Elastic Beanstalk
メトリクス、ログ、トレースオブザーバビリティデータをサードパーティーのバックエンドに送信する

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

Beanstalk クラスター環境のモニタリング

Beanstalk クラスター環境は、Beanstalk Standard 環境と同じ Elastic Beanstalk ヘルスモデルと APIs を通じて環境レベルのヘルスをレポートします。Elastic Beanstalk コンソールでそのヘルスカラーとステータスを表示し、 DescribeEnvironmentHealthを呼び出して現在の色、ステータス、およびそれを説明する原因を読み取ることができます。ヘルスの色とステータスは、両方のモードで同じ意味を持ちます。

Beanstalk クラスター環境が Application Load Balancer を使用する場合、Elastic Beanstalk は環境のロードバランサーメトリクスからアプリケーションの状態を決定します。リクエストレート、HTTP 4xx および 5xx レスポンスを返すリクエストの割合、レスポンスレイテンシーです。リクエストを正常に処理する環境は、正常なステータスを報告します。失敗したリクエストの割合が増加すると、ステータスは徐々に深刻になります。Elastic Beanstalk が受信するトラフィックが少なすぎる環境では、アイドル環境で予想されるヘルスを判断するにはリクエストレートが不十分であるとレポートされます。ロードバランサータイプを に設定するとNone、このロードバランサーの評価は適用されません。

Beanstalk Standard 環境とは異なり、Beanstalk クラスター環境はインスタンスごとのヘルスをレポートしません。Beanstalk クラスターはインスタンス上のヘルスエージェントを使用しません。また、標準環境に適用されるインスタンスレベルのヘルスレポート設定は適用されません。

コンテナプローブは、アプリケーションレプリカがトラフィックを受信するタイミングと再起動のタイミングを制御します。準備状況プローブはサービスから準備されていないコピーを削除し、ライブネスプローブは異常なままのコピーを再起動し、スタートアッププローブは開始が遅いコピー時間を提供して初期化します。の下にあるプローブ名前空間を使用してプローブを設定しますaws:elasticbeanstalk:eks:environment。「コンテナプローブの名前空間」を参照してください。

メトリクス、ログ、トレース

アプリケーションのオブザーバビリティは、環境の状態とは別のものです。aws:elasticbeanstalk:eks:observability 名前空間の設定オプションを使用して、アプリケーションのメトリクス、ログ、トレースのバックエンドを選択します。デフォルトでは、Elastic Beanstalk はアプリケーションのメトリクスとログを Amazon CloudWatch (CloudWatch) に送信し、トレースにはバックエンドがありません。代わりにAmazon S3にログを送信したり、Amazon Managed Service for Prometheus にメトリクスを送信したり、 にトレースを送信したりできます AWS X-Ray。OpenTelemetry データを受け入れるサードパーティーのバックエンドに 3 つのいずれかを送信することもできます。「」を参照してくださいオブザーバビリティデータをサードパーティーのバックエンドに送信する。使用可能なオプションについては、「」を参照してくださいaws:elasticbeanstalk:eks:observability。

Elastic Beanstalk は、コレクションコンポーネントをプロビジョニングして運用し、ユーザーに代わってインフラストラクチャメトリクスを発行します。必要なメトリクス、ログ、トレースを出力するようにアプリケーションを計測し、選択した送信先へのアクセスを提供および維持する責任があります。

アプリケーションは、バックエンドが何かを受け取るために OpenTelemetry データを出力する必要があります。アプリケーションを変更せずにこれを取得するには、aws:elasticbeanstalk:eks:environment名前空間の languageオプションをアプリケーションのランタイムに設定します。Elastic Beanstalk は、そのランタイムの OpenTelemetry 自動計測をコンテナに追加します。これは、すべてのバックエンド AWS にもサードパーティーにも適用されます。自動計測は、Java、Node.js、Python、および .NET アプリケーションで使用できます。Java アプリケーションの場合、エージェントは Log4j2、Logback、および もブリッジするためjava.util.logging、アプリケーションのログはアプリケーションを変更せずにログバックエンドに到達します。

ログバックエンドとは別に、Elastic Beanstalk は環境オペレーションごとにデプロイログを収集します。これには、ポッドのコンテナログと オペレーションからの Kubernetes イベントが含まれます。これにより、オペレーションが失敗したときに確認する場所になります。詳細については、「デプロイログ」を参照してください。

CloudWatch でのログとメトリクスの検索

デフォルトのバックエンドでは、Elastic Beanstalk は 4 つの CloudWatch ロググループに書き込みます。ロググループ名は固定されており、変更することはできません。

Beanstalk クラスター環境の CloudWatch ロググループ
ロググループ 目次 ログストリーム名 存在する場合

/aws/elasticbeanstalk/application/logs

アプリケーションのコンテナからの出力。

eb-environment-name.pod-name

logs-backend が の場合cloudwatch、デフォルトです。

/aws/elasticbeanstalk/application/metrics

アプリケーションが出力するメトリクス。

environment-name/pod-name

metrics-backend が の場合cloudwatch、デフォルトは で、アプリケーションはメトリクスを出力します。

/aws/elasticbeanstalk/infrastructure/logs

ユーザーに代わって Elastic Beanstalk がクラスターで実行するコンポーネントからの出力。

kubernetes-namespace.pod-name

常に。

/aws/elasticbeanstalk/infrastructure/metrics

Elastic Beanstalk が埋め込みメトリクス形式で公開するメトリクス。

kubernetes-namespace.pod-name

常に。
注記

これらのロググループは共有されます。 AWS アカウントとリージョンのすべての Beanstalk クラスター環境は、すべてのクラスターで同じ 4 つのグループに書き込みます。環境のデータは、ロググループではなくログストリーム名で区切られます。Elastic Beanstalk は、 という名前の Kubernetes 名前空間で各環境を実行し、eb-その後に環境名を付けるため、アプリケーションのログストリームは eb-environment-nameとピリオドで始まります。アプリケーションのメトリクスストリームは、eb-プレフィックスなしで環境名とスラッシュで始まります。

Elastic Beanstalk は保持ポリシーなしでこれらのロググループを作成するため、その内容が期限切れになることはありません。ログストリーム名にはポッド名が含まれているため、すべてのデプロイで新しいストリームが作成され、以前のデプロイからのストリームは残ります。各ロググループに保持ポリシーを設定して、保存する内容を制限します。

Elastic Beanstalk が公開するメトリクスは、3 つの CloudWatch 名前空間に到着します。これら 3 つはすべてカスタム名前空間で、メトリクスごとに支払います。Beanstalk Standard 環境は代わりに、CloudWatch が無料で提供するAWS/ElasticBeanstalk名前空間に発行します。Beanstalk クラスター環境は、各レプリカについて以下のコンテナメトリクスを発行するため、カスタムメトリクスの数は実行するレプリカの数に応じて増加します。現在の料金については、Amazon CloudWatch の料金」を参照してください。

Beanstalk クラスター環境の CloudWatch メトリクス
Namespace メトリクス ディメンション

ElasticBeanstalk/Infrastructure

アプリケーションのコンテナ: container_cpu_usage_seconds_total、container_memory_working_set_bytes、および の場合EnvironmentReplicas、準備完了のレプリカの数。

2 つのコンテナメトリクスは、namespace、pod、containerおよび namespace のみで公開されます。 EnvironmentReplicasは namespaceでのみ公開されます。

ElasticBeanstalk/System

Elastic Beanstalk がアプリケーションではなく、ユーザーに代わってクラスターで実行するコンポーネントについて、同じ 2 つのコンテナメトリクス。

namespace、pod、container、および をnamespace単独で繰り返します。

ElasticBeanstalk/Application

自動計測によって生成されるランタイムメトリクスなど、アプリケーションが出力するメトリクス。

EnvironmentName。 リクエスト期間は、http.method、、http.routeおよび でも発行されますhttp.status_code。

namespace ディメンションは Kubernetes 名前空間であるため、その値のeb-後に環境名が続きます。ElasticBeanstalk/Application 名前空間は代わりに、値自体が環境名であるEnvironmentNameディメンションを使用します。クエリする名前空間に一致する値を使用します。

logs-backend を に設定するとs3、Elastic Beanstalk は、Kubernetes 名前空間、ポッド名、日付から構築されたキーの下で、アプリケーションのログを elasticbeanstalk-logs-account-id-region-an という名前のバケットに書き込みます。 には何も送信されません/aws/elasticbeanstalk/application/logs。Elastic Beanstalk はこれらのアップロードをバッチ処理するため、オブジェクトが表示されるまでに最大 1 分かかることがあります。logs-backend または metrics-backendを に設定するとcustom、そのデータは設定したバックエンドに送信され、これらのロググループには表示されません。「オブザーバビリティデータをサードパーティーのバックエンドに送信する」を参照してください。

オブザーバビリティデータをサードパーティーのバックエンドに送信する

Beanstalk クラスターは OpenTelemetry コレクターを使用してアプリケーションのテレメトリを収集するため、送信 AWS 先ではなく Datadog や Splunk などの OpenTelemetry データを受け入れる任意のバックエンドに送信できます。パイプライン設定と必要な認証情報を指定すると、Elastic Beanstalk はアプリケーションのポッド内のサイドカーコンテナとしてパイプラインを実行します。

サードパーティーのバックエンドの設定には、次の 4 つのものがあります。

  1. にリダイレクトする各シグナルを設定しますcustom。シグナルは独立しているため、トレースが続く間、メトリクスとログをサードパーティーのバックエンドに送信できます AWS X-Ray。aws:elasticbeanstalk:eks:observability 名前空間traces-backendで metrics-backend、logs-backend、および を使用します。

  2. をコレクターのパイプライン設定custom-configに JSON として設定します。設定に値を入力するのではなく、各認証情報を${NAME}プレースホルダーとして参照します。

  3. 認証情報を に保存 AWS Secrets Manager し、シークレットの ARN custom-credentialsに設定します。シークレット値は、キーが設定のプレースホルダー名と一致する JSON オブジェクトである必要があります。

  4. aws:elasticbeanstalk:eks:environment 名前空間で application-roleオプションを設定し、そのロールにシークレットを読み取るアクセス許可を付与します。コレクターは、オブザーバビリティロールではなく実行時にアプリケーションロールを使用し、 application-roleが設定された場合にのみ存在するポッドの ID を介してシークレットに到達します。これがないと、マウントは失敗し、レプリカは起動しません。

次の例では、メトリクスとログを Datadog に送信し、トレースを に保持します AWS X-Ray。まず、設定が参照する認証情報を保持するシークレットを作成します。

$ aws secretsmanager create-secret \
    --name my-app/otel-credentials \
    --secret-string '{"DD_API_KEY":"your-api-key"}'

コレクターが実行時に取得できるように、アプリケーションロールにそれを読み取るアクセス許可を付与します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue",
        "secretsmanager:DescribeSecret"
      ],
      "Resource": "arn:aws:secretsmanager:us-east-1:111122223333:secret:my-app/otel-credentials-AbCdEf"
    }
  ]
}

Elastic Beanstalk はマウントされた認証情報をスケジュールに従って更新し、更新はシークレットの最新バージョンをチェックするため、 secretsmanager:DescribeSecretに加えて を付与しますsecretsmanager:GetSecretValue。環境はGetSecretValue単独で開始されますが、それ以降の更新は失敗します。

次に、オプション設定を ファイルに配置します。コレクター設定にはカンマが含まれており、 の短縮構文では区切り文字として--option-settings扱われるため、代わりに設定を JSON として渡します。custom-config 値にパイプライン設定を JSON 文字列としてoptions.json、以下を として保存します。

[
  {
    "Namespace": "aws:elasticbeanstalk:eks:observability",
    "OptionName": "metrics-backend",
    "Value": "custom"
  },
  {
    "Namespace": "aws:elasticbeanstalk:eks:observability",
    "OptionName": "logs-backend",
    "Value": "custom"
  },
  {
    "Namespace": "aws:elasticbeanstalk:eks:observability",
    "OptionName": "traces-backend",
    "Value": "xray"
  },
  {
    "Namespace": "aws:elasticbeanstalk:eks:observability",
    "OptionName": "custom-config",
    "Value": "{\"receivers\":{\"otlp\":{\"protocols\":{\"grpc\":{\"endpoint\":\"0.0.0.0:4317\"},\"http\":{\"endpoint\":\"0.0.0.0:4318\"}}}},\"processors\":{\"batch\":{}},\"exporters\":{\"datadog\":{\"api\":{\"site\":\"datadoghq.com\",\"key\":\"${DD_API_KEY}\"}}},\"service\":{\"pipelines\":{\"metrics\":{\"receivers\":[\"otlp\"],\"processors\":[\"batch\"],\"exporters\":[\"datadog\"]},\"logs\":{\"receivers\":[\"otlp\"],\"processors\":[\"batch\"],\"exporters\":[\"datadog\"]}}}}"
  },
  {
    "Namespace": "aws:elasticbeanstalk:eks:observability",
    "OptionName": "custom-credentials",
    "Value": "arn:aws:secretsmanager:us-east-1:111122223333:secret:my-app/otel-credentials-AbCdEf"
  }
]

組織で使用する Datadog サイトsiteに設定します。次に、 ファイルを適用します。

$ aws elasticbeanstalk update-environment \
    --environment-name my-cluster-env \
    --option-settings file://options.json

に設定したシグナルごとにパイプラインを定義しますcustom。 AWS 送信先に残したシグナルは、Elastic Beanstalk が動作するコレクションを使用し続け、独自のパイプラインを必要としません。

設定のないコンポーネントは、空のオブジェクトを として受け取ります"batch": {}。receivers ブロックはオプションです。これを省略すると、Elastic Beanstalk はアプリケーションが送信する OTLP レシーバーを追加し、追加を報告する環境イベントを記録します。前の例では、レシーバーを明示的に定義しています。

この設定中に、各パイプラインにdebugエクスポーターを追加し、パイプラインexportersのリストに含めます。次に、コレクターは受信およびエクスポートするテレメトリを記録します。これにより、データがコレクターに到達しているかどうか、およびコレクターがバックエンドに到達できるかどうかが個別にわかります。