メトリクスとディメンションの命名規則

Splunk Observability Cloud のメトリクスとディメンションの命名規則。

Splunk Observability Cloud のカスタムメトリクスとカスタムディメンションの命名規則と推奨事項については、このドキュメントをお読みください。

注: Splunk Observability Cloud が生成するすべてのメトリクスと MTS は、接頭辞 sf. または sf_metric で始まります。

Splunk Observability Cloudのデータの種類

Splunk Observability Cloud は、インポートされたデータまたは既存データだけでなく、カスタムデータでも動作します。

インポートデータ

Collectd エージェントや AWS CloudWatch 統合など、既存のデータ収集統合を使用する場合は、統合がメトリクス名、ディメンション名、およびイベント名を定義します。詳細については、「メトリクス名の標準」を参照してください。

Splunk Infrastructure Monitoring は、さまざまなソースから送られてくるメトリクスを簡単に見つけて作業できるように、仮想メトリクスと呼ばれる統一フォーマットでデータを取得し、変換し、返します。詳細については、「Splunk Infrastructure Monitoring の仮想メトリクス」を参照してください。

カスタムデータ

カスタムメトリクス、ディメンション、またはイベント (リリースなどの特定のイベントをマークするために送信するキーと値のペア) を Splunk Infrastructure Monitoring に送信する場合、独自の名前を選択できます。

カスタムデータをSplunk Observability Cloudに送信する

API を使用して Splunk Observability Cloud でカスタムメトリクスを送信する方法については、「開発者ポータル」を参照してください。

OpenTelemetry Collector を使用している場合は、レシーバを作成して Splunk Observability Cloud にカスタムメトリクスを送信できます。

送信した命名スキームを他のメトリクスに変更する

以前に Graphite などの他のメトリクスシステムに送信したメトリクスを使用している場合は、Splunk Observability Cloud の全機能セットを活用するために命名スキームを変更します。

メトリクス名称規格

メトリクスとは、システムインフラ、アプリケーション機器、その他のハードウェアやソフトウェアによって生成される明確な数値測定値であり、時間とともに変化します。例:

  • 受信したGETリクエスト数

  • 総メモリ使用率

  • ネットワークの応答時間(ミリ秒)

メトリクスの詳細については、「Splunk Observability Cloud のメトリクス、データポイント、メトリクス時系列」を参照してください。

説明的な名前を使う

メトリクス名には最大 256 文字を使用できます。それ以上の値の場合、メトリックは削除される可能性があります。

メトリクスが何に関連しているかを識別するのに役立つ名前を使用します。

メトリクス情報

測定説明

cpu.temperature

測定単位

degreesC

メトリクスカテゴリ

temperature

送信する前にメトリクスに計算を適用する場合は、説明の一部として計算を使用します。たとえば、95 パーセンタイルの測定値を計算し、その結果をメトリクスで送信する場合、メトリクス名の一部として p95 を使用します。

一方、測定されるハードウェアやソフトウェアの説明など、メトリクス名ではなくディメンションに適した情報もあります。たとえば、測定が特定のホストに関するものであることを示すために production1 を使用しないでください。詳細については、「ディメンションに適した情報の種類」を参照してください。

メトリクス名を使用してメトリクスタイプを示す

名前を使用してさまざまなメトリクスタイプを示すには、次のベストプラクティスに従ってください。

  • それぞれのメトリクスに名前をつけます。

  • 独自のメトリクスを定義する場合は、メトリクスタイプの参照を含む名前を各メトリクスに付けます。

  • ディメンションを含むカスタムメトリクス名を割り当てることは避けてください。たとえば、100 個のサーバーまたはインスタンスがあり、それぞれのディスク書き込み数を追跡するカスタムメトリクスを作成する場合は、ディメンションでインスタンスを区別します。

階層構造を使用してメトリクス名を作成する

最も高いレベルから始め、次に進むにつれて具体的な値を追加していきます。

この例では、これらのメトリクスのすべてに hostname というディメンションキーがあり、analytics-1、analytics-2 などの値が設定されています。これらのメトリクスには、org-x、org-y などの値を持つユーザーディメンションキーもあります。ディメンションは、分析サービスの使用状況について、インフラストラクチャまたはユーザーに焦点を合わせたビューを提供します。ゲージメトリクスの詳細については、「メトリクスタイプを識別する」を参照してください。

  1. 分析やウェブなど、メトリクスが属するドメインまたはネームスペースから始めます。

  2. 次に、ジョブやhttpなど、メトリクスが測定するエンティティを追加します。

  3. あなたの判断で、エラーなどの中間的な名前を追加してください。

  4. 最後に測定単位を指定します。たとえば、SignalFlow 分析サービスは、以下のメトリクスをレポートします。

    • analytics.jobs.total:現在の実行ジョブ数を定期的に測定するゲージメトリクス

    • analytics.thrift.execute.count:新しいジョブが始まるたびにインクリメントされるカウンタメトリクス

    • analytics.thrift.execute.time:ジョブの実行要求を処理するのに必要な時間を測定するゲージメトリクス

    • analytics.jobs_by_state:stateと呼ばれるディメンションキーを持つカウンターメトリクスで、ジョブが特定の状態に到達するたびにインクリメントされます。

ディメンション名と値の標準

ディメンションは、メトリクスに関連付ける任意のキーと値のペアです。メトリクスは測定基準を区別しますが、ディメンションは測定の生成や測定の特徴付けを行うシステムの特定の要素を区別します。ディメンションを使用すると、次のことができます。

  • あるメトリクスについて、異なるデータストリームのポイントを分類します。

  • フィルタリングと集計を簡素化します。たとえば、SignalFlow では、1 つまたは複数のディメンションでデータストリームをフィルタリングおよび集計できます。

ディメンションは、数字または数字以外にすることができます。ホスト名や値などの一部のディメンションは、モニタリングしているシステムから取得されます。また、独自のディメンションを作成することもできます。

ディメンションキーと値の要件

ディメンションキー名は UTF-8 文字列で、最大長は 128 文字 (512 バイト) です。

  • 例えば、ディメンションのキーと値のペアが「mydim」と「myvalue」である場合、「mydim」は 128 文字に制限されます。

  • 大文字または小文字で始まること。名前の残りの部分には、文字、数字、アンダースコア(_)、ハイフン(-)、ピリオド(.)を含められますが、空白を含めることはできません。

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

  • sf_ のようなSplunk Observability Cloudで定義されたディメンションを除き、プレフィックス sf_hires で始まってはなりません。

ディメンション値は UTF-8 文字列で、最大長は 256 UTF-8 文字 (1024 バイト) です。

  • 例えば、ディメンションのキーと値のペアが「mydim」と「myvalue」である場合、「myvalue」は 256 文字に制限されます。

  • それ以上の値の場合、データポイントは削除されます。

  • 数字は数値文字列として表現されます。

MTS ごとに最大 36 の一意のディメンションを定義できます。この制限を超えると、データポイントは削除され、メッセージが記録されます。

読みやすさを確保するため、名前と値は40文字以内にしてください。

例:

  • "hostname": "production1"

  • "region": "emea"

組織におけるメトリクス名とディメンション名に関する考慮事項

組織の名称に一貫性を持たせます。

  • メトリクス名には一貫した単一のデリミタを使用します。メトリクス名に一貫した単一のデリミタを使用すると、ワイルドカードでの検索に役立ちます。区切り文字としてピリオドまたはアンダースコアを使用します。コロンやスラッシュは使用しないでください。

  • メトリクス名とディメンション名は変更しないでください。名前を変更する場合は、古い名前を使用するチャートとディテクタを更新する必要があります。Infrastructure Monitoring は、これを自動的に行いません。

  • メトリクスやディメンションを使用するのは自分だけではないため、識別しやすく理解しやすい名前を使用してください。確立された規則に従います。組織内の規則を確認するには、メトリクスファインダーを使用してメトリクスを参照します。

低カーディナリティと高カーディナリティのデータを扱うためのガイドライン

メトリクス名またはディメンションキー名でのみ低カーディナリティデータを送信します。低カーディナリティデータには、少数の異なる値が含まれます。たとえば、HTTP リクエストエラーの数を報告するゲージメトリクスのメトリクス名 web.http.error.countの値は単一です。この名前は読みやすく、説明も不要です。ゲージメトリクスの詳細については、「メトリクスタイプを識別する」を参照してください。

高カーディナリティデータには、数多くの固有の値が存在します。たとえば、タイムスタンプは高カーディナリティデータです。ディメンション値では、この種の高カーディナリティデータのみを送信します。高カーディナリティデータをメトリクス名で送信すると、Infrastructure Monitoring にデータが取り込まれない場合があります。Infrastructure Monitoring は、タイムスタンプを含む名前のメトリクスを拒否します。高カーディナリティデータは、適切な用途に使用してください。たとえば、コンテナ化された環境では、container_idは通常、高カーディナリティフィールドです。system.cpu.utilization.<container_id> などのメトリクス名に container_id を含めると、MTS が 1 つではなく、コンテナと同じ数になります。

メトリクスまたはディメンションを使用するタイミング

異なるメトリクスタイプを追跡する場合にメトリクスを使用する

Infrastructure Monitoring では、すべてのメトリクスが特定のメトリクスタイプに属し、特定のデフォルトロールアップを持ちます。メトリクスタイプの詳細については、「メトリクスタイプ」を参照してください。

2つの異なるメトリクスタイプを使用して測定可能な値を追跡するには、2つのディメンションを持つ1つのメトリクスではなく、2つのメトリクスを使用します。

たとえば、network_latency の測定があり、ゲージメトリクス(ミリ秒単位の平均ネットワーク遅延時間)とカウンタメトリクス(ある間隔で送信された遅延値の合計数)の 2 つの異なるメトリクスタイプとして送信したいとします。この場合は、2 つのディメンション type:averagetype:count を含む 1 つのメトリクス名ではなく、network_latency.averagenetwork_latency.count などの 2 つの異なるメトリクス名を使用して測定値を送信します。

ディメンションに適した情報の種類

ディメンションに追加できる情報の種類の例を参照してください。

  • 測定値ではなくカテゴリ:ディメンション値に対して算術演算を行った結果、有意なものが得られる場合、ディメンションには適していません。

  • フィルタリング、グループ化、集計のためのメタデータ。

  • 測定対象のエンティティ名:例: hostnameproduction1.

  • 可能な値の数が多いメタデータ:1 つのディメンションキーを多数の異なるディメンション値に使用します。

  • 数値以外の値:数値ディメンション値は、通常は測定値ではなくラベルです。

例:HTTPエラーを測定するためのカスタムメトリクスとディメンション

HTTP エラーを監視するために以下のデータを追跡したいとします。

  • エラー数

  • 各エラーのHTTPレスポンスコード

  • エラーを報告したホスト

  • エラーを返したサービス(アプリ

メトリクス名とディメンションではなく、長いメトリクス名を使用してデータを識別するとします。たとえば、web.http.myhost.checkout.error.500.count は、サービスチェックアウトに対して myhost というホストから報告された HTTP レスポンスコード 500 エラーの数を表す長いメトリクス名です。

web.http.myhost.checkout.error.500.count を使用している場合、以下の問題が発生する可能性があります。

  • このデータを Splunk Infrastructure Monitoring チャートで可視化するには、構文 web.http.*.*.error.*.count でワイルドカードクエリを実行する必要があります。

  • ホスト別、サービス別、エラータイプ別にエラーをまとめるには、クエリを変更する必要があります。

  • チャートではフィルタやダッシュボード変数は使用できません。

  • HTTP 400エラー、他のホストから報告されたエラー、他のサービスから報告されたエラーを追跡するには、別のメトリクス名を定義しなければなりません。

その代わりに、同じデータを追跡するためにディメンションを使用します。

  1. 必要な測定値を記述するメトリクス名を定義します。HTTP エラーの数は web.http.error.count です。メトリクス名には、次のものが含まれます。

    • web:ウェブ計測のためのメトリクスファミリーの名前

    • http.error:測定するプロトコルの名前(http)とプロトコルの要素(error)

    • count:測定単位

  2. エラーを分類するディメンションを定義します。ディメンションには次のものが含まれます。

    • host:エラーを報告したホスト

    • service:エラーを返したサービス

    • error_type:エラーのHTTPレスポンスコード

このように、チャートを使用してエラーデータを可視化するためには、「error count」を検索して名前でメトリクスを探します。チャートを作成する際に、受信メトリクス時系列をホスト、サービス、error_type、または 3 つすべてでフィルタリングして集計することができます。ダッシュボードフィルタを追加して、チャート自体を用意せずに、特定のダッシュボードにチャートを表示することができます。