メトリクスとディメンションの命名規則 🔗
Splunk Observability Cloud のカスタムメトリクスとカスタムディメンションの命名規則と推奨事項については、このドキュメントをお読みください。
注釈
Splunk Observability Cloud が生成するすべてのメトリクスと MTS は、接頭辞 sf. または sf_metric で始まります。
Types of data in Splunk Observability Cloud 🔗
Splunk Observability Cloud は、インポートまたは 既存データ だけでなく、カスタムデータ でも動作します。
インポートデータ 🔗
Collectdエージェントや AWS CloudWatch インテグレーションなど、既存のデータ収集インテグレーションを使用する場合は、インテグレーションがメトリクス名、ディメンション名、およびイベント名を定義します。詳細については、メトリクス名の標準 を参照してください。
Splunk Infrastructure Monitoring は、さまざまなソースから送られてくるメトリクスを簡単に見つけて作業できるように、仮想メトリクスと呼ばれる統一フォーマットでデータを取得、変換、返します。詳しくは Splunk Infrastructure Monitoring の仮想メトリクス を参照してください。
カスタムデータ 🔗
カスタムメトリクス、ディメンション、またはイベント (リリースなどの特定のイベントをマークするために送信するキーと値のペア) を Splunk Infrastructure Monitoring に送信する場合、独自の名前を選択できます。
Send custom data to Splunk Observability Cloud 🔗
To learn how to send custom metrics in Splunk Observability Cloud using our API, see the developer portal .
OpenTelemetry Collector を使用している場合は、カスタムメトリクスを Splunk Observability Cloud に送信する にレシーバを作成できます。
送信した命名スキームを他のメトリクスに変更する 🔗
以前に Graphite などの他のメトリクスシステムに送信したメトリクスを使用している場合は、Splunk Observability Cloud の全機能セットを活用するために命名スキームを変更します。
メトリクス名称規格 🔗
メトリクスとは、システムインフラ、アプリケーション機器、その他のハードウェアやソフトウェアによって生成される明確な数値測定値であり、時間とともに変化します。例えば
受信したGETリクエスト数
総メモリ使用率
ネットワークの応答時間(ミリ秒)
メトリクスについて、詳しくは Splunk Observability Cloudのメトリクス、データポイント、メトリック時系列 を参照してください。
説明的な名前を使う 🔗
メトリクス名は 256 文字まで使用できます。これより長い値を指定すると、そのメトリクスはドロップされる可能性があります。
メトリクスが何に関連しているかを識別するのに役立つ名前を使用します。
メトリクス情報 |
例 |
|---|---|
測定説明 |
|
測定単位 |
|
メトリクスカテゴリ |
|
送信する前にメトリクスに計算を適用する場合は、説明の一部として計算を使用します。たとえば、測定値の95パーセンタイルを計算し、その結果をメトリクスで送信する場合は、メトリクス名の一部として p95 を使用します。
一方、測定されるハードウェアやソフトウェアの説明など、メトリクス名ではなくディメンションに適した情報もあります。たとえば、測定が特定のホストに対するものであることを示すために、production1 を使用しないでください。詳細については、ディメンションに適した情報の種類 を参照してください。
メトリクス名を使用してメトリクスタイプを示す 🔗
以下のベスト・プラクティスに従って、メトリクスタイプの違いを示す名称を使用する ：
それぞれのメトリクスに名前をつけます。
独自のメトリクスを定義する場合は、メトリクスタイプの参照を含む名前を各メトリクスに付けます。
ディメンションを含むカスタム メトリクス名を割り当てないようにします。たとえば、100 個のサーバ/ インスタンスがあり、それぞれのディスク書き込み数を追跡するカスタム メトリクスを作成する場合は、ディメンションでインスタンスを区別します。
階層構造を使用してメトリクス名を作成する 🔗
最も高いレベルから始め、次に進むにつれて具体的な値を追加していきます。
この例では、これらのメトリクスはすべて、analytics-1、analytics-2 などの値を持つ、hostname というディメンションキーを持ちます。これらのメトリクスは、org-x、org-y などの値を持つ Customer ディメンションキーも持っています。このディメンションは、分析サービスの使用状況について、インフラストラクチャに重点を置いたビュー、または顧客に重点を置いたビューを提供します。ゲージメトリクスの詳細については、メトリクスタイプの識別 を参照してください。
分析やウェブなど、メトリクスが属するドメインまたはネームスペースから始めます。
次に、ジョブやhttpなど、メトリクスが測定するエンティティを追加します。
あなたの判断で、エラーなどの中間的な名前を追加してください。
最後に測定単位を指定します。例えば、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」 は 256 文字に制限されます。
Must start with an uppercase or lowercase letter. The rest of the name can contain letters, numbers, underscores (_) and hyphens (-), and periods (.), but cannot contain blank spaces.
アンダースコア文字(_)で始まってはならない。
Must not start with the prefix
sf_, except for dimensions defined by Splunk Observability Cloud such assf_hires.
ディメンション値は UTF-8 文字列で、最大長は 256 UTF-8 文字 (1024 バイト) です。
例えば、ディメンションのキーと値のペアが (「mydim」、」myvalue」) の場合、」myvalue」 は 256 文字に制限されます。
それ以上の値の場合、データポイントは削除されます。
数字は数値文字列として表現されます。
1つのMTSにつき最大36ディメンションを設定できます。この制限を超えると、データポイントは削除され、メッセージが記録されます。
読みやすさを確保するため、名前と値は40文字以内にしてください。
例：
"hostname": "production1""region": "emea"
組織におけるメトリクス名とディメンション名に関する考慮事項 🔗
組織の名称に一貫性を持たせます。
メトリクス名には、一貫性のある単一のデリミタを使用します。メトリクス名に一貫性のある単一のデリミタを使用すると、ワイルドカードを使用した検索に役立ちます。ピリオドまたはアンダースコアを区切り文字として使用します。コロンやスラッシュは使用しないでください。
メトリクス名とディメンション名の変更は避けてください。名前を変更すると、古い名前を使用しているチャートとディテクターを更新する必要があります。Infrastructure Monitoringはこれを自動的に行いません。
そのメトリクスやディメンションを使用しているのはあなただけではありませんから、識別しやすく理解しやすい名称を使用してください。確立された慣例に従ってください。組織内の規約を確認するには、メトリクス・ファインダー を使用してメトリクスを参照します。
低カーディナリティと高カーディナリティのデータを扱うためのガイドライン 🔗
カーディナリティの低いデータは、メトリクス名またはディメンションキー名でのみ送信します。低基数性データには、少数の明確な値があります。例えば、HTTP 要求エラーの数をレポートするゲージメトリクスのメトリクス名 web.http.error.count の値は 1 つです。この名前も読みやすく、自明です。ゲージメトリクスの詳細については、メトリクスタイプの識別 を参照してください。
High-cardinality data has a large number of distinct values. For example, timestamps are high-cardinality data. Only send this kind of high-cardinality data in dimension values. If you send high-cardinality data in metric names, Infrastructure Monitoring might not ingest the data. Infrastructure Monitoring rejects metrics with names that contain timestamps. High-cardinality data does have legitimate uses. For example, in containerized environments, container_id is usually a high-cardinality field. If you include container_id in a metric name such as system.cpu.utilization.<container_id>, instead of having one MTS, you have as many MTS as you have containers.
メトリクスまたはディメンションを使用するタイミング 🔗
異なるメトリクスタイプを追跡する場合にメトリクスを使用する 🔗
Infrastructure Monitoringでは、すべてのメトリクスが特定のメトリクスタイプに属し、特定のデフォ ルト・ロールアップを持ちます。メトリクスタイプの詳細については、メトリクスタイプ を参照してください。
2つの異なるメトリクスタイプを使用して測定可能な値を追跡するには、2つのディメンションを持つ1つのメトリクスではなく、2つのメトリクスを使用します。
For example, suppose you have a network_latency measurement that you want to send as two different metric types: a gauge metric (the average network latency in milliseconds) and a counter metric (the total number of latency values sent in an interval). In this case, send the measurement using two different metric names, such as network_latency.average and network_latency.count, instead of one metric name with two dimensions type:average and type:count.
ディメンションに適した情報の種類 🔗
ディメンションに追加できる情報の種類の例を参照してください。
測定値ではなくカテゴリ：ディメンション値に対して算術演算を行った結果、意味のあるものが得られる場合、ディメンションはありません。
フィルタリング、グループ化、集計のためのメタデータ。
測定対象のエンティティ名：例：
hostname、production1.可能な値の数が多いメタデータ：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エラー、他のホストから報告されたエラー、他のサービスから報告されたエラーを追跡するには、別のメトリクス名を定義しなければなりません。
その代わりに、同じデータを追跡するためにディメンションを使用します。
必要な測定値を記述するメトリクス名を定義します。HTTPエラーの数は、
web.http.error.count。メトリクス名には、以下が含まれます。web：ウェブ計測のためのメトリクスファミリーの名前http.error：測定するプロトコルの名前（http）とプロトコルの側面（エラー）count：測定単位
エラーを分類するディメンションを定義します。ディメンションには以下が含まれます。
host：エラーを報告したホストservice：エラーを返したサービスerror_type：エラーのHTTPレスポンスコード
このようにして、チャートを使用してエラー・データを視覚化するには、「error count」で検索してメトリクス名を特定します。チャートを作成する際、ホスト、サービス、error_type、またはこれら3つすべてによって、受信メトリック時系列をフィルタリングおよび集約できます。ダッシュボード・フィルタを追加して、特定のダッシュボードでチャートを表示するときに、チャート自体を表示しないようにできます。