OpenTelemetryでタグや属性を使用する 🔗

タグは、記録された測定値に関連付けられたデータのキーと値のペアで、解析や検査時にコンテキスト情報を提供したり、測定値を区別したり、グループ化したりします。

OpenTelemetry データモデルでは、タグは属性として提供されます。Splunk Observability Cloud が属性付きで traces をインジェストした後、これらは tags として利用できます。また、属性を使用して Monitoring Metric Sets を作成することもできます。

重要

OpenTelemetry の展開を開始する前に、命名規則を定義してください。詳しくは属性の意味上の規約を参照してください。

属性を作成および設定する 🔗

metrics 、logs 、traces には、手動インストルメンテーション、自動インスツルメンテーション、または Collector レベルで、リソースプロセッサーや属性プロセッサーなどの各種プロセッサーを使用して、属性をアタッチできます。

プロセッサーを使えば、以下のことができます：

insert: キーと値のペアがまだ存在しなければ、それを作成します。
update: キーが存在する場合、属性を更新します。
upsert: 属性の挿入や更新を行います。
delete: データから属性を削除します。
hash: 既存の属性の値をSHA1アルゴリズムを使ってハッシュします。
extract: 正規表現ルールを使用して値を抽出します。
convert: 属性を別のタイプに変換します。

属性プロセッサーの構成例 🔗

atributes プロセッサーをコンフィギュレーションに含めます：

processors:
  # Overrides an existing tag for a span.
  attributes/copyfromexistingkey:
    actions:
      - key: SPAN_TAG_KEY
        from_attribute: "SPAN_TAG_VALUE"
        action: upsert
  # Adds a tag to spans without a tag.
  attributes/newenvironment:
    actions:
      - key: SPAN_TAG_KEY
        value: "SPAN_TAG_VALUE"
        action: insert

次に、次の例のように、パイプラインにも追加します：

service:
  pipelines:
    traces:
      processors:
        - memory_limiter
        - batch
        - resourcedetection
        - attributes/copyfromexistingkey
        - attributes/newenvironment

属性の意味上の規約 🔗

標準リソースの意味上の規約 🔗

さまざまな標準リソースについては、以下の命名規則を参照してください。

サービス属性 🔗

監視対象のサービスを説明するために、多くの属性を使用することができます。

service.name は、OpenTelemetry SDK によって自動的に追加され、サービスの論理名を定義します。これをカスタマイズすることもできますが、シンプルに保ち、サービスの他の側面をキャプチャするために他の属性を使用します。

以下のサービス属性が有用です：

service.namespace: サービスを所有するチームを特定します。
service.instance.id: サービスの一意のインスタンスを識別します。
service.version:サービスのバージョンを示します。

Telemetry SDK 🔗

OpenTelemetry SDK は、使用されているインストルメンテーション・ライブラリに関する情報を記録するために、これらの属性を自動的に設定します：

telemetry.sdk.name:通常は opentelemetry に設定されます。
telemetry.sdk.language: java など、SDKの言語。
telemetry.sdk.version:どのバージョンのSDKを使用しているかを示します。

コンテナ 🔗

コンテナ内で実行されるサービスには、container.id 、container.name 、container.image.name など、数多くの属性があります。

詳しくはOpenTelemetry GitHubレポコンテナの意味上の規約を参照してください。

ホスト数 🔗

host.id 、host.name 、host.arch など、ホストで実行されるサービスには数多くの属性があります。

詳しくは、OpenTelemetry GitHub レポホストの意味上の規約を参照してください。

デプロイ環境 🔗

staging や production のように、サービスがデプロイされている環境を識別するには deployment.environment 属性を使用します。

Splunk Observability Cloud はこの属性を使用して関連コンテンツを有効にするため、この属性を含めることが重要です。詳しくは InfraおよびAPMの関連コンテンツを有効にするために Collector を設定するを参照してください。

クラウド 🔗

cloud.provider 、cloud.account.id 、cloud.region など、パブリッククラウド環境で動作するサービスの情報を取得する属性があります。

詳しくはOpenTelemetry GitHubレポクラウドの意味上の規約を参照してください。

注意

GCPのようないくつかのクラウドプロバイダーは、そのプロバイダー特有の意味上の規約を定義しています。詳しくはGoogleの公式ドキュメントを参照してください。

Kubernetes 🔗

Kubernetes で実行されるアプリケーションには、標準化された属性が多数あります。Splunk Distribution of the OpenTelemetry Collectorでは、k8s.cluster.name 、k8s.node.name 、k8s.pod.name 、k8s.namespace.name 、kubernetes.workload.name など、これらの多くが自動的に追加されます。

詳細は、Infrastructure Monitoring の関連コンテンツを参照してください。

カスタム属性を作成するためのベストプラクティス 🔗

カスタム属性が必要な場合は、すでに意味上の規約に含まれている属性名との名前の衝突を避けてください。

また、属性値についても考慮する必要があります。例えば、アプリケーションが所属する特定のビジネスユニットをキャプチャしたい場合、効果的なフィルターリングを容易にするために、ビジネスユニットの値の標準化されたリストから選択することもできます。

OpenTelemetryコミュニティは、以下のような属性の命名に関するガイドラインを提供しています：

その属性が社内だけでなく社外でも使用される場合は、com.acme.shopname のように、属性名の前に会社のドメイン名を付けます。
属性名が特定のアプリケーションに固有で、組織内でのみ使用される場合は、属性名の前にアプリケーション名を付けます。
属性名のプレフィックスとして、既存の OpenTelemetry の意味上の規約名を使用しないでください。
様々な組織や業界で一般的なニーズがあれば、OpenTelemetry仕様にあなたの属性名を追加する提案を提出することを検討してください。
属性名が otel.* で始まるのは避けてください。これは OpenTelemetry 仕様用に予約されているからです。

完全なリストは属性の命名にあります。

メトリクスのカーディナリティに関する考慮事項 🔗

メトリクスのカーディナリティは、メトリクス名と関連するディメンションの組み合わせによって生成される一意のメトリクス時系列（MTS）の数として定義されます。メトリクスのカーディナリティが高いのは、ディメンション・キーの数が多く、それらのディメンション・キーに対して取り得る一意の値の数が多い場合です。

例えば、アプリケーションが custom.metric というメトリクスのデータを送信したとします。

属性がない場合、custom.metricは単一のメトリクス時系列（MTS）を生成します。
一方、custom.metric に customer.id という属性があり、顧客IDの値が何千もある場合、何千ものMTSが生成されることになり、コストやクエリのパフォーマンスに影響を与える可能性があります。

Splunk Observability Cloud は、メトリクスの使用状況を管理できるレポートを提供し、ルールを作成して望ましくないディメンションを削除できます。詳しくはサブスクリプションの使用状況と請求を監視および管理するを参照してください。

This page was last updated on 2024年01月10日.

Related Topics