Collector のデプロイモード

Splunk Distribution of OpenTelemetry Collector は、単一のバイナリと 2 つのデプロイ方法を提供します。どちらのデプロイ方法もデフォルト設定を使用して構成できます。

Splunk Distribution of the OpenTelemetry Collector は、ホスト監視（エージェント）モード と データ転送（ゲートウェイ）モードの 2 つのデプロイモードのいずれかでデプロイできます。

注: 「Deployment: Patterns you can apply to deploy the OpenTelemetry Collector 」にある OpenTelemetry プロジェクトの公式ドキュメントも参照してください。

ホスト監視（エージェント）モード

ホスト監視（エージェント）モードでは、Collector はアプリケーションと共に、またはアプリケーションと同じホスト上で実行され、Splunk Observability Cloud に直接データを送信します。スタンドアロンエージェントとしてデプロイされた場合、Splunk Distribution of OpenTelemetry Collector は、デプロイされ設定された唯一のコンポーネントとなります。

次の図は、スタンドアロン・モードのアーキテクチャーを示しています：

データの流れは環境によって異なります。詳しくは「Get started with the Splunk Distribution of the OpenTelemetry Collector」を参照してください。

ホスト監視 (エージェント) モードを使用する場合

これらのことを行いたい場合は、ホスト監視（エージェント）モードを使用します：

  • インストルメンテーションを設定します。ホストモニタリング（エージェント）モードは、バッチ処理、キューイング、リトライを含むアプリケーションからの責任をオフロードします。

  • ホストとアプリケーションのメトリクス、およびメトリクス、スパン、ログのホストとアプリケーションのメタデータ・エンリッチメントを収集します。

データ転送（ゲートウェイ）モード

データ転送（ゲートウェイ）モードは通常、クラスター、データセンター、またはリージョンごとにデプロイされます。ゲートウェイモードのコレクタは、Kubernetes と、スタンドアロン エージェント モードで実行されている 1 つ以上の Collector の両方からデータを収集し、Splunk Observability Cloud に送信します。デフォルトゲートウェイの設定ファイルについては 、「data forwarding (gateway) mode configuration in GitHub」を参照してください。

次の図は、データ転送（ゲートウェイ）モードのアーキテクチャを示しています：

注: データ転送（ゲートウェイ）モードでメトリクスとメタデータを転送するには、「「Metrics and metadata not available in data forwarding (gateway) mode」を参照してください。

データ転送 (ゲートウェイ) モードを使用する場合

オプションですが、ゲートウェイモードの Collector は大規模な Kubernetes デプロイに有益であり、大規模クラスターではゲートウェイ Collector の追加を検討できます。大規模な Kubernetes セットアップを定義するための厳密なルールは、ホストの仕様、ホストとノードの数、およびテレメトリの量がさまざまであるため存在しませんが、25 ホストが小規模な環境の限界と見なされることがあります。

データ転送（ゲートウェイ）モードは、以下のいずれかを行う場合に使用します：

  • より大きなバッファを設定します。

  • 再試行の待機間隔を長く設定します。

  • データ送信に必要なイグレスポイント数を制限します。

  • APIトークン管理を統合。詳しくは「Token usage with a Collector in data forwarding (gateway) mode」を参照してください。

データ転送（ゲートウェイモード）のCollectorでのトークンの使用状況

ホストモニタリング（エージェント）モードの Collectors がデータ転送（ゲートウェイ）モードの別の Collectors にデータを送信する設定では、エージェント Collectors はデータを Splunk Observability Cloud バックエンドに直接送信しません。この場合、ゲートウェイ Collectors の取り込みトークンのみが使用され、ゲートウェイにデータを送信している Collectors のトークンは、SignalFx エクスポータを使用していない限り無視されます。したがって、Splunk Observability Cloudでデータを参照するには、ゲートウェイCollectorに有効なトークンが1つあればよく、残りのCollectorには無効または期限切れのトークンがある可能性があります。

SignalFxエクスポーターでのトークンの使用状況

エージェントモードの Collector がデフォルト設定で SignalFx エクスポータを使用している場合、またはエクスポータの設定 access_token_passthrough が true に設定されている場合、その特定の Collector からのデータは、ゲートウェイ Collector のトークンではなく、Collector のアクセストークンを使用して Splunk Observability Cloud に送信されます。

詳しくは「SignalFx エクスポータ」を参照してください。

OTLP/HTTP エクスポータでのトークンの使用状況

エージェントモードのCollectorがゲートウェイ上で実行されているotlpレシーバーにデータをエクスポートし、ゲートウェイのトークンの代わりにソースで設定されたトークンを使用する場合は、デフォルトゲートウェイ設定のinclude_metadata: trueのコメントを外します。

詳細は、GitHub の「Default gateway config」および「Associate passthroughs to an access token」を参照してください。

Collector はどのようなモードでデプロイされていますか？どうすれば変更できますか。

提供されたスクリプトを使用して Collector をインストールする場合、Collector は構成ファイルで指定されたモードでデプロイされます。

LinuxとWindows

WindowsおよびLinuxインストーラの場合、デフォルトの構成yamlはCollectorをエージェントとして設定します。

コンフィギュレーションyamlへのパスはenv変数 SPLUNK_CONFIG 、デフォルトで設定されます：

  • Linux：/etc/otel/collector/<gateway or agent>_config.yaml

  • Windows：C:\ProgramData\Splunk\OpenTelemetry Collector\<gateway or agent>_config.yaml

デプロイモードを変更するには、代わりにゲートウェイ構成 yaml ファイルへのパスの SPLUNK_CONFIG を変更します。データ転送（ゲートウェイ）モード yaml の詳細については、「データ転送（ゲートウェイ）モード」を参照してください。

Kubernetes

Collector for Kubernetes には、さまざまなデプロイメントオプションがあります。これらは、それぞれの Helm 値マッピングの enabled フィールドを使用して構成できます。構成 yaml へのアクセス方法については、「Advanced configuration for Kubernetes」を参照してください。

主なデプロイモードは以下の通りです：

  • デフォルトでは、agent DaemonSetとclusterReceiverデプロイコンポーネントが含まれています。

  • すべてのコレクターモード（agent DaemonSet、およびclusterReceiverとgatewayのコンポーネントを含む）。

デフォルトでは、agent DaemonSet は、Kubernetes クラスターの各ノードで、OpenTelemetry Collector エージェントを実行する Pod をデプロイします。エージェント Pod は、それぞれのノードで実行されているアプリケーション、サービス、その他のオブジェクトからデータを収集し、そのデータを Splunk Observability Cloud に送信します。

この Kubernetes クラスターには 3 つのノードが含まれています。各ノードにはテレメトリデータを Splunk Observability Cloud に送信する OpenTelemetry Collector エージェント Pod が含まれています。

各モードのコンポーネントの詳細については、「Helm chart architecture and components」を参照してください。

Kubernetes環境でデプロイメントモードを変更する

Collector モードを変更したい場合は、既存の設定を上書きするように、希望の設定で新しい Helm チャートをデプロイします。Kubernetes の公式ドキュメントで「Deployment」を参照してください。

GithubでさまざまなHelmチャートを見つけることができます：

エージェントCollector からゲートウェイCollector へのデータ送信

ホスト監視（エージェント）Collector を手動で設定して、Splunk Distribution of OpenTelemetry Collector のゲートウェイインスタンスまたはクラスターにデータを送信できます。これには、ゲートウェイを指すようにエージェントのパイプラインエクスポータを変更する必要があります。

Collector がデータ転送（ゲートウェイ）モードで別の Collector にデータを送信するように設定するには、以下の設定を参照してください：

エージェント設定

ホスト監視（エージェント）モード構成ファイルで、SPLUNK_GATEWAY_URL 環境変数をゲートウェイの URL に更新します。

また、以下をチェックする必要がある可能性があります：

  • 環境変数 SPLUNK_API_URL をゲートウェイのURLに更新し、イングレス・ポート（デフォルトでは 6060 ）を指定します。

  • 環境変数 SPLUNK_INGEST_URL をゲートウェイのURLに更新し、イングレス・ポート（デフォルトでは 9943 ）を指定します。

  • メトリクス、トレース、ログのパイプラインが、ゲートウェイの適切なレシーバーにデータを送信することを確認します。

トレース相関を有効にするには、トレースパイプラインで signalfx エクスポータを使用します。エージェントとゲートウェイ間の他のすべてのパイプラインは、より効率的な otlp エクスポータを使用できます。

注: メトリクスに otlp エクスポーターを使用している場合、hostmetrics 集計はゲートウェイで行われます。

次の例は、ゲートウェイ Collector にデータを送信するために、Collector をホスト監視（エージェント）モードで設定する方法を示しています：

YAML 
receivers:
   hostmetrics:
      collection_interval: 10s
      scrapers:
         cpu:
         disk:
         filesystem:
         memory:
         network:
# More receivers

processors:
   resourcedetection:
      detectors: [system,env,gce,ec2]
      override: true
   resource/add_environment:
      attributes:
         - action: insert
            value: staging
            key: deployment.environment
# More processors

exporters:
   # Traces
   otlp:
      endpoint: "${SPLUNK_GATEWAY_URL}:4317"
      tls:
         insecure: true
   # Metrics, events, and APM correlation calls
   signalfx:
      access_token: "${SPLUNK_ACCESS_TOKEN}"
      api_url: "http://${SPLUNK_GATEWAY_URL}:6060"
      ingest_url: "http://${SPLUNK_GATEWAY_URL}:9943"
      sync_host_metadata: true
      correlation:
   # Logs
   otlp:
      endpoint: "${SPLUNK_GATEWAY_URL}:4317"
# More exporters

service:
   extensions: [health_check, http_forwarder, zpages]
   pipelines:
      traces:
         receivers: [jaeger, zipkin]
         processors: [memory_limiter, batch, resourcedetection, resource/add_environment]
         exporters: [otlp, signalfx]
      metrics:
         receivers: [hostmetrics]
         processors: [memory_limiter, batch, resourcedetection]
         exporters: [otlp]
      metrics/internal:
         receivers: [prometheus/internal]
         processors: [memory_limiter, batch, resourcedetection]
         exporters: [signalfx]
      logs:
         receivers: [otlp]
         processors: [memory_limiter, batch, resourcedetection]
         exporters: [otlp]
   # More pipelines

ゲートウェイ設定

データ転送（ゲートウェイ）モード構成ファイルの以下のセクションを変更します。

  • レシーバーがエージェント設定のエクスポーターと一致していることを確認します。

  • Collector をデータ転送（ゲートウェイ）モードに設定して、ポート 4317、6060、および 9943 の要求を待ち受けます。

  • 環境変数 SPLUNK_GATEWAY_URL を https://api.${SPLUNK_REALM}.signalfx.com に更新します。

Collector をデータ転送 ( ゲートウェイ ) モードに設定してエージェントから データを受信するには、以下の設定を使用します：

YAML 
extensions:
   http_forwarder:
      egress:
         endpoint: "https://api.${SPLUNK_REALM}.signalfx.com"
# More extensions

receivers:
   otlp:
      protocols:
         grpc:
         http:
   signalfx:
# More receivers

exporters:
   # Traces (Agent)
   otlphttp:
      access_token: "${SPLUNK_ACCESS_TOKEN}"
      endpoint: "https://ingest.${SPLUNK_REALM}.signalfx.com/v2/trace/otlp"
   # Metrics + Events (Agent)
   signalfx:
      access_token: "${SPLUNK_ACCESS_TOKEN}"
      realm: "${SPLUNK_REALM}"
   # Metrics + Events (Gateway)
   signalfx/internal:
      access_token: "${SPLUNK_ACCESS_TOKEN}"
      realm: "${SPLUNK_REALM}"
      sync_host_metadata: true
# More exporters

service:
   extensions: [http_forwarder]
   pipelines:
      traces:
         receivers: [otlp]
         processors:
         - memory_limiter
         - batch
         exporters: [otlphttp]
      metrics:
         receivers: [otlp]
         processors: [memory_limiter, batch]
         exporters: [signalfx]
      metrics/internal:
         receivers: [prometheus/internal]
         processors: [memory_limiter, batch, resourcedetection/internal]
         exporters: [signalfx/internal]
   # More pipelines

SignalFxエクスポーターでメトリクスを送信する

エージェントとゲートウェイの両方のメトリクスに SignalFx エクスポータを使用する場合は、ゲートウェイで集約を非アクティブ化します。これを行うには、次の例のように、translation_rules と exclude_metrics を空のリストに設定します。

注: ゲートウェイからホストメトリクスを収集する場合は、変換ルールをそのまま使用して別の SignalFx エクスポータインスタンスを使用します。たとえば、メトリクス / 内部パイプラインで hostmetrics オプションを使用します。
YAML 
receivers:
   hostmetrics:
      collection_interval: 10s
      scrapers:
         cpu:
         disk:
         filesystem:
         memory:
         network:

exporters:
   # Traces
   otlphttp:
      access_token: "${SPLUNK_ACCESS_TOKEN}"
      traces_endpoint: "https://ingest.${SPLUNK_REALM}.signalfx.com/v2/trace/otlp"
   # Metrics + Events (Agent)
   signalfx:
      access_token: "${SPLUNK_ACCESS_TOKEN}"
      realm: "${SPLUNK_REALM}"
      translation_rules: []
      exclude_metrics: []
   # Metrics + Events (Gateway)
   signalfx/internal:
      access_token: "${SPLUNK_ACCESS_TOKEN}"
      realm: "${SPLUNK_REALM}"
      sync_host_metadata: true

service:
   extensions: [http_forwarder]
   pipelines:
      traces:
         receivers: [otlp]
         processors:
         - memory_limiter
         - batch
         exporters: [otlphttp]
      metrics:
         receivers: [signalfx]
         processors: [memory_limiter, batch]
         exporters: [signalfx]
      metrics/internal:
         receivers: [prometheus/internal]
         processors: [memory_limiter, batch, resourcedetection/internal]
         exporters: [signalfx/internal]