Nomad でCollectorをデプロイする

Nomad を使用して Splunk Observability Cloud OpenTelemetry Collector をデプロイします。

Nomad 導入オーケストレーターを使用して、Splunk Observability Cloud のメトリクスデータとトレースデータを受信、処理、エクスポートする統一された方法を提供するジョブを作成します。

注: ジョブファイルは参考として提供されるものであり、本番での使用を意図したものではありません。

はじめに

ジョブファイルを実行するには、以下が必要です：

  • Nomad クラスターへのアクセス

  • (オプション）Consulクラスターへのアクセス

NomadとConsulのローカル開発エージェントを立ち上げます：

  1. 「nomad binary file」と「consul binary」をダウンロードします。

  2. 以下のコマンドを2つの異なるターミナルで実行します：

$ nomad agent -dev -network-interface='{{ GetPrivateInterfaces | attr "name" }}'

$ consul agent -dev

NomadクラスターにCollectorジョブをデプロイするには、次の例に示すようにNomadジョブ構成で環境変数を設定します：

env {
  SPLUNK_ACCESS_TOKEN = "<SPLUNK_ACCESS_TOKEN>"
  SPLUNK_REALM = "<SPLUNK_REALM>"
  SPLUNK_MEMORY_TOTAL_MIB = 2048
  // You can specify more environment variables to override default values.
}

次の例に示すように、独自の Collector 構成ファイルを使用する場合は、[template stanza] でコンテンツを指定できます。

template {
 data        = <<EOF
# The following example shows how to set up your Collector configuration file.
extensions:
  health_check: null
  zpages: null
receivers:
  hostmetrics:
    collection_interval: 10s
    scrapers:
      cpu: null
      disk: null
      filesystem: null
      load: null
      memory: null
      network: null
      paging: null
      processes: null
processors:
  batch: null
  memory_limiter:
    check_interval: 2s
    limit_mib: ${SPLUNK_MEMORY_LIMIT_MIB}
exporters:
  signalfx:
    access_token: ${SPLUNK_ACCESS_TOKEN}
    api_url: https://api.${SPLUNK_REALM}.signalfx.com
    correlation: null
    ingest_url: https://ingest.${SPLUNK_REALM}.signalfx.com
    sync_host_metadata: true
  debug:
    verbosity: detailed
service:
  extensions:
  - health_check
  - zpages
  pipelines:
    metrics:
      exporters:
      - logging
      - signalfx
      processors:
      - memory_limiter
      - batch
      receivers:
      - hostmetrics
      - signalfx
EOF
    destination = "local/config/otel-agent-config.yaml"
}

デプロイモード

Collector をゲートウェイまたはエージェントとして実行します。詳細については、「Collector deployment modes」を参照してください。

Collector をゲートウェイとして実行する

次の例に示すように、サービスジョブを登録して Collector をゲートウェイ として実行します：

$ git clone https://github.com/signalfx/splunk-otel-collector.git
$ cd splunk-otel-collector/deployments/nomad
$ nomad run otel-gateway.nomad

[service] スケジューラを使用して、ダウンしない長時間のサービスをスケジュールします。これにより、[service] スケジューラはジョブの制約を満たす多数のノードを評価し、タスクグループの配置に最適なノードを選択します。

サービスジョブは、オペレータが明示的に停止するまで稼働し続けます。サービスタスクが終了した場合は失敗とみなされ、ジョブの再起動と再スケジュールスタンザに従って処理されます。

Collector をエージェントとして実行する

以下の例に示すように、システムジョブを登録して Collector をエー ジェントとして実行します：

$ git clone https://github.com/signalfx/splunk-otel-collector.git
$ cd splunk-otel-collector/deployments/nomad
$ nomad run otel-agent.nomad

[system] スケジューラを使用して、ジョブの制約を満たすすべてのクライアントで実行する必要があるジョブを登録します。[system] スケジューラは、クライアントがクラスターに参加するか、準備完了状態に移行するときにも呼び出されます。これは、制約が満たされた場合に、登録されているすべてのシステムジョブが再評価され、タスクが新しく使用可能になったノードに配置されることを意味します。

[system] スケジューラタイプは、クラスター内のすべてのノードに存在する必要があるタスクをデプロイおよび管理するのに役立ちます。これらのタスクは Nomad によって管理されるため、ジョブの更新、サービス検出などを活用できます。

Nomad 0.9 以降では、システムジョブを配置するのに十分な容量がない場合、システムスケジューラはノード上で実行されている優先順位の低いタスクをプリエンプトします。プリエンプトされるタスクの選択方法の詳細については、プリエンプションを参照してください。

システムジョブは、オペレータまたはプリエンプションによって明示的に停止されるまで稼働し続けます。システムタスクが終了した場合は失敗とみなされ、ジョブの再起動スタンザに従って処理されます。システムジョブには再スケジュール機能はありません。