Docs » Splunk Distribution of the OpenTelemetry Collector の利用開始 » はじめに:Collectorを理解して使用する » Collector のデプロイモード

Collector のデプロイモード 🔗

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

注釈

デプロイ:OpenTelemetry Collector のデプロイに適用できるパターン にある OpenTelemetry プロジェクトの公式ドキュメントも参照してください。

ホスト監視(エージェント)モード 🔗

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

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

flowchart LR accTitle: Splunk Distribution of the OpenTelemetry Collector in agent mode diagram. accDescr: The Splunk Distribution of the OpenTelemetry Collector contains receivers, processors, exporters, and extensions. Receivers gather metrics and logs from infrastructure, and metrics, traces, and logs from back-end applications. A((applications)) --> S[agent OTel Collector] B((hosts)) --> S[agent OTel Collector] S[agent OTel Collector] --> R((Splunk Observability Suite))

データの流れは環境によって異なります。詳しくは Splunk Distribution of the OpenTelemetry Collector の利用開始 をご覧ください。

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

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

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

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

データ転送(ゲートウェイ)モード 🔗

データ転送 (ゲートウェイ) モードは通常、クラスター、データセンター、または地域ごとに展開されます。ゲートウェイモードのCollectorは、Kubernetesとスタンドアロンエージェントモードで動作する1つ以上のCollectorの両方からデータを収集し、Splunk Observability Cloudに送信します。デフォルトのゲートウェイ設定ファイルについては、GitHubのデータ転送 (ゲートウェイ) モード設定 を参照してください。

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

flowchart LR accTitle: Splunk Distribution of the OpenTelemetry Collector in gateway mode diagram. accDescr: The Splunk Distribution of the OpenTelemetry Collector contains receivers, processors, exporters, and extensions. Receivers gather metrics and logs from infrastructure, and metrics, traces, and logs from back-end applications. A((applications)) --> S[agent OTel Collector] B((hosts)) --> S[agent OTel Collector] S[agent OTel Collector] --> Q[Load Balancer] Q[Load Balancer] --> U[gateway OTel Collector] Q[Load Balancer] --> V[gateway OTel Collector] U[gateway OTel Collector] --> R((Splunk Observability Suite)) V[gateway OTel Collector] --> R((Splunk Observability Suite))

注釈

データ転送(ゲートウェイ)モードでメトリクスとメタデータを転送するには、データ転送(ゲートウェイ)モードでメトリクスとメタデータが利用できない を参照してください。

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

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

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

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

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

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

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

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

Token usage with the otlphttp exporter 🔗

If any of your Collectors in agent mode exports data to the otlp receiver running on the gateway and you want to use the token set at the source instead of the gateway’s token, uncomment include_metadata: true in the default gateway config.

For more details see Default gateway config in GitHub and パススルーをアクセストークンに関連付ける.

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にアクセスする方法については、Kubernetesの高度な設定 を参照してください。

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

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

  • すべてのコレクターモード( agent DaemonSet、および clusterReceivergateway のコンポーネントを含む)。

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

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

各モードのコンポーネントの詳細については、Helmチャートアーキテクチャーとコンポーネント を参照してください。

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

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

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 をホスト監視(エージェント)モードで設定する方法を示しています:

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_URLhttps://api.${SPLUNK_REALM}.signalfx.com に更新します。

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

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_rulesexclude_metrics を空のリストに設定します。

注釈

ゲートウェイからホストメトリクスを収集する場合は、変換ルールをそのまま使用して別のSignalFxエクスポーターインスタンスを使用します。例えば、metrics/internalパイプラインで hostmetrics オプションを使用します。

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]

このページは 2025年04月01日 に最終更新されました。