Docs » Splunk Observability Cloud のメトリクス » メタデータ：ディメンション、カスタムプロパティ、タグ、属性

メタデータ：ディメンション、カスタムプロパティ、タグ、属性 🔗

Splunk Observability Cloud のデータは、追加のメタデータで強化されています。

名前

説明

データ型

フォーマット

ディメンション

メトリクスにコンテキストを追加するために、インジェスト時にメトリック時系列（MTS）とともに送信されます。メトリクス名とともに、MTS を一意に識別します。ディメンション名は時間の経過とともに変化しません。

インフラストラクチャ・メトリクス

キーと値のペア

カスタムプロパティ

インジェスト後にメトリクス・ディメンションに適用して、メトリクスにコンテキストを追加します。カスタムプロパティは、MTS を一意に識別することには寄与しません。

インフラストラクチャ・メトリクス

キーと値のペア

タグ

インジェスト後にメトリクス・ディメンションおよびカスタムプロパティに適用されるラベルまたはキーワード。タグを使用して、sf_tags を使用して、チャートやディテクターで MTS をフィルタリングできます。

インフラストラクチャ・メトリクス

文字列

属性またはスパンタグ

追跡中の操作に関する情報を伝える注釈。

APMメトリクス、コレクタ・メトリクス、スパン

キーと値のペア

ディメンション 🔗

注意

OpenTelemetryデータモデルでは、ディメンションの代わりに attributes を使用します。詳しくは OpenTelemetryのタグ を参照してください。

ディメンションは、キーと値のペアの形式で不変のメタデータであり、モニタリングソフトウェアがメトリクスと共に送信します。インジェスト中に送信される MTS ディメンションのセットは、メトリクス名とともに、MTS を一意に識別するために使用されます。

ディメンションは、メトリクスを送信したホストの名前など、メトリクスに関する追加情報を提供します。例えば、"hostname": "host1"。

以下が該当します。

  • 異なるキーを持つ2つのキーと値のペアは、値に関係なく異なるディメンションです。例えば、"hostname": "bcn" と "clustername": "bcn"。

  • キーが同じで値が異なる2つのキーと値のペアは、異なるディメンションです。例えば、"hostname": "bcn" と "hostname": "gir"。

  • 同じキーと値を持つ2つのキーと値のペアは、同じディメンションです。例えば、 "hostname": "host" と "hostname": "host" 。

インフラストラクチャで各メタデータ・タイプを使用するタイミング でのディメンションの使い方を参照してください。

ディメンション基準 🔗

MTSごとに最大36の一意のディメンションを定義できます。

ディメンション名の基準：

  • UTF-8文字列、最大長128文字（512バイト）。

  • 大文字または小文字で始まること。

  • アンダースコア(_)で始まってはならない。

  • After the first character, the name can contain letters, numbers, underscores (_), hyphens (-), and periods (.), but cannot contain blank spaces.

  • Must not start with the prefix sf_, except for dimensions defined by Splunk Observability Cloud such as sf_hires.

カスタムプロパティ 🔗

カスタムプロパティは、取り込み後に既存の MTS のディメンションに割り当てることができるキーと値のペアです。カスタムプロパティは単一値で、複数の値には対応していません。

例えば、カスタムプロパティ use: QA をメトリクスの host ディメンションに追加して、データを送信しているホストが QA に使用されていることを示すことができます。その後、カスタムプロパティ use: QA は、そのディメンションを持つすべての MTS に伝搬します。既存のメトリクス・ディメンションへのカスタムプロパティの追加の詳細については、メタデータ・カタログを検索する を参照してください。

When Splunk Observability Cloud assigns a different name to a dimension coming from an integration or monitor, the dimension also becomes a custom property as it is assigned to the metric after ingest. For example, the AWS EC2 integration sends the instance-id dimension, and Splunk Observability Cloud renames the dimension to aws_instance_id. This renamed dimension is a custom property.

For more information on how Splunk Observability Cloud uses custom properties to rename dimensions generated by monitoring software, see Guidance for metric and dimension names.

You can also apply custom properties to tags. When you do this, anything that has that tag inherits the properties associated with the tag. For example, if you associate the tier:web custom property with the apps-team tag, Splunk Observability Cloud attaches the tier:web custom property to any metric or dimension that has the apps-team tag.

カスタムプロパティ基準 🔗

ディメンションごとに最大75のカスタムプロパティを定義できます。

カスタムプロパティ名と値の基準：

  • 名前は、最大長 128文字 (512バイト) の UTF-8 文字列でなければなりません。ディメンション名として既に使用されているカスタムプロパティ名は避けてください。

  • 値は最大256文字（1024バイト）のUTF-8文字列でなければならない。

  • オプションの説明プロパティを使用すると、メトリクス、ディメンション、またはタグの詳細な説明を指定できます。説明には、最大1024 UTF-8 文字を使用できます。

In custom property values, Splunk Observability Cloud stores numbers as numeric strings.

Infrastructure Monitoringタグ 🔗

Infrastructure Monitoringでは、タグはディメンションおよびカスタムプロパティに割り当てるラベルまたはキーワードで、複数のディメンションに同じ検索可能な値を指定できます。カスタムプロパティとは異なり、タグはディメンションの sf_tags プロパティの下にあり、複数の値を持つことができます。

既存のメトリクスにタグを追加する方法については、メタデータ・カタログを検索する を参照してください。

タグの基準 🔗

タグはUTF-8文字列で、最大長はUTF-8文字で256文字/1024バイトです。

  • 1つのディメンションにつき、最大50個のタグを付けることができます。

  • カスタムプロパティ1つにつき、最大50個のタグを設定できます。

スパン属性またはタグ 🔗

タグは、タグとオブジェクトの多対一の関係や、タグとそれを適用するオブジェクトの一対多の関係が必要な場合に使用します。タグは、本質的に関連付けられていないメトリクスをグループ化するのに便利です。

OpenTelemetryの属性 🔗

OpenTelemetry データモデルでは、メタデータはスパン属性またはタグとして提供されます。コレクタのトレースパイプラインでアトリビュートプロセッサを使用して、属性を追加および変更できます。

詳しくは OpenTelemetry のタグ を参照してください。

Splunk APM の属性 🔗

Splunk APM では、スパンタグはインスツルメンテーションによってスパンに追加されるキーと値のペアで、スパンが表す操作に関する情報とコンテキストを提供します。

APMのスパンタグについて詳しくは、こちらを参照してください。

Splunk RUM の属性 🔗

RUMでグローバル属性を設定するには、以下を参照のこと：

インフラストラクチャで各メタデータ・タイプを使用するタイミング 🔗

次の表は、IMメタデータのタイプ間の主な違いを示しています。

メタデータ

作成

追加可能

フィルタ？

グループ別？

ディメンション

When Splunk Observability Cloud ingests data

メトリック時系列

はい

はい

カスタムプロパティ

インジェスト後、ユーザー・インターフェースまたはREST APIを通じて

ディメンションとタグ

はい

はい

タグ

インジェスト後、ユーザー・インターフェースまたはREST APIを通じて

ディメンションとカスタムプロパティ

はい

いいえ

Each type of metadata has its own function in Splunk Observability Cloud. The following sections discuss several considerations to help you choose the most appropriate type of metadata for your metrics.

ディメンションまたはカスタムプロパティを使用する 🔗

注釈

ディメンションとカスタムプロパティは、UI上では互いに区別できませんが、異なる方法で動作し、異なる目的を果たします。

ディメンションとカスタムプロパティは、どちらもメトリクスにコンテキストを追加するキーと値のペアであ り、メトリクスを効果的にグループ化および集計するツールを提供するという点で似ています。ディメンションとカスタムプロパティの主な違いは以下のとおりです。

  1. インジェスト時にディメンションを送信し、インジェスト後にカスタムプロパティを追加します。

  2. ディメンションに変更を加えることはできませんが、カスタムプロパティに変更を加えることはできます。

これらの違いにより、以下の状況でディメンションを使用します。

Example: Sending the same metric from multiple data centers 🔗

Suppose you send in a metric called cpu.utilization from two data centers. Within each data center, you have 10 servers with unique names represented by these key-value pairs: host:server1, host:server2,…, host:server10. However, your server names are only unique within a data center and not within your whole environment. You want to add more metadata for your data centers, dc:west and dc:east, to help with the distinction. In this case, you need send metadata about the hosts and the data centers as dimensions because you know before ingesting that you want a separate MTS for every host in your environment.

Example: Tracking and comparing historical values 🔗

Suppose you collect a metric called latency to measure the latency of requests made to your application. You already have a dimension for customers, but you also want to track the improvement between versions 1.0 and 2.0 of your application. In this case, you need to make version:1.0 and version:2.0 dimensions. If you make version:1.0 a custom property, then change it to version:2.0 when you release a new version of your application, you lose all the historical values for the latency MTS defined by version:1.0.

カスタムプロパティは次のような場合に使用します。

  • メトリクスに追加のコンテキストを提供するメタデータがあるが、そのメタデータによって別の一意に識別可能な MTS を作成したくない場合。

  • 将来的に変更を加えたいメタデータがある場合。

Example: Adding context without creating more MTS 🔗

Suppose you collect a metric called service.errors to know when your customers are running into issues with your services. The MTS for this metric are already uniquely identifiable by the customer and service dimensions. You want to attach the escalation contacts for each service for every customer to your metrics. In this case, you assign the escalation contacts as custom properties to the specific service dimension or customer dimensions. As your team grows and goes through reorganization, you want to be able to change this metadata. You also don’t need the escalation contacts as dimensions as the customer and service dimensions already yield separate MTS.

Infrastructure Monitoringタグの使用 🔗

Infrastructure Monitoringでは、タグとそれを割り当てるオブジェクトの間に一対多の関係がある場合にタグを使用します。

Example: Canary testing 🔗

Suppose you do canary testing in your environment. When you create a canary deployment, you can use the canary tag to mark the hosts that received the new code, so you can identify their metrics and compare their performance to those hosts that didn’t receive the new code. You don’t need a key-value pair as there’s only a single value, canary.

Example: Host running multiple applications 🔗

Suppose you have hosts that run multiple applications in your environment. To identify the apps that a particular host is running, create a tag for each app, then apply one or more of these tags to the host:<name> dimension to specify the apps that are running on each host.

This page was last updated on 2024年06月25日.