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

リソースを検出し、それらに関する情報を OpenTelemetry フォーマットで操作するには、リソース検出プロセッサを使用します。コンポーネントの設定方法については、続きをお読みください。

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

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

  • ホスト環境変数

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

  • アマゾン ウェブ サービス 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 deployment modes」を参照してください。

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

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

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

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

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

  3. Collector を再起動します。

メイン構成

リソース属性プロセッサは、detectors のディテクタのリストを受け入れます。各ディテクタに対して、どのリソース属性を収集するか、または無視するか、また既存の属性をオーバーライドする必要があるかどうかを指定できます。ディテクタのリストについては、「Available detectors and metadata」を参照してください。

注: Collector のバージョン 0.81 以降では、attributes の設定は廃止されています。attributes から resource_attributes へ移行するには、「Migrate from attributes to resource_attributes」を参照してください。

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

resourcedetection:
  # List of detectors
  detectors: [ec2, system]
  # 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ディテクターを使用する場合は、以下の順序に従ってください: 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 で有効になっています: gcpecsec2azuresystem

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 `` (For example, ``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_HOSTKUBERNETES_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

設定

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

同梱

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

トラブルシューティング

__ ___ ___ _ ______ _____________ _____ ________ ___ ___ ___ ____ __ ___ ____ ____ __ ______ _____________ ______ ___ ___ ___ ____ __ ___ _________ _____

_________ __ ______ _____________ _____ _________

_________ __ ___________ _________ ___ ____ _____ _____

  • ___ _ ________ ___ ___ _______ _______ _________ _______ __ ______ ________

  • ____ ___ ______ ______________ ____ _____ _____ _______ __ ___________ ____ __________ _________ ___ ______ _________ __________ __ _____ ___ ____ _______