Docs » Splunk Distribution of the OpenTelemetry Collector の利用開始 » Collector コンポーネント » Collectorコンポーネント: プロセッサー » リソース検出プロセッサー

リソース検出プロセッサー 🔗

リソース検出プロセッサーは OpenTelemetry Collector コンポーネントで、受信するテレメトリからリソースを検出し、それらに関する追加のメタデータを収集することができます。サポートされるパイプラインタイプは、tracesmetrics 、および logs です。詳細は パイプラインでデータを処理する を参照してください。

リソース検出プロセッサーは、ディテクターを使用して、さまざまなソースからシステムのメタデータを収集します。リソース検出プロセッサーがサポートする検出対象は、以下のとおりです:

  • ホスト環境変数

  • オンホスト・システム情報

  • アマゾン ウェブ サービス EC2、ECS、EKS、Elastic Beanstalk、Lambda

  • AzureインスタンスとAKS

  • Google Cloud Platform GCE、GKE、Cloud Run、Cloud Functions、アプリエンジン

  • Consul エージェント

  • OpenshiftとKubernetes

  • Dockerコンテナ

  • Heroku

リソース検出プロセッサーによって収集されたメタデータを使用して、収集されたテレメトリ内のリソース値を拡張または上書きできます。デフォルトでは、プロセッサーは既存のリソースメタデータを上書きします。既存のリソースに属性を追加することもできます。

注釈

リソースプロセッサーについては、リソースプロセッサー を参照してください。

はじめに 🔗

注釈

このコンポーネントは、Splunk Distribution of the OpenTelemetry Collector のデフォルト設定に含まれています。

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

デフォルトでは、Splunk Distribution of OpenTelemetry Collector は、ホスト監視 (エージェント) モードでデプロイする場合、すべての定義済みパイプラインにリソース検出プロセッサーを含みます。Collector をデータ転送 (ゲートウェイ) モードでデプロイする場合、リソース検出プロセッサーは内部メトリクスを収集します。詳細は、Collector のデプロイモード を参照してください。

より多くの種類のリソースを検出するには、以下の設定例に示すように、追加のプロセッサーを設定し、既存または新規のパイプラインに追加します。

注意

resourcedetection または resourcedetection/internal プロセッサーを構成から削除しないでください。プロセッサーを削除すると、Splunk Observability Cloud がインフラストラクチャメタデータを収集できなくなる可能性があります。

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

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

  1. このドキュメントに記載されているようにプロセッサーを設定します。

  2. Collector を再起動します。

メイン構成 🔗

リソース属性プロセッサーは、detectors のディテクターのリストを受け付けます。各ディテクターに対して、どのリソース属性を収集するか、または無視するか、また既存の属性をオーバーライドしなければならないかどうかを指定できます。ディテクターのリストについては 利用可能なディテクターとメタデータ を参照してください。

注釈

Collector のバージョン 0.81 以降、attributes の設定は非推奨です。attributes から resource_attributes に移行するには、attributes から resource_attributes への移行 を参照してください。

次の例は、リソース属性プロセッサーの主な構成設定を示しています:

resourcedetection:
  # List of detectors
  detectors: [system, ec2]
  # Whether to override existing attributes. Default is true
  override: true
  system:
    resource_attributes:
      host.name:
        enabled: true
      host.id:
        enabled: false
  ec2:
    resource_attributes:
      host.name:
        enabled: false
      host.id:
        enabled: true

次に、設定ファイルの service セクションの必要なパイプラインにプロセッサーを含めます:

service:
  pipelines:
    metrics:
      processors: [resourcedetection]
    logs:
      processors: [resourcedetection]
    traces:
      processors: [resourcedetection]

注文に関する考慮事項 🔗

複数のディテクターが同じ属性名を挿入する場合、最初のディテクターのみが考慮されます。例えば、eksec2 ディテクターを使用する場合、cloud.platform 属性の値は ec2 ではなく aws_eks になります。

複数のAWSディテクターを使用する場合は、以下の順序に従ってください: lambdaelastic_beanstalkeksecsec2

リソースの検出とデータの収集 🔗

以下のサンプル設定は、異なるターゲットからのリソースを検出する方法を示しています。

EC2リソースとタグを収集する 🔗

次の例では、既存のメタデータを上書きすることなく、EC2インスタンスからリソース、環境変数、選択したタグを検出する方法を示しています:

processors:
  resourcedetection/ec2:
    detectors: [env, ec2]
    timeout: 2s
    override: false
    ec2:
    # List of attributes to collect or ignore
     resource_attributes:
       host.name:
         enabled: false
       host.id:
         enabled: true
    # Regex patterns for tag keys you want to add as resource attributes
      tags:
        - ^tag1$
        - ^tag2$
        - ^label.*$

TLS接続でOpenShiftリソースを収集する 🔗

以下の例では、IPアドレスとポート、TLS証明書とサービス・トークンを指定して、OpenShiftとKubernetes APIからリソース属性を収集する方法を示しています:

processors:
  resourcedetection/openshift:
    detectors: [openshift]
    timeout: 2s
    override: false
    openshift:
      address: "127.0.0.1:4444"
      token: "<token>"
      tls:
        insecure: false
        ca_file: "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt"

利用可能なすべてのソースを使用してシステムのメタデータを収集する 🔗

以下の例は、system ディテクターで利用可能なすべてのソースを使用してホスト名を決定する方法を示しています。resource_attributes フィールドは、選択した属性のみを含めるようにプロセッサーに指示します。

processors:
  resourcedetection/system:
    detectors: ["system"]
    system:
      # Default is "dns" and "os"
      hostname_sources: ["lookup", "cname", "dns", "os"]
      # Attributes to collect or ignore. Invalid names are ignored
      resource_attributes:
        host.name:
          enabled: true
        host.id:
          enabled: true

利用可能なディテクターとメタデータ 🔗

リソース検出プロセッサーは、検出器を使用してリソースメタデータを収集します。デフォルトでは、以下のディテクターが Splunk Distribution of OpenTelemetry Collector でアクティブになっています: gcpecsec2azure、および system

Amazon Elastic Beanstalkのメタデータ 🔗

elastic_beanstalk ディテクターは、X-Ray が有効になっているすべての Beanstalk インスタンスの AWS X-Ray 設定を読み取ることで、以下のリソース属性を収集します:

  • cloud.provider (値: aws )

  • cloud.platform (値: aws_elastic_beanstalk )

  • deployment.environment

  • service.instance.id

  • service.version

Amazon EKS のメタデータ 🔗

eks ディテクターは以下のリソース属性を収集します:

  • cloud.provider (値: aws )

  • cloud.platform (値: aws_eks )

AWS EC2のメタデータ 🔗

ec2 ディテクターは以下のリソース属性を収集します:

  • cloud.provider (値: aws )

  • cloud.platform (値: aws_ec2 )

  • cloud.account.id

  • cloud.region

  • cloud.availability_zone

  • host.id

  • host.image.id

  • host.name

  • host.type

ec2 、タグを収集することもできます。タグを収集するには、EC2インスタンスのポリシーに ec2:DescribeTags 権限を追加します。EC2インスタンスでプロキシを使用している場合は、メタデータのリクエストを許可します。

AWS ECS メタデータ 🔗

ecs ディテクターは以下のリソース属性を収集します。タスクのメタデータ・エンドポイント(TMDE)バージョン3および4のみがサポートされています。

  • cloud.provider (値: aws )

  • cloud.platform (値: aws_ecs )

  • cloud.account.id

  • cloud.region

  • cloud.availability_zone

  • aws.ecs.cluster.arn

  • aws.ecs.task.arn

  • aws.ecs.task.family

  • aws.ecs.task.revision

  • aws.ecs.launchtype (TMDEバージョン4のみ)

  • aws.log.group.names (TMDEバージョン4のみ)

  • aws.log.group.arns (TMDEバージョン4のみ)

  • aws.log.stream.names (TMDEバージョン4のみ)

  • aws.log.stream.arns (TMDEバージョン4のみ)

AWS Lambda のメタデータ 🔗

lambda ディテクターは、実行時環境変数を使用して、以下のリソース属性を収集します:

  • aws.log.group.names (値: $AWS_LAMBDA_LOG_GROUP_NAME )

  • aws.log.stream.names (値: $AWS_LAMBDA_LOG_STREAM_NAME )

  • cloud.provider (値: aws )

  • cloud.platform (値: aws_lambda )

  • cloud.region (値: $AWS_REGION )

  • faas.name (値: $AWS_LAMBDA_FUNCTION_NAME )

  • faas.version (値: $AWS_LAMBDA_FUNCTION_VERSION )

  • faas.instance (値: $AWS_LAMBDA_LOG_STREAM_NAME )

  • faas.max_memory (値: $AWS_LAMBDA_FUNCTION_MEMORY_SIZE )

Azure のメタデータ 🔗

azure ディテクターは、Azure Instance Metadata Service を通じて以下のリソース属性を収集します:

  • cloud.provider (値: azure )

  • cloud.platform (値: azure_vm )

  • cloud.region

  • cloud.account.id (値:サブスクリプションID)

  • host.id (値:仮想マシンID)

  • host.name

  • azure.vm.name ( host.name と同じ)

  • azure.vm.size (値:仮想マシンサイズ)

  • azure.vm.scaleset.name (値:スケールセットの名前(ある場合))

  • azure.resourcegroup.name (値:リソースグループ名)

Azure AKS のメタデータ 🔗

aks ディテクターは以下のリソース属性を収集します:

  • cloud.provider (値: azure )

  • cloud.platform (値: azure_aks )

Consul のメタデータ 🔗

consul ディテクターは、Consul エージェントに問い合わせ、その設定エンドポイントを読み取ることで、以下のリソース属性を収集します:

  • cloud.region (価値:Consul データセンター)

  • host.id (値: ConsulノードID)

  • host.name (値: Consulノード名)

ディテクターはまた、Consulメタデータのすべてのキーと値のペアを収集し、ラベルと値のペアに変換します。

Docker のメタデータ 🔗

docker ディテクターは、Dockerデーモンにクエリを送信することで、ホストマシンから以下のリソース属性を収集します:

  • host.name

  • os.type

Herokuアプリケーションの場合、dyno IDは仮想化環境を識別します。

注釈

Dockerデーモンに連絡するには、Dockerソケットをマウントします。Linuxの場合、ソケットは /var/run/docker.sock です。

環境変数 🔗

env ディテクターは、= 文字で区切られたキーと値のペアのリストとして、OTEL_RESOURCE_ATTRIBUTES 環境変数からリソース情報を収集します。

GCPメタデータ 🔗

gcp ディテクターは、Google Cloud クライアント・ライブラリを使用して、メタデータ・サーバーからリソース情報と環境変数を読み取ります。ディテクターはメタデータを使用して、どの GCP アプリケーションが実行されているかを判断し、関連する属性を抽出します。

GCEメタデータ 🔗

gcp ディテクターはGCEから以下のリソース属性を収集します:

  • cloud.provider (値: gcp )

  • cloud.platform (値: gcp_compute_engine )

  • cloud.account.id (値:プロジェクトID)

  • cloud.region `` (例えば、``us-central1

  • cloud.availability_zone (例えば、us-central1-c

  • host.id (値:インスタンスID)

  • host.name (値:インスタンス名)

  • host.type (値:マシンタイプ)

GKEメタデータ 🔗

gcp ディテクターは、GKEから以下のリソース属性を収集します:

  • cloud.provider (値: gcp )

  • cloud.platform (値: gcp_kubernetes_engine )

  • cloud.account.id (値:プロジェクトID)

  • cloud.region (リージョン GKEクラスターのみ。例: us-central1 )

  • cloud.availability_zone (ゾーン GKEクラスターのみ。例えば、us-central1-c )

  • k8s.cluster.name

  • host.id (値:インスタンスID)

  • host.name (値:インスタンス名、ワークロード ID が無効化されている場合のみ)。

Google App Engineのメタデータ 🔗

gcp ディテクターは、Google App Engine から以下のリソース属性を収集します:

  • cloud.provider (値: gcp )

  • cloud.platform (値: gcp_app_engine )

  • cloud.account.id (値:プロジェクトID)

  • cloud.region (例えば、us-central1 )。

  • cloud.availability_zone (例: us-central1-c )

  • faas.id (値:インスタンスID)

  • faas.name (値:サービス名)

  • faas.version (サービスバージョン)

Google Cloud Runのメタデータ 🔗

gcp ディテクターはGoogle Cloud Runから以下のリソース属性を収集します:

  • cloud.provider (値: gcp )

  • cloud.platform (値: gcp_cloud_run )

  • cloud.account.id (値:プロジェクトID)

  • cloud.region (例えば、us-central1 )。

  • faas.id (値:インスタンスID)

  • faas.name (値:サービス名)

  • faas.version (値:サービスバージョン)

Google Cloud Functionsのメタデータ 🔗

gcp ディテクターは、Google Cloud Functions から以下のリソース属性を収集します:

  • cloud.provider (値: gcp )

  • cloud.platform (値: gcp_cloud_functions )

  • cloud.account.id (値:プロジェクトID)

  • cloud.region (例えば、us-central1 )。

  • faas.id (値:インスタンスID)

  • faas.name (関数名)

  • faas.version (関数バージョン)

Heroku のメタデータ 🔗

heroku ディテクターは、Heroku メタデータ機能を通じて以下のリソース属性を収集します:

  • heroku.release.version (値: 現在のリリースの識別子)

  • heroku.release.creation_timestamp (値:リリース作成日時)

  • heroku.release.commit (値: 現在のリリースのコミットハッシュ)

  • heroku.app.name (値:アプリケーション名)

  • heroku.app.id (値:アプリケーションの一意識別子)

  • heroku.dyno.id (値: Dyno識別子。ホスト名として使用)

注釈

heroku ディテクターを使用する前に、アプリケーションの Heroku メタデータ機能を有効にしてください。

Openshiftのメタデータ 🔗

openshift ディテクターは、OpenShift と Kubernetes API にクエリを送信することで以下のリソース属性を収集します:

  • cloud.provider

  • cloud.platform

  • cloud.region

  • k8s.cluster.name

デフォルトでは、ディテクターは環境変数 KUBERNETES_SERVICE_HOST および KUBERNETES_SERVICE_PORT を使用してAPIアドレスを決定します。デフォルトのサービス・トークンは /var/run/secrets/kubernetes.io/serviceaccount/token です。TLSが有効でCAファイルを定義していない場合、ディテクターは /var/run/secrets/kubernetes.io/serviceaccount/ca.crt の証明書を使用します。すべての設定は構成で上書きできます。

システムのメタデータ 🔗

system ディテクターは以下のリソース属性を収集します:

  • host.name

  • host.id

  • os.type

デフォルトでは、host.name 属性は、利用可能な場合は完全修飾ドメイン名(FQDN)です。ディテクターは、フォールバックとしてホスト名を使用します。

ディテクターのデフォルト設定は hostname_sources: ["dns", "os"] で、次のサポートされている値を使用して上書きできます。

  • cname:正式名。

  • dns: hosts ファイルのホスト名、CNAME 、またはDNSの逆引きクエリの結果のいずれか(この順)。

  • lookup: 現在のホストのIPアドレスのDNS逆引き。

  • os::ローカルマシンのカーネルが提供するホスト名。

FQDNの使用を避けるには、hostname_sources フィールドの値を os に設定します。

注釈

CollectorをDockerコンテナとして実行している場合は、docker ディテクターを使用します。

attributes から resource_attributes への移行 🔗

Collector のバージョン0.81から、リソース検出プロセッサーは attributes オプションを廃止し、各ディテクターに固有の resource_attributes に置き換えます。

移行するには、attributes 内の属性を各ディテクターの関連する resource_attributes リストに移動します。たとえば、次のような構成を考えてみます:

resourcedetection:
  detectors: [system]
  # Deprecated in version 0.81
  attributes: ['host.name', 'host.id']

以前の設定を以下のように置き換えることができます:

resourcedetection:
  detectors: [system]
  system:
    resource_attributes:
      host.name:
        enabled: true
      host.id:
        enabled: true
      os.type:
        enabled: false

設定 🔗

以下の表は、リソース検出プロセッサーのコンフィギュレーション・オプションを示しています:

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

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

Splunk Observability Cloudをご利用のお客様

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

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

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

This page was last updated on 2024年05月29日.