リソース検出プロセッサー 🔗
リソース検出プロセッサーは 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 をホストまたはコンテナプラットフォームにデプロイします：
このドキュメントに記載されているようにプロセッサーを設定します。
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。
リソースの検出とデータの収集 🔗
以下のサンプル設定は、異なるターゲットからのリソースを検出する方法を示しています。
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.environmentservice.instance.idservice.version
Amazon EKS のメタデータ 🔗
eks ディテクターは以下のリソース属性を収集します：
cloud.provider(値:aws)cloud.platform(値:aws_eks)
AWS EC2のメタデータ 🔗
ec2 ディテクターは以下のリソース属性を収集します：
cloud.provider(値:aws)cloud.platform(値:aws_ec2)cloud.account.idcloud.regioncloud.availability_zonehost.idhost.image.idhost.namehost.type
ec2 、タグを収集することもできます。タグを収集するには、EC2インスタンスのポリシーに ec2:DescribeTags 権限を追加します。EC2インスタンスでプロキシを使用している場合は、メタデータのリクエストを許可します。
AWS ECS メタデータ 🔗
ecs ディテクターは以下のリソース属性を収集します。タスクのメタデータ・エンドポイント（TMDE）バージョン3および4のみがサポートされています。
cloud.provider(値:aws)cloud.platform(値:aws_ecs)cloud.account.idcloud.regioncloud.availability_zoneaws.ecs.cluster.arnaws.ecs.task.arnaws.ecs.task.familyaws.ecs.task.revisionaws.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.regioncloud.account.id(値：サブスクリプションID）host.id(値：仮想マシンID）host.nameazure.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.nameos.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.namehost.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.providercloud.platformcloud.regionk8s.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.namehost.idos.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 マニュアルの チャットグループ を参照してください。