Docs » Splunk Observability Cloud でサポートされているインテグレーション » Collectorコンポーネント: レシーバー » ホスト・メトリクス・レシーバー

ホスト・メトリクス・レシーバー 🔗

ホスト・メトリクス・レシーバーは、Collector がエージェントとしてデプロイされたときに、ホスト・システムからスクレイピングされたメトリクスを生成します。サポートされているパイプラインタイプは metrics です。

デフォルトでは、Splunk Distribution of OpenTelemetry Collector でホストメトリクスレシーバーが有効化され、以下のメトリクスを収集します:

  • システム・メトリクス

  • CPU使用率メトリクス

  • ディスクI/Oメトリクス

  • CPU負荷メトリクス

  • ファイル・システム使用量メトリクス

  • メモリ使用量メトリクス

  • ネットワーク・インターフェイスとTCPコネクション・メトリクス

  • プロセス・カウント・メトリクス(Linuxのみ)

ホスト・レシーバーのメトリクスは、Infrastructure Monitoring に表示されます。これらを使用して、ダッシュボードやアラートを作成できます。詳細については、アラートをトリガーするディテクターを作成する を参照してください。

注意

SignalFxエクスポーターは、デフォルトでいくつかの利用可能なメトリクスを除外します。デフォルトのメトリクス・フィルターについては、デフォルトで除外されるメトリクスのリスト を参照してください。除外されるメトリクスの最新リストはGitHubにあります。https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/exporter/signalfxexporter/internal/translation/default_metrics.go#L49 を参照してください。

はじめに 🔗

注釈

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

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

以下の手順に従って、コンポーネントの設定とアクティベーションを行ってください:

  1. Splunk Distribution of OpenTelemetry Collector をホストまたはコンテナプラットフォームにデプロイします:

  2. 次のセクションで説明するようにレシーバーを設定します。

  3. Collector を再起動します。

注釈

Splunk Observability Cloud に取り込まれるデータにはシステム制限があります。詳しくは Splunk Observability Cloudの製品別のシステム制限 を参照してください。

コンテナ・ホストのメトリクスを収集する(Linux) 🔗

ホスト・メトリクス・レシーバーは、Linux システム・ディレクトリからメトリクスを収集します。コンテナの代わりにホストのメトリクスを収集するには、以下の手順に従います:

  1. コンテナを実行するときに、ホストのファイルシステム全体をマウントします。例: docker run -v /:/hostfs。ホスト・ファイル・システムのどの部分をマウントするかを選択することもできます。例: docker run -v /proc:/hostfs/proc

  2. ルート・ファイル・システムがどこにあるかを、ホスト・メトリクス受信者が知るように、root_path を構成します。例:

    receivers:
    hostmetrics:
       root_path: /hostfs
    

    ホスト・メトリクス・レシーバーの複数のインスタンスを実行している場合は、すべてのインスタンスに同じ root_path を設定します。

サンプル構成 🔗

次の例に示すように、収集間隔とスクレイピングするメトリクスのカテゴリを構成できます:

hostmetrics:
  collection_interval: <duration> # The default is 1m.
  scrapers:
    <scraper1>:
    <scraper2>:
    ...

スクレーパーはエンドポイントからデータを抽出し、そのデータを指定されたターゲットに送信します。利用可能なスクレーパーを以下の表に示します:

Scraper

説明

system

システム・メトリクス

cpu

CPU使用率メトリクス

disk

ディスクI/Oメトリクス

load

CPU負荷メトリクス

filesystem

ファイル・システム利用率メトリクス

memory

メモリ利用率メトリクス

network

ネットワーク・インターフェイスのI/OメトリクスとTCPコネクション・メトリクス

paging

ページングまたはスワップ領域の使用率とI/Oメトリクス

processes

プロセス数のメトリクス。Linuxでのみ利用可能

process

プロセスごとのCPU、メモリ、ディスクI/Oメトリクス

スクレーパーの構成については、以下のセクションを参照してください。

ディスク 🔗

disk:
  <include|exclude>:
    devices: [ <device name>, ... ]
    match_type: <strict|regexp>

ファイルシステム 🔗

filesystem:
  <include_devices|exclude_devices>:
    devices: [ <device name>, ... ]
    match_type: <strict|regexp>
  <include_fs_types|exclude_fs_types>:
    fs_types: [ <filesystem type>, ... ]
    match_type: <strict|regexp>
  <include_mount_points|exclude_mount_points>:
    mount_points: [ <mount point>, ... ]
    match_type: <strict|regexp>

以下の例では、Linuxシステムの一般的なマウント・ポイントとして、フォワード・スラッシュ( / )を使用しています:

filesystem:
  include_mount_points:
    mount_points: ["/"]
    match_type: strict

同様に、以下の例では、Windowsシステムの一般的なマウントポイントとして C: を示しています:

filesystem:
  include_mount_points:
    mount_points: ["C:"]
    match_type: strict

仮想ファイルシステムを含めるには、include_virtual_filesystemstrue に設定します。

filesystem:
  include_virtual_filesystems: true

GitHubのdaemonset.yamlファイルに、より多くの例があります。

ネットワーク 🔗

network:
  <include|exclude>:
    interfaces: [ <interface name>, ... ]
    match_type: <strict|regexp>

プロセス 🔗

process:
  <include|exclude>:
    names: [ <process name>, ... ]
    match_type: <strict|regexp>
  mute_process_name_error: <true|false>
  mute_process_exe_error: <true|false>
  mute_process_io_error: <true|false>
  scrape_process_delay: <time>

以下の例では、デフォルトに加えて2つのメトリクスを収集し、リソース属性を使用して収集データにプロセスオーナを含めるプロセススクレーパーの設定方法を示します:

receivers:
  hostmetrics:
    scrapers:
      process:
        resource_attributes:
          process.owner:
            enabled: true
        metrics:
          process.memory.usage:
            enabled: true
          process.disk.io:
            enabled: true

For more information about enabling and disabling metrics and resource attributes using the process scraper, see hostmetricsreceiver/process in the OpenTelemetry documentation.

If you continuously see errors related to process reading, consider setting mute_process_name_error, mute_process_exe_error, or mute_process_io_error to true.

フィルターリング 🔗

特定のソースからのメトリクスのサブセットのみを収集するには、filter プロセッサーでホスト・メトリクス・レシーバーを使用します。

さまざまな頻度 🔗

あるメトリクスを他のメトリクスとは異なる頻度でスクレイピングするには、異なる collection_interval 値で複数のホスト・メトリクス・レシーバーを構成します。例:

receivers:
  hostmetrics:
    collection_interval: 30s
    scrapers:
      cpu:
      memory:

  hostmetrics/disk:
    collection_interval: 1m
    scrapers:
      disk:
      filesystem:

service:
  pipelines:
    metrics:
      receivers: [hostmetrics, hostmetrics/disk]

メトリクス 🔗

以下のメトリクス、リソース属性、および属性が使用できます。

注釈

SignalFxエクスポーターは、デフォルトでいくつかの利用可能なメトリクスを除外します。デフォルトのメトリクス・フィルターについては、デフォルトで除外されるメトリクスのリスト を参照してください。

CPUスクレーパー 🔗

詳細については、GitHub の cpu scraper documentation を参照してください。

ディスクスクレーパー 🔗

詳細については、GitHubの ディスクスクレーパーのドキュメント を参照してください。

ファイルシステムスクレーパー 🔗

詳細については、GitHubの ファイルシステム・スクレーパー・ドキュメント を参照してください。

ロードスクレーパー 🔗

詳しくは、GitHubの load scraper documentation を参照してください。

メモリスクレーパー 🔗

詳細については、GitHubの メモリスクレーパーのドキュメント を参照してください。

ネットワークスクレーパー 🔗

詳細については、GitHubの network scraper documentation を参照してください。

ページングスクレーパー 🔗

詳しくは、GitHubの paging scraper documentation を参照してください。

プロセススクレーパー 🔗

詳細については、GitHub の process scraper documentation を参照してください。

プロセススクレーパー 🔗

詳細については、GitHub の processes scraper documentation を参照してください。

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

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

リソース属性 🔗

ホスト・メトリクス・レシーバーは、エクスポートされたメトリクスにリソース属性を設定しません。

リソース属性を設定するには、OTEL_RESOURCE_ATTRIBUTES 環境変数を使用します。例:

export OTEL_RESOURCE_ATTRIBUTES="service.name=<name_of_service>,service.version=<version_of_service>"

特定のメトリクスをアクティブまたは非アクティブにする 🔗

各メトリクスの metrics セクションの enabled フィールドを設定することで、特定のメトリクスをアクティブまたは非アクティブにできます。例:

receivers:
  samplereceiver:
    metrics:
      metric-one:
        enabled: true
      metric-two:
        enabled: false

以下は、アクティブ化されたメトリクスを持つホスト・メトリクス・レシーバーの構成例です:

receivers:
  hostmetrics:
    scrapers:
      process:
        metrics:
          process.cpu.utilization:
            enabled: true

注釈

無効化されたメトリクスは Splunk Observability Cloud に送信されません。

Billing 🔗

  • If you’re in a MTS-based subscription, all metrics count towards metrics usage.

  • ホストベースのプランに加入している場合、このドキュメントでアクティブ(Active: Yes)と記載されているメトリクスはデフォルトとみなされ、無料で含まれます。

Learn more at Infrastructure Monitoringのサブスクリプション使用状況(ホストとメトリクスのプラン).

設定 🔗

以下の表に、ホスト・メトリクス・レシーバーの構成オプションを示します:

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

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

Splunk Observability Cloudをご利用のお客様

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

  • Splunk Answers のコミュニティサポートで質問し、回答を得る

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

このページは 2024年12月19日 に最終更新されました。