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

Collector のデプロイモード 🔗

You can deploy the Splunk Distribution of the OpenTelemetry Collector in one of two deployment modes: host monitoring (agent) mode and data forwarding (gateway) mode.

注釈

デプロイ: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 の利用開始 をご覧ください。

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

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

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

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

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

Data forwarding (gateway) mode is typically deployed per cluster, data center, or region. A Collector in gateway mode collects data both from Kubernetes and from one or more Collectors running in standalone agent mode and sends it to Splunk Observability Cloud. For the default gateway config file see data forwarding (gateway) mode configuration in GitHub .

The following image shows the architecture for the data forwarding (gateway) mode:

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))

注釈

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

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

While optional, the Collector in gateway mode is beneficial for large-scale Kubernetes deployments, and you might consider adding a gateway Collector in big clusters. There isn’t a strict rule for defining a large-scale Kubernetes setup due to varying host specifications, host and node numbers, and telemetry volume, although 25 hosts is sometimes considered the limit for a small environment.

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

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

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

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

  • APIトークン管理を一元化します。詳しくは Token usage with a Collector in data forwarding (gateway) mode を参照してください。

Token usage with a Collector in data forwarding (gateway) mode 🔗

In a set-up where Collectors in host monitoring (agent) mode send data to another Collector in data forwarding (gateway) mode, agent Collectors don’t send the data directly to the Splunk Observability Cloud back-end. In this case, only the ingest token in the gateway Collector is used, and tokens in the Collectors that are sending data to a gateway are ignored, unless they’re using the SignalFx exporter. Therefore, you only need one valid token for the gateway Collector to see data in Splunk Observability Cloud, and the rest of Collectors could have invalid or expired tokens.

Token usage with the SignalFx exporter 🔗

If any of your Collectors in agent mode is using the SignalFx exporter with the default configuration or if the exporter’s setting access_token_passthrough is set to true, then data from that specific Collector will be sent to Splunk Observability Cloud using the Collector’s access token instead of the Gateway Collector’s token.

Learn more at SignalFx エクスポーター.

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の高度な設定 を参照してください。

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

  • Default, which includes the agent DaemonSet and the clusterReceiver deployment component.

  • All collector modes, which includes agent DaemonSet, and the clusterReceiver and the gateway components.

By default, the agent DaemonSet deploys a pod running the OpenTelemetry Collector agent in each node of your Kubernetes cluster. The agent pods gather data from your applications, services, and other objects running in their respective nodes, then send the data to Splunk Observability Cloud.

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

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

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

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

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

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

You can manually configure a host monitoring (agent) Collector to send data to a Splunk Distribution of the OpenTelemetry Collector gateway instance or cluster. This requires changing the pipeline exporters in the agent to point to the gateway.

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

注釈

If you want to collect host metrics from the Gateway, use a different SignalFx exporter instance with the translation rules intact. For example, use the hostmetrics option in the metrics/internal pipeline.

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年02月24日 に最終更新されました。