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

リソース検出プロセッサーは OpenTelemetry Collector コンポーネントで、受信するテレメトリからリソースを検出し、それらに関する追加のメタデータを収集することができます。サポートされるパイプラインタイプは、traces 、metrics 、および 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 がインフラストラクチャメタデータを収集できなくなる可能性があります。

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

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

インストーラ・スクリプトを使用して Linux 用 Collector をインストールします。

インストーラ・スクリプトを使用して Collector for Windows をインストールします。

Install the Collector for Kubernetes using Helm

このドキュメントに記載されているようにプロセッサーを設定します。
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]

注文に関する考慮事項 🔗

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

複数のAWSディテクターを使用する場合は、以下の順序に従ってください： lambda、elastic_beanstalk、eks、ecs、ec2。

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

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

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 でアクティブになっています： gcp、ecs、ec2、azure、および 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をご利用のお客様

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

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

はじめに 🔗

メイン構成 🔗

注文に関する考慮事項 🔗

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

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

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

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

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

Amazon Elastic Beanstalkのメタデータ 🔗

Amazon EKS のメタデータ 🔗

AWS EC2のメタデータ 🔗

AWS ECS メタデータ 🔗

AWS Lambda のメタデータ 🔗

Azure のメタデータ 🔗

Azure AKS のメタデータ 🔗

Consul のメタデータ 🔗

Docker のメタデータ 🔗

環境変数 🔗

GCPメタデータ 🔗

GCEメタデータ 🔗

GKEメタデータ 🔗

Google App Engineのメタデータ 🔗

Google Cloud Runのメタデータ 🔗

Google Cloud Functionsのメタデータ 🔗

Heroku のメタデータ 🔗

Openshiftのメタデータ 🔗

システムのメタデータ 🔗

`attributes` から `resource_attributes` への移行 🔗

設定 🔗

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

Was this topic useful?

Splunk

Related Topics

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

はじめに 🔗

メイン構成 🔗

注文に関する考慮事項 🔗

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

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

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

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

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

Amazon Elastic Beanstalkのメタデータ 🔗

Amazon EKS のメタデータ 🔗

AWS EC2のメタデータ 🔗

AWS ECS メタデータ 🔗

AWS Lambda のメタデータ 🔗

Azure のメタデータ 🔗

Azure AKS のメタデータ 🔗

Consul のメタデータ 🔗

Docker のメタデータ 🔗

環境変数 🔗

GCPメタデータ 🔗

GCEメタデータ 🔗

GKEメタデータ 🔗

Google App Engineのメタデータ 🔗

Google Cloud Runのメタデータ 🔗

Google Cloud Functionsのメタデータ 🔗

Heroku のメタデータ 🔗

Openshiftのメタデータ 🔗

システムのメタデータ 🔗

attributes から resource_attributes への移行 🔗

設定 🔗

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

Was this topic useful?

`attributes` から `resource_attributes` への移行 🔗