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バイト)。

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

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

  • 最初の文字以降には、名前にアルファベット、数字、アンダースコア(_)、ハイフン(-)、ピリオド(.)を含められますが、空白を含めることはできません。

  • 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上では互いに区別できませんが、異なる方法で動作し、異なる目的を果たします。

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

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

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

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

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

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

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

アプリケーションへのリクエストの待ち時間を測定するために、 latency というメトリクスを収集するとします。顧客用のディメンションはすでにありますが、アプリケーションのバージョン 1.0 と 2.0 の間の改善も追跡したいとします。この場合、version:1.0 および version:2.0 ディメンションを作成する必要があります。version:1.0 をカスタムプロパティにし、アプリケーションの新バージョンをリリースするときにそれを version:2.0 に変更すると、version:1.0 で定義された latency MTS の履歴値がすべて失われます。

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

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

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

例: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では、タグとそれを割り当てるオブジェクトの間に一対多の関係がある場合にタグを使用します。

例:カナリアテスト 🔗

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

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

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

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