Amazon ECS Fargate でCollectorをデプロイする 🔗
Splunk Distribution of the OpenTelemetry Collector を、AWS Fargate を使用して Amazon ECS にデーモンサービスとしてデプロイします。特に断りのない限り、Collector は ECS タスクのサイドカー (追加コンテナ) としてデプロイされます。AWS Fargateはコンテナとして分類され、Fargateメトリクスはコンテナメトリクスとして分類されます。
ECS Fargate環境でCollectorを使用してJavaアプリケーションを監視する方法の例については、シナリオ：ECS FargateのOpenTelemetryでJavaサービスを監視する を参照してください。
要件 🔗
先に進む前に、AWS Fargate（Fargate）の予備知識が必要です。詳細については、公式の AWS Fargate ユーザーガイド を参照してください。
このデプロイメントには、Collectorリリースv0.33.0以上（イメージタグ 0.33.0 以上に対応）が必要です。最新のイメージをダウンロードするには、イメージリポジトリ を参照してください。
ガイド付きセットアップを使用する 🔗
ガイド付きセットアップを使用して、CollectorをECSタスクのサイドカーとしてデプロイします。次のCollector 設定オプションのいずれかを選択します：
デフォルト： Collector イメージの
/etc/otel/collector/fargate_config.yamlファイルが Collector 構成に使用されます。File: Collector 設定に使用するファイルを指定します。ecs_observer 設定 を参照してください。
AWSパラメータストア: Collector構成に使用するAWSパラメータストアのキーまたはARNを指定します。ecs_observer 設定 を参照してください。
セットアップガイドにアクセスする 🔗
Open the Amazon Fargate guided setup .
オプションで、ガイド付きセットアップに自分で移動することもできます：
Splunk Observability Cloud にログインします。
ナビゲーションメニューで、Data Management を選択します。
Go to the Available integrations tab, or select Add Integration in the Deployed integrations tab.
Select the tile for Amazon Fargate.
セットアップガイドの手順に従ってください。
はじめに 🔗
例で示したデフォルトの Collector コンテナ定義をコピーし、以下の変更を加えます：
MY_SPLUNK_ACCESS_TOKENとMY_SPLUNK_REALMを有効な値に置き換えます。画像タグを最新バージョンに更新します。
タスク定義の
containerDefinitionsセクションに設定を追加します。
{
"environment": [
{
"name": "SPLUNK_ACCESS_TOKEN",
"value": "MY_SPLUNK_ACCESS_TOKEN"
},
{
"name": "SPLUNK_REALM",
"value": "MY_SPLUNK_REALM"
},
{
"name": "SPLUNK_CONFIG",
"value": "/etc/otel/collector/fargate_config.yaml"
},
{
"name": "ECS_METADATA_EXCLUDED_IMAGES",
"value": "[\"quay.io/signalfx/splunk-otel-collector*\"]"
}
],
"image": "quay.io/signalfx/splunk-otel-collector:0.33.0",
"essential": true,
"name": "splunk_otel_collector"
}
このコンテナ定義の例では、Collector はデフォルトの構成ファイル /etc/otel/collector/fargate_config.yaml を使用するように構成されています。CollectorイメージのDockerfileは Dockerfile で、デフォルトの設定ファイルの内容は Fargate設定 で確認できます。smartagent/ecs-metadata レシーバーはデフォルトで有効になっています。
要約すると、デフォルトのCollectorコンテナ定義では以下のことが行われます：
Collector イメージを指定します。
環境変数
SPLUNK_ACCESS_TOKENを使ってアクセストークンを設定します。環境変数
SPLUNK_REALMを使ってレルムを設定します。環境変数
SPLUNK_CONFIGを使って、デフォルトの設定ファイルパスを設定します。環境変数
ECS_METADATA_EXCLUDED_IMAGESを使用して、Collector イメージからecs-metadataメトリクスを除外します。
除外したいメトリクスの文字列化された配列を環境変数 METRICS_TO_EXCLUDE に代入します。環境変数 SPLUNK_MEMORY_LIMIT_MIB を使用して、memory_limiter プロセッサーのメモリ制限を設定できます。デフォルトのメモリ制限は512MiBです。
カスタム設定を使用する 🔗
次の例は、カスタム設定を使用するように設定されたCollectorのコンテナ定義の抜粋を示しています。/path/to/custom/config/file は実際のカスタム設定ファイルパスのプレースホルダ値で、0.33.0 は現在の最新のイメージタグです。カスタム設定ファイルは、タスクにアタッチされたボリュームに存在する必要があります。
{
"environment": [
{
"name": "SPLUNK_CONFIG",
"value": "/path/to/custom/config/file"
}
],
"image": "quay.io/signalfx/splunk-otel-collector:0.33.0",
"essential": true,
"name": "splunk_otel_collector"
}
カスタム Collector コンテナの定義：
Collector イメージを指定します。
環境変数
SPLUNK_CONFIGにカスタム設定ファイルのパスを設定します。
あるいは、ecs_observer 設定 で説明されているように、SPLUNK_CONFIG_YAML 環境変数を使用してカスタムコンフィギュレーション YAML を直接指定することもできます。
ecs_observer 設定 🔗
カスタム設定で拡張 Amazon Elastic Container Service Observer ( ecs_observer ) を使用すると、サービス名、タスク定義、コンテナ・ラベルでフィルターリングされた、実行中のタスクのメトリクスターゲットを検出できます。 ecs_observer は現在 Prometheus ターゲットに限定されており、以下の読み取り専用アクセス許可が必要です。このアクセス許可は、タスクロールにアタッチされたカスタマ管理ポリシーに追加することで、タスクロールに追加できます。
ecs:List*
ecs:Describe*
以下のカスタム設定例では、lorem-ipsum-cluster クラスターと us-west-2 地域で Prometheus ターゲットを検索するように設定された ecs_observer を示しており、タスク ARN パターンは ^arn:aws:ecs:us-west-2:906383545488:task-definition/lorem-ipsum-task:[0-9]+$ です。
結果は/etc/ecs_sd_targets.yamlに書き込まれます。prometheus レシーバーは、結果ファイルからターゲットを読み込むように設定されています。access_token と realm の値は SPLUNK_ACCESS_TOKEN と SPLUNK_REALM 環境変数から読み込まれます。
extensions:
ecs_observer:
refresh_interval: 10s
cluster_name: 'lorem-ipsum-cluster'
cluster_region: 'us-west-2'
result_file: '/etc/ecs_sd_targets.yaml'
task_definitions:
- arn_pattern: "^arn:aws:ecs:us-west-2:906383545488:task-definition/lorem-ipsum-task:[0-9]+$"
metrics_ports: [9113]
metrics_path: /metrics
receivers:
prometheus:
config:
scrape_configs:
- job_name: 'lorem-ipsum-nginx'
scrape_interval: 10s
file_sd_configs:
- files:
- '/etc/ecs_sd_targets.yaml'
processors:
batch:
resourcedetection:
detectors: [ecs]
override: false
exporters:
signalfx:
access_token: ${SPLUNK_ACCESS_TOKEN}
realm: ${SPLUNK_REALM}
service:
extensions: [ecs_observer]
pipelines:
metrics:
receivers: [prometheus]
processors: [batch, resourcedetection]
exporters: [signalfx]
ecs_observer 設定に ARN パターンを設定します。 🔗
このタスクARNパターンを使用すると、ecs_observer 、タスク lorem-ipsum-task の実行中のリビジョンでターゲットを検出するようになります。つまり、タスク lorem-ipsum-task の複数のリビジョンが実行されている場合、ecs_observer は Collector サイドカーコンテナが実行されているタスクの外でターゲットを検出します。サイドカーデプロイメントでは、Collectorと監視対象コンテナは同じタスク内にあるため、メトリクスターゲットはタスク内になければなりません。
この問題を解決するには、以下のように完全なタスクARNを使用します。タスクのリビジョンに合わせて、タスクARNパターンを更新する必要があります。
...
- arn_pattern: "^arn:aws:ecs:us-west-2:906383545488:task-definition/lorem-ipsum-task:3$"
...
直接コンフィギュレーションを使用する 🔗
Fargateではファイルシステムがすぐに利用できないので、SPLUNK_CONFIG_YAML 環境変数を使って設定YAMLを直接指定する必要があります。
たとえば、AWS Systems Manager Parameter Store の splunk-otel-collector-config というパラメータにカスタム構成の YAML を格納できます。Collector コンテナの定義で、valueFrom を使用して、パラメータを SPLUNK_CONFIG_YAML 環境変数に割り当てます。次の例では、MY_SPLUNK_ACCESS_TOKEN と MY_SPLUNK_REALM はプレースホルダ値で、0.33.0 は画像タグです。
{
"environment": [
{
"name": "SPLUNK_ACCESS_TOKEN",
"value": "MY_SPLUNK_ACCESS_TOKEN"
},
{
"name": "SPLUNK_REALM",
"value": "MY_SPLUNK_REALM"
}
],
"secrets": [
{
"valueFrom": "splunk-otel-collector-config",
"name": "SPLUNK_CONFIG_YAML"
}
],
"image": "quay.io/signalfx/splunk-otel-collector:0.33.0",
"essential": true,
"name": "splunk_otel_collector"
}
注釈
タスクがパラメータ ストアへの読み取りアクセスを持つようにするには、AmazonSSMReadOnlyAccess ポリシーをタスク ロールに追加します。
スタンドアロン・タスク 🔗
ecs_observer 拡張機能では、クラスター全体のターゲットをスキャンできます。スキャンを使用すると、監視対象のアプリケーションを含むタスクとは別のタスクにCollectorをデプロイすることで、テレメトリデータを収集できます。これは、Collectorコンテナと監視対象アプリケーションコンテナが同じタスクにあるサイドカー・デプロイメントとは対照的です。
スタンドアロン・タスク用にECS resourcedetection プロセッサーを構成しないでください。スタンドアロンCollectorタスク自体のリソースが検出され、監視対象のアプリケーションを含むタスクのリソースが検出されなくなるためです。
AWS Graviton2 🔗
AWS Graviton2はデフォルトのFargate構成でサポートされています。CollectorのDockerイメージは、AMD64とARM64の両方のアーキテクチャーで実行できます。