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

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

名前	説明	データ型	フォーマット
ディメンション	メトリクスにコンテキストを追加するために、インジェスト時にメトリック時系列（MTS）とともに送信されます。メトリクス名とともに、MTS を一意に識別します。ディメンション名は時間の経過とともに変化しません。	インフラストラクチャ・メトリクス	キーと値のペア
カスタムプロパティ	インジェスト後にメトリクス・ディメンションに適用して、メトリクスにコンテキストを追加します。カスタムプロパティは、MTS を一意に識別することには寄与しません。	インフラストラクチャ・メトリクス	キーと値のペア
タグ	インジェスト後にメトリクス・ディメンションおよびカスタムプロパティに適用されるラベルまたはキーワード。タグを使用して、`sf_tags` を使用して、チャートやディテクターで MTS をフィルタリングできます。	インフラストラクチャ・メトリクス	文字列
属性またはスパンタグ	追跡中の操作に関する情報を伝える注釈。	APMメトリクス、コレクタ・メトリクス、スパン	キーと値のペア

メタデータの検索、編集、リンク 🔗

メタデータの検索、編集、リンクの方法については、以下のリソースを参照してください：

メタデータの検索と編集には、メタデータ・カタログをご利用ください。詳しくはメトリクス・ファインダーとメタデータ・カタログを検索するを参照してください。
メタデータを他のリソースにリンクするには、グローバル・データリンクを使用して、メタデータを関連リソースにリンクするを参照してください。
メトリクスにメタデータを追加するには、メトリクス・ファインダーとメタデータ・カタログを検索するを参照してください。APIを使用してメタデータを追加することもできます。その方法は、Splunk開発者向けドキュメントを参照してください。

データを活用するためのツールについては、以下を参照してください：

ディメンション 🔗

注意

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バイト）。
大文字または小文字で始まること。
アンダースコア(_)で始まってはならない。
最初の文字以降には、名前にアルファベット、数字、アンダースコア（_）、ハイフン（-）、ピリオド（.）を含められますが、空白を含めることはできません。
sf_ のようなSplunk Observability Cloudで定義されたディメンションを除き、プレフィックス sf_hires で始まってはなりません。

カスタムプロパティ 🔗

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

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

Splunk Observability Cloudがインテグレーションまたはモニタからのディメンションに別の名前を割り当てると、インジェスト後にそのディメンションがメトリクスに割り当てられるため、そのディメンションもカスタムプロパティになります。たとえば、AWS EC2インテグレーションは instance-id ディメンションを送信し、Splunk Observability Cloudはディメンションの名前を aws_instance_id に変更します。この名前を変更したディメンションはカスタムプロパティになります。

Splunk Observability Cloudがカスタムプロパティを使用して、モニタリングソフトウェアによって生成されたディメンションの名前を変更する方法の詳細については、メトリクス名とディメンション名のガイダンスを参照してください。

タグにカスタムプロパティを適用することもできます。これを実行すると、そのタグを持つものはすべて、タグに関連付けられたプロパティを継承します。例えば、tier:web カスタムプロパティを apps-team タグに関連付けると、Splunk Observability Cloudは tier:web タグを持つメトリクスまたはディメンションに apps-team カスタムプロパティを付けます。

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

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

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

名前は、最大長 128文字 (512バイト) の UTF-8 文字列でなければなりません。ディメンション名として既に使用されているカスタムプロパティ名は避けてください。
値は最大256文字（1024バイト）のUTF-8文字列でなければならない。
オプションの説明プロパティを使用すると、メトリクス、ディメンション、またはタグの詳細な説明を指定できます。説明には、最大1024 UTF-8 文字を使用できます。

カスタムプロパティ値では、Splunk Observability Cloudは数値を数値文字列として保存します。

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メタデータのタイプ間の主な違いを示しています。

メタデータ	作成	追加可能	フィルタ？	グループ別？
ディメンション	Splunk Observability Cloudがデータを取り込むとき	メトリック時系列	はい	はい
カスタムプロパティ	インジェスト後、ユーザー・インターフェースまたはREST APIを通じて	ディメンションとタグ	はい	はい
タグ	インジェスト後、ユーザー・インターフェースまたはREST APIを通じて	ディメンションとカスタムプロパティ	はい	いいえ

メタデータの各タイプは、Splunk Observability Cloudで独自の機能を持ちます。以下のセクションでは、メトリクスに最適なメタデータのタイプを選択するためのいくつかの考慮事項について説明します。

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

注釈

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

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

インジェスト時にディメンションを送信し、インジェスト後にカスタムプロパティを追加します。
ディメンションに変更を加えることはできませんが、カスタムプロパティに変更を加えることはできます。

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

一意のMTSを定義するためにメタデータが必要な場合。例：複数のデータセンターから同じメトリクスを送信するを参照してください。

メタデータの履歴値を記録したい場合。例：履歴値の追跡と比較を参照してください。

例：複数のデータセンターから同じメトリクスを送信する 🔗

2つのデータセンターから cpu.utilization というメトリクスを送信したとします。各データセンター内には、host:server1、host:server2、…、host:server10 というキーと値のペアで表される一意の名前を持つサーバーが10台あります。しかし、サーバー名はデータセンター内で一意であるだけで、環境全体で一意ではありません。dc:west と dc:east というデータセンターのメタデータを追加して、区別できるようにしたいと思っています。この場合、環境内の各ホストに個別のMTSが必要であることがインジェスト前に分かっているため、ホストとデータセンターに関するメタデータをディメンションとして送信する必要があります。

例：履歴値の追跡と比較 🔗

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 を作成したくない場合。

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

例：MTSを増やさずにコンテキストを追加する 🔗

service.errors と呼ばれるメトリクスを収集し、顧客がいつサービスで問題に遭遇しているかを知るとします。このメトリクスのMTSは、顧客およびサービスディメンションによって既に一意に識別可能です。各顧客の各サービスのエスカレーションコンタクトをメトリクスに添付したいとします。この場合、特定のサービスディメンションまたは顧客ディメンションに、カスタムプロパティとしてエスカレーション連絡先を割り当てます。チームが成長し、再編成が行われると、このメタデータを変更できるようにします。また、顧客ディメンションとサービスディメンションはすでに個別の MTS を生成しているため、ディメンションとしてのエスカレーション連絡先は必要ありません。

Infrastructure Monitoringタグの使用 🔗

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

例：カナリアテスト 🔗

自分の環境でカナリアテストを行うとします。カナリアデプロイを作成するとき、 canary タグを使って新しいコードを受け取ったホストをマークし、そのホストのメトリクスを特定して、新しいコードを受け取らなかったホストとパフォーマンスを比較することができます。値は canary だけなので、キーと値のペアは必要ありません。

例：複数のアプリケーションを実行するホスト 🔗

環境に複数のアプリケーションを実行するホストがあるとします。特定のホストが実行しているアプリを識別するには、アプリごとにタグを作成し、これらのタグを host:<name> ディメンションに1つ以上適用して、各ホストで実行しているアプリを指定します。

このページは 2024年06月25日に最終更新されました。

Related Topics