リソース検出プロセッサー
リソースを検出し、それらに関する情報を OpenTelemetry フォーマットで操作するには、リソース検出プロセッサを使用します。コンポーネントの設定方法については、続きをお読みください。
リソース検出プロセッサは 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 OpenTelemetry Collector はホスト監視(エージェント)モードでデプロイする場合、すべての定義済みパイプラインにリソース検出プロセッサを含みます。Collector をデータ転送(ゲートウェイ)モードでデプロイすると、リソース検出プロセッサは内部メトリクスを収集します。詳細については、「Collector deployment modes」を参照してください。
より多くの種類のリソースを検出するには、以下の設定例に示すように、追加のプロセッサーを設定し、既存または新規のパイプラインに追加します。
resourcedetection または resourcedetection/internal プロセッサを設定から削除しないでください。プロセッサを削除すると、Splunk Observability Cloud がインフラストラクチャ メタデータを収集できなくなる可能性があります。以下の手順に従って、コンポーネントの設定とアクティベーションを行ってください:
-
Splunk Distribution of OpenTelemetry Collector をホストまたはコンテナプラットフォームにデプロイします:
-
このドキュメントに記載されているようにプロセッサーを設定します。
-
Collector を再起動します。
メイン構成
リソース属性プロセッサは、detectors のディテクタのリストを受け入れます。各ディテクタに対して、どのリソース属性を収集するか、または無視するか、また既存の属性をオーバーライドする必要があるかどうかを指定できます。ディテクタのリストについては、「Available detectors and metadata」を参照してください。
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ディテクターを使用する場合は、以下の順序に従ってください: 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は仮想化環境を識別します。
/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_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 に設定します。
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
トラブルシューティング
__ ___ ___ _ ______ _____________ _____ ________ ___ ___ ___ ____ __ ___ ____ ____ __ ______ _____________ ______ ___ ___ ___ ____ __ ___ _________ _____
_________ __ ______ _____________ _____ _________
-
______ _ ____ __ ___ ______ _______ _______
-
_______ ______ ________
_________ __ ___________ _________ ___ ____ _____ _____
-
___ _ ________ ___ ___ _______ _______ _________ _______ __ ______ ________
-
____ ___ ______ ______________ ____ _____ _____ _______ __ ___________ ____ __________ _________ ___ ______ _________ __________ __ _____ ___ ____ _______