Docs » Splunk APMでスパンタグとMetricSetsを使ってサービスを分析する » スパンタグとTroubleshooting MetricSetsのリファレンスおよびベストプラクティス

スパンタグとTroubleshooting MetricSetsのリファレンスおよびベストプラクティス 🔗

Troubleshooting MetricSets（TMS）を使用すると、インフラストラクチャのパフォーマンスに関するインサイトを取得したり、特定のインシデントに対処したりするためのドリルダウンが可能になります。

注釈

Splunk APMにおいて、Troubleshooting MetricSetsとMonitoring MetricSetsは異なります。APMのMetricSetsの種類の概要は、APMのMetricSetsについて を参照してください。

APMのデフォルトのインデックス付きスパンタグ 🔗

APMは、以下のテーブル内のスパンタグに対してデフォルトでインデックスを作成し、Troubleshooting MetricSetsを作成します：

タグ

例

タイプ

説明

environment

production、lab

グローバル

スパンに関連付けられたサービスが実行される環境。

Endpoint

/auth/valid、/checkout/{cartId}

すべてのサービス

ルートスパンが span.kind = server タグを含む場合、サービスのルートスパンの操作名。

Operation

/auth/valid、/checkout/{cartId}

すべてのサービス

サービスのルートスパンの操作名。

HTTP Method

GET、POST、PUT

すべてのサービス

該当するものがあれば、スパンのHTTPメソッド。実際のスパンタグのフィールド名は、http.method または requestMethod になる可能性がありますが、HTTP Method は、サービスをフィルタリングおよび分解するために使用するタグです。

Kind

server、client、producer

すべてのサービス

スパンに関連付けられたサービスのタイプ。実際のスパンタグのフィールド名は span.kind ですが、Kind は、サービスのフィルタリングおよび分解に使用するタグです。

Service

インストルメンテーションを設定する際に指定するサービス名。

すべてのサービス

インストルメントし、トレースデータのエクスポート元であるサービス。

インデックス化できるスパンタグのタイプ 🔗

インデックス化できるスパンタグのタイプは3つです：

タイプ

例

説明

グローバル

テナントクラス、アプリケーションID

トレース全体で単一の値のみを持つタグ。これは、スパンタグの値をトレース全体に関連付けます。

すべてのサービス

バージョン、ホスト、ステータスコード

大部分のサービスまたはすべてのサービスのために存在するタグ。これは、スパンタグ値をトレース内のサービスと関連付けます。値はトレース内のサービス間で変わる可能性があります。

特定のサービス（1つまたは複数）

ジョブID、データベース名

トレース内の単一のサービスのためにのみ存在するタグ。これは、スパンタグ値をトレース内の単一のサービスと関連付けます。

スパンタグにインデックスを付ける方法については、Index span tags to create Troubleshooting MetricSets を参照してください。

追加のスパンタグをインデックス化しないことを選択した場合でも、トレース全体を分析する際にスパン内のタグを表示することができます。また、トレースをダウンロードし、スパンタグによってデータを手動でフィルタリングしたり処理したりすることもできます。トレースのダウンロード方法については、トレースのダウンロード を参照してください。

スパンタグのインデックス作成の制限 🔗

APM generates a Troubleshooting MetricSet for every unique set of indexed span tag values, so the number of span tags you can index depends on the number of Troubleshooting MetricSets that the span tags generate. This is also known as the cardinality contribution of indexed tags. The number of Troubleshooting MetricSets you can generate might be limited in your Splunk APM contract, so keep this limit in mind when you’re indexing span tags. For more information, see Splunk APM Pricing .

潜在的なTroubleshooting MetricSets数の判断 🔗

タグのインデックス化によって生成される可能性のあるTroubleshooting MetricSetsの総数を判断するには、サービス、エンドポイント、操作、および環境の値の各一意のセットに関連付けられた各インデックス付きタグのインデックス付きタグ値の数を乗算します。

例えば、frontend と checkoutservice という2つのサービスについて考えてみましょう。それぞれのサービスは2つのリージョンに存在しています。frontend サービスには5つのエンドポイントがあり、 checkoutservice には2つのエンドポイントがあります。region と endpoint は各サービスのインデックス付きタグです。このシナリオでは、他のインデックス付きタグはありません。

Multiplying the five endpoints for frontend by two, the number of unique regions, and then adding the result of multiplying the two endpoints for checkoutservice by two for the unique regions, we get a maximum of 14 possible combinations: (2 * 5) + (2 * 2) = 14. This doesn’t always mean there will be 14 Troubleshooting MetricSets. If you collect traces in a certain region or with a certain endpoint, the Troubleshooting MetricSet exists only for that region or endpoint.

次のテーブルは、これら2つのサービスと複数の値を持つ2つのインデックス付きタグがある場合に、考えられるTroubleshooting MetricSetsのサンプルセットを示しています：

#

サービス

リージョン

エンドポイント

1

frontend

west

/currency

2

frontend

west

/cart

3

frontend

west

/checkout

4

frontend

west

/shipping

5

frontend

west

/product

6

frontend

east

/currency

7

frontend

east

/cart

8

frontend

east

/checkout

9

frontend

east

/shipping

10

frontend

east

/product

11

checkoutservice

west

/placeholder

12

checkoutservice

west

/queueplaceholder

13

checkoutservice

east

/placeholder

14

checkoutservice

east

/queueplaceholder

どのスパンタグを追加的にインデックス化するかの判断 🔗

Troubleshooting MetricSetsを使い切らないようにするために、どのスパンタグが最もインデックス化する価値があるかを検討しましょう。以下は、どのスパンタグが最も有用かを判断するのに役立ついくつかの質問です：

  • インシデントが発生したときに見るべき属性はあるか？

    Kubernetesを実行している場合、k8s.pod.name をインデックス化して、特定のKubernetesポッドによるサービスのパフォーマンスを見ることができます。

  • 複数のバージョンやビルドのコードを同時に実行することがあるか？

    version や build_id のタグにインデックスを付けることで、アプリケーションの特定のバージョンやビルドにしたがってインフラストラクチャを分解することができます。

  • 複数のリージョンや障害ドメインにサービスをデプロイすることがあるか？

    サービスのメトリクスを特定の region スパンタグ別で表示して、特定のリージョンやゾーンにおけるリソースの問題を識別すると、有用です。

  • 複数の製品を監視するか？

    特定の製品のサービスの実行状況を把握するためには、複数の製品タイプのトレースを同時に表示するのではなく、product_category のようなスパンタグを使用して単一の製品タイプのトレースのメトリクスを表示することができます。

  • どの程度のカーディナリティが必要か？

    スパンタグの中には、実用的ではない可能性のあるカーディナリティレベルを提供するものがあります。例えば query_id をインデックス化すると、すべての一意のクエリごとにTroubleshooting MetricSetsを生成する可能性がありますが、多くの場合、このレベルのカーディナリティは必要ありません。

  • 一時的なリソースを表すタグはあるか？

    container_id のように一時的なリソースを表すスパンタグのインデックス化は、避けることが最適です。

インデックス化するスパンタグを選択したら、Index span tags to create Troubleshooting MetricSets でその方法を確認してください。

このページは 2023年03月17日 に最終更新されました。