要件

続行するには、AWS Fargate（Fargate）の以前の知識が必要です。詳細については、公式の「AWS Fargate user guide」を参照してください。

このデプロイメントには、Collector リリース v0.33.0 以上（イメージタグ 0.33.0 以上に対応）が必要です。最新のイメージをダウンロードするには、「イメージリポジトリ」を参照してください。

ガイド付きセットアップを使用する

ガイド付きセットアップを使用して、ECS タスクにサイドカーとして Collector をデプロイします。以下のCollector 構成オプションのいずれかを選択します：

• デフォルト：Collector イメージの /etc/otel/collector/fargate_config.yaml ファイルが Collector 設定に使用されます。

• ファイル：Collector 設定に使用するファイルを指定します。「ecs_observer configuration」を参照してください。

• AWS パラメータストア：Collector 構成に使用する AWS パラメータストアのキーまたは ARN を指定します。「ecs_observer configuration」を参照してください。

セットアップガイドにアクセスする

Amazon Fargate ガイド付きセットアップを開きます。

オプションで、ガイド付きセットアップに自分で移動することもできます：

1. Splunk Observability Cloud にログインします。

2. ナビゲーションメニューで、Data Management を選択します。

3. Available integrations タブにアクセスするか、Deployed integrations タブで Add Integration を選択します。

4. Amazon Fargate のタイルを選択します。

5. セットアップガイドの手順に従ってください。

はじめに

例で示したデフォルトの 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 configuration」で見ることができます。smartagent/ecs-metadata レシーバーはデフォルトで有効化されます。

要約すると、デフォルトのCollectorコンテナ定義では以下のことが行われます：

• Collector イメージを指定します。

• 環境変数 SPLUNK_ACCESS_TOKEN を使ってアクセストークンを設定します。

• 環境変数 SPLUNK_REALM を使ってレルムを設定します。

• 環境変数 SPLUNK_CONFIG を使って、デフォルトの設定ファイルパスを設定します。

• 環境変数 ecs-metadata を使用して、Collector イメージから ECS_METADATA_EXCLUDED_IMAGES メトリクスを除外します。

環境変数 SPLUNK_MEMORY_LIMIT_MIB を使用して、memory_limiter プロセッサのメモリ制限を設定できます。デフォルトのメモリ制限は 512 MiB です。

カスタム設定を使用する

次の例は、カスタム設定を使用するように設定された 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 にカスタム設定ファイルのパスを設定します。

あるいは「Amazon Elastic Container Service オブザーバーエクステンションを設定する」で説明されているように、SPLUNK_CONFIG_YAML 環境変数を使用してカスタム設定 YAML を直接指定することもできます。

ecs_observerconfiguration

カスタム設定で拡張 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]

theecs_observerconfiguration に 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を直接指定する必要があります。

たとえば、カスタム設定の YAML を AWS Systems Manager Parameter Store の splunk-otel-collector-config というパラメータに格納できます。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"
}

スタンドアロン・タスク

ecs_observer 拡張機能は、クラスター全体のターゲットをスキャンできます。スキャンでは、監視対象のアプリケーションを含むタスクとは別のタスクに Collector をデプロイして、テレメトリデータを収集できます。これは、Collector コンテナと監視対象のアプリケーションコンテナが同じタスク内にあるサイドカーデプロイメントとは対照的です。

スタンドアロン・タスク用にECS resourcedetection プロセッサーを構成しないでください。スタンドアロンCollectorタスク自体のリソースが検出され、監視対象のアプリケーションを含むタスクのリソースが検出されなくなるためです。

AWS Graviton2

AWS Graviton2 は、デフォルトの Fargate 設定でサポートされています。Collector Docker イメージは、AMD64 アーキテクチャと ARM64 アーキテクチャの両方で実行できます。