SignalFx エクスポーター 🔗

注意

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

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

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

はじめに 🔗

注釈

このコンポーネントは、ホスト監視 (エージェント) モードでデプロイする場合、Splunk Distribution of the OpenTelemetry Collector のデフォルト設定に含まれます。詳細は Collector のデプロイモードを参照してください。

デフォルト設定の詳細については、Helmで Collector for Kubernetes を設定する、Collector for Linux のデフォルト設定、または Collector for Windows のデフォルト設定を参照してください。この文書で説明されているように、いつでも設定をカスタマイズすることができます。

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

サンプル構成 🔗

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

# 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 レシーバーも追加してください：

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

Send histogram metrics in OTLP format 🔗

The Splunk Distribution of OpenTelemetry Collector supports OTLP histogram metrics starting from version 0.98 and higher. See Explicit bucket histograms for more information.

To send histogram data to Splunk Observability Cloud, set the send_otlp_histograms option to true. For example:

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エクスポーターは、不要なカスタムメトリクスを防ぐために、デフォルトで多くのメトリクスを除外しています。詳細については、デフォルトで除外されるメトリクスのリストを参照してください。

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

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 メトリクスの両方を送信するようにエクスポーターに指示します：

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

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

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

# 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のサービスや環境にソース（ホストやポッドなど）を関連付け、sf_service と sf_environment を使用してそれらを識別します。その後、トレースサービスと環境に基づいてこれらのメトリクスをフィルターリングできます。

注釈

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

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

endpoint: 必須.https://api.us0.signalfx.com のような API リクエストのベース URL。デフォルトは 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"} です。

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

変換ルールとメトリクス変換 🔗

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

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

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

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

設定 🔗

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

注意

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

トラブルシューティング 🔗

Splunk Observability Cloudをご利用のお客様で、Splunk Observability Cloudでデータを確認できない場合は、以下の方法でサポートを受けることができます。

Splunk Observability Cloudをご利用のお客様

Submit a case in the Splunk Support Portal .
Contact Splunk Support .

見込み客および無料トライアルユーザー様

Splunk Answers のコミュニティサポートで質問し、回答を得る
Splunk #observability ユーザーグループの Slack チャンネルに参加して、世界中の顧客、パートナー、Splunk 社員とのコミュニケーションを図る。参加するには、Get Started with Splunk Community マニュアルのチャットグループを参照してください。

This page was last updated on 2024年09月18日.

Related Topics