SignalFx エクスポーター

SignalFx エクスポータにより、OpenTelemetry Collector はトレース、ログ、メトリクスを SignalFx エンドポイントに送信できます。コンポーネントの設定方法については、続きをお読みください。

注意: SignalFx エクスポータは、デフォルトでメトリクスを作成し、除外します。どのメトリクスが作成され、どのメトリクスが除外されるかを理解し、この動作を変更する方法を学ぶには、続きをお読みください。

SignalFx エクスポータは、OpenTelemetry Collector がメトリクスとイベントを SignalFx エンドポイントに送信できるようにする、ネイティブの OTel コンポーネントです。サポートされるパイプラインタイプは、tracesmetricslogs です。詳細については「パイプラインでデータを処理する」を参照してください。

SignalFx Smart Agent はサポート終了となりましたが、Smart Agent レシーバー、SignalFx レシーバー、SignalFx エクスポータなどの OTel ネイティブコンポーネントは利用可能で、サポートされています。レシーバーについては、「Smart Agent レシーバー」および 「SignalFx レシーバー」を参照してください。

はじめに

注: このコンポーネントは、ホスト監視(エージェント)モードでデプロイする場合、Splunk Distribution of the OpenTelemetry Collector のデフォルト設定に含まれます。詳細については、「Collector deployment modes」を参照してください。デフォルト設定の詳細については、「Helm で Collector for Kubernetes を設定する」、「Collector for Linux のデフォルト設定」、または「Collector for Windows のデフォルト設定」を参照してください。このドキュメントで説明されているように、いつでも設定をカスタマイズできます。

デフォルトでは、Splunk Distribution of OpenTelemetry Collector には、tracesmetricslogs/signalfx パイプラインに SignalFx エクスポーターが含まれています。

サンプル構成

次の例は、SignalFx exporterのデフォルトの構成で、メトリクススとイベントの取り込み、およびトレースとメトリクススの相関を示しています:

YAML
# Metrics + Events
signalfx:
  access_token: "${SPLUNK_ACCESS_TOKEN}"
  api_url: "${SPLUNK_API_URL}"
  ingest_url: "${SPLUNK_INGEST_URL}"
  # Use instead when sending to gateway (http forwarder extension ingress endpoint)
  #api_url: http://${SPLUNK_GATEWAY_URL}:6060
  #ingest_url: http://${SPLUNK_GATEWAY_URL}:9943
  sync_host_metadata: true

SignalFx エクスポータを追加する場合は、メトリクスとログパイプラインの両方を設定します。次の例のように、SignalFx レシーバーも追加してください。

YAML
service:
  pipelines:
    metrics:
      receivers: [signalfx]
      processors: [memory_limiter, batch, resourcedetection]
      exporters: [signalfx]
    logs:
      receivers: [signalfx]
      processors: [memory_limiter, batch, resourcedetection]
      exporters: [signalfx]

ヒストグラムメトリクスをOTLP形式で送信

Splunk Distribution of OpenTelemetry Collector は、バージョン 0.98 以降の OTLP ヒストグラムメトリクスをサポートしています。詳細については、「Explicit bucket histograms」を参照してください。

SignalFx Exporter を使用してヒストグラムデータを Splunk Observability Cloud に送信するには、send_otlp_histograms オプションを true に設定します。例:

YAML
exporters:
  signalfx:
    access_token: "${SPLUNK_ACCESS_TOKEN}"
    api_url: "${SPLUNK_API_URL}"
    ingest_url: "${SPLUNK_INGEST_URL}"
    sync_host_metadata: true
    correlation:
    send_otlp_histograms: true

デフォルトのメトリクスフィルター

SignalFx エクスポータは、不要なカスタムメトリクスを防ぐために、デフォルトで多くのメトリクスを除外しています。詳細については、「List of metrics excluded by default」を参照してください。

デフォルトの除外を無効にし、メトリクスを手動で含めるには、include_metrics オプションを使用します。例:

YAML
exporters:
  signalfx:
    include_metrics:
      - metric_names: [cpu.interrupt, cpu.user, cpu.system]
      - metric_name: system.cpu.time
        dimensions:
          state: [interrupt, user, system]

以下の例では、 cpuディメンション値を持つ cpu.interrupt メトリクスと、コアごとおよび集約 cpu.idle メトリクスの両方を送信するようにエクスポーターに指示します:

YAML
exporters:
  signalfx:
    include_metrics:
      - metric_name: "cpu.idle"
      - metric_name: "cpu.interrupt"
        dimensions:
          cpu: ["*"]

デフォルトで除外されるメトリクスのリスト

SignalFx エクスポータがデフォルトで除外するメトリクスは、default_metrics.go ファイルにリストされています。以下のスニペットは、リストの最新バージョンを示しています。

YAML
# DefaultExcludeMetricsYaml holds a list of hard coded metrics that's added to the
# exclude list from the config. It includes non-default metrics collected by
# receivers. This list is determined by categorization of metrics in the SignalFx
# Agent. Metrics in the OpenTelemetry convention that have equivalents in the
# SignalFx Agent that are categorized as non-default are also included in this list.

exclude_metrics:

# Metrics in SignalFx Agent Format
- metric_names:
  # CPU metrics.
  - cpu.interrupt
  - cpu.nice
  - cpu.softirq
  - cpu.steal
  - cpu.system
  - cpu.user
  - cpu.utilization_per_core
  - cpu.wait

  # Disk-IO metrics
  - disk_ops.pending

  # Virtual memory metrics
  - vmpage_io.memory.in
  - vmpage_io.memory.out

# Metrics in OpenTelemetry Convention

# CPU Metrics
- metric_name: system.cpu.time
  dimensions:
    state: [idle, interrupt, nice, softirq, steal, system, user, wait]

- metric_name: cpu.idle
  dimensions:
    cpu: ["*"]

# Memory metrics
- metric_name: system.memory.usage
  dimensions:
    state: [inactive]

# Filesystem metrics
- metric_name: system.filesystem.usage
  dimensions:
    state: [reserved]
- metric_name: system.filesystem.inodes.usage

# Disk-IO metrics
- metric_names:
  - system.disk.merged
  - system.disk.io
  - system.disk.time
  - system.disk.io_time
  - system.disk.operation_time
  - system.disk.pending_operations
  - system.disk.weighted_io_time

# Network-IO metrics
- metric_names:
  - system.network.packets
  - system.network.dropped
  - system.network.tcp_connections
  - system.network.connections

# Processes metrics
- metric_names:
  - system.processes.count
  - system.processes.created

# Virtual memory metrics
- metric_names:
  - system.paging.faults
  - system.paging.usage
- metric_name: system.paging.operations
  dimensions:
    type: [minor]

 k8s metrics
- metric_names:
  - k8s.cronjob.active_jobs
  - k8s.job.active_pods
  - k8s.job.desired_successful_pods
  - k8s.job.failed_pods
  - k8s.job.max_parallel_pods
  - k8s.job.successful_pods
  - k8s.statefulset.desired_pods
  - k8s.statefulset.current_pods
  - k8s.statefulset.ready_pods
  - k8s.statefulset.updated_pods
  - k8s.hpa.max_replicas
  - k8s.hpa.min_replicas
  - k8s.hpa.current_replicas
  - k8s.hpa.desired_replicas

  # matches all container limit metrics but k8s.container.cpu_limit and k8s.container.memory_limit
  - /^k8s\.container\..+_limit$/
  - '!k8s.container.memory_limit'
 - '!k8s.container.cpu_limit'

  # matches all container request metrics but k8s.container.cpu_request and k8s.container.memory_request
  - /^k8s\.container\..+_request$/
  - '!k8s.container.memory_request'
  - '!k8s.container.cpu_request'

  # matches any node condition but k8s.node.condition_ready
  - /^k8s\.node\.condition_.+$/
  - '!k8s.node.condition_ready'

  # kubelet metrics
  # matches (container|k8s.node|k8s.pod).memory...
  - /^(?i:(container)|(k8s\.node)|(k8s\.pod))\.memory\.available$/
  - /^(?i:(container)|(k8s\.node)|(k8s\.pod))\.memory\.major_page_faults$/
  - /^(?i:(container)|(k8s\.node)|(k8s\.pod))\.memory\.page_faults$/
  - /^(?i:(container)|(k8s\.node)|(k8s\.pod))\.memory\.rss$/
  - /^(?i:(k8s\.node)|(k8s\.pod))\.memory\.usage$/
  - /^(?i:(container)|(k8s\.node)|(k8s\.pod))\.memory\.working_set$/

  # matches (k8s.node|k8s.pod).filesystem...
  - /^k8s\.(?i:(node)|(pod))\.filesystem\.available$/
  - /^k8s\.(?i:(node)|(pod))\.filesystem\.capacity$/
  - /^k8s\.(?i:(node)|(pod))\.filesystem\.usage$/

  # matches (k8s.node|k8s.pod).cpu.time
  - /^k8s\.(?i:(node)|(pod))\.cpu\.time$/

  # matches (container|k8s.node|k8s.pod).cpu.utilization
  - /^(?i:(container)|(k8s\.node)|(k8s\.pod))\.cpu\.utilization$/

  # matches k8s.node.network.io and k8s.node.network.errors
  - /^k8s\.node\.network\.(?:(io)|(errors))$/

  # matches k8s.volume.inodes, k8s.volume.inodes and k8s.volume.inodes.used
  - /^k8s\.volume\.inodes(\.free|\.used)*$/

サービスまたは環境を使用してメトリクスをフィルターリングする

SignalFx エクスポータは、受信したトレースをメトリクスに関連付けます。エクスポータが新しいサービスや環境を検出すると、Splunk Observability Cloud のサービスや環境にソース(ホストや Pod など)を関連付け、sf_servicesf_environment を使用してそれらを識別します。その後、トレースサービスと環境に基づいてこれらのメトリクスをフィルタリングできます。

注: Splunk Observability Cloud でトレースを確認するには、OTLP/HTTP エクスポータを使用してトレースを送信する必要があります。

correlation 設定を使用して、サービスおよび環境プロパティのディメンションへの同期を制御します。次のオプションがあります。

  • endpoint必須。API リクエストのベース URL、https://api.us0.signalfx.com など。デフォルトは、api_url または https://api.{realm}.signalfx.com/ です。

  • timeout:バックエンドへのデータ送信のタイムアウト。デフォルトでは 5 秒です。

  • stale_service_timeout:スパンのサービス名が最後に表示されてから、相関を解除するまでの待ち時間。デフォルトでは 5 分です。

  • max_requests:HTTP リクエストの最大並列数。デフォルトでは 20 です。

  • max_buffered:更新がドロップされる前にバッファリングできる相関更新の最大数。デフォルトでは 10,000 です。

  • max_retries:相関関係の更新に失敗した場合の最大再試行回数。デフォルトでは 2 です。

  • log_updates:ディメンションへの相関更新をデバッグレベルでログに記録するかどうか。デフォルトでは false です。

  • retry_delay:再試行の間隔。デフォルトでは 30 秒です。

  • cleanup_interval: 重複リクエストをパージする頻度。デフォルトでは 1 分です。

  • sync_attributes:値として指定されたディメンションに同期するために、スパンから読み込む属性のキーを含むマップ。デフォルトは {"k8s.pod.uid": "k8s.pod.uid", "container.id": "container.id"} です。

その他のオプションは「設定」セクションを参照してください。

ヒストグラムメトリクスをドロップする

カーディナリティが高いメトリクスの場合、ヒストグラムバケットを削除すると便利です。ヒストグラムメトリクスをドロップするには、drop_histogram_bucketstrue に設定します。

drop_histogram_buckets を有効にすると、ヒストグラムバケットは _bucket 接尾辞を持つデータポイントに変換される代わりにドロップされます。_sum_count_min_max を持つデータポイントのみがエクスポータを介して送信されます。

変換ルールからの移行

注意: Collector v0.121.0 以降、変換ルールは廃止され、既存の Collector プロセッサを優先して削除されています。

変換ルールの移行ガイド

translation_rules は廃止されています。代わりに既存の OpenTelemetry Collector プロセッサを使用してください。置換オプションの詳細については「migration guide in GitHub」を参照してください。

廃止されたルール(参照用のみ)

translation_rules フィールドを使用すると、追加のプロセッサーを必要とせずに、メトリクスを変換したり、他のメトリクスス値をコピー、計算、集計してカスタムメトリクスを作成したりすることができます。

変換ルールでは現在、次のような操作が可能です:

  • aggregate_metric: 指定されたディメンションを削除してメトリクスを集約します。

  • calculate_new_metric:一貫性のある2つのメトリクスを操作して新しいメトリクスを作成します。

  • convert_values: 指定されたメトリクス名について、float値をintに、intをfloatに変換します。

  • copy_metrics: 別のメトリクスのコピーとして新しいメトリクスを作成します。

  • delta_metric: 指定されたデルタ以外のメトリクスに対して新しいデルタのメトリクスを作成します。

  • divide_int:メトリクスの整数値を指定された係数でスケーリングします。

  • drop_dimensions:指定されたメトリクス、またはグローバルにディメンションを削除します。

  • drop_metrics: 指定された名前を持つメトリクスをすべて削除します。

  • multiply_float: メトリクスの浮動小数点値を与えられた浮動小数点係数でスケーリングします。

  • multiply_int:メトリクスの int 値を指定された int 係数でスケーリングします。

  • rename_dimension_keys:指定されたメトリクス、またはグローバルなディメンションの名前を変更します。

  • rename_metrics:指定されたメトリクス名を指定されたメトリクス名に置き換えます。

  • split_metric:指定されたディメンションについて、指定されたメトリクスを複数の新しいメトリクスに分割します。

デフォルトの変換ルールと生成されたメトリクス

SignalFx エクスポータは、デフォルトで translation/constants.go で定義された変換ルールを使用します。

デフォルトのルールは、Infrastructure Monitoring に直接レポートされるメトリクスを作成します。その属性または値を変更する場合は、変換ルールまたはその構成要素であるホストのメトリクスを変更する必要があります。

デフォルトでは、SignalFx エクスポータは、ホストメトリクスレシーバーから以下の集約メトリクスを作成します。

  • cpu.idle

  • cpu.interrupt

  • cpu.nice

  • cpu.num_processors

  • cpu.softirq

  • cpu.steal

  • cpu.system

  • cpu.user

  • cpu.utilization

  • cpu.utilization_per_core

  • cpu.wait

  • disk.summary_utilization

  • disk.utilization

  • disk_ops.pending

  • disk_ops.total

  • memory.total

  • memory.utilization

  • network.total

  • process.cpu_time_seconds

  • system.disk.io.total

  • system.disk.operations.total

  • system.network.io.total

  • system.network.packets.total

  • vmpage_io.memory.in

  • vmpage_io.memory.out

  • vmpage_io.swap.in

  • vmpage_io.swap.out

集約されたメトリクスに加えて、デフォルトのルールでは、以下の「コアごとの」カスタムホストメトリクスが利用可能です。CPU 番号はディメンション cpu に割り当てられます。

  • cpu.interrupt

  • cpu.nice

  • cpu.softirq

  • cpu.steal

  • cpu.system

  • cpu.user

  • cpu.wait

設定

次の表は、SignalFx エクスポーターの設定オプションです:

同梱

https://raw.githubusercontent.com/splunk/collector-config-tools/main/cfg-metadata/exporter/signalfx.yaml

注意: 同じ設定で SignalFx レシーバーを使用する場合は、access_token_passthrough 設定を使用します。この設定を有効にする場合は、SignalFx レシーバーと SignalFx エクスポータのみを使用してください。

トラブルシューティング

If you are a Splunk Observability Cloud customer and are not able to see your data in Splunk Observability Cloud, you can get help in the following ways.

Available to Splunk Observability Cloud customers

Available to prospective customers and free trial users

  • Ask a question and get answers through community support at Splunk Answers.

  • Join the Splunk community #observability Slack channel to communicate with customers, partners, and Splunk employees worldwide.