スパンタグとTroubleshooting MetricSetsのリファレンスおよびベストプラクティス 🔗
Troubleshooting MetricSets（TMS）を使用すると、インフラストラクチャのパフォーマンスに関するインサイトを取得したり、特定のインシデントに対処したりするためのドリルダウンが可能になります。
注釈
Splunk APMにおいて、Troubleshooting MetricSetsとMonitoring MetricSetsは異なります。APMのMetricSetsの種類の概要は、APMのMetricSetsについて を参照してください。
Splunk APMが自動的にインデックス化するスパンタグについては、APMのデフォルトのインデックス付きスパンタグ を参照してください。
インデックス化を選択できるスパンタグの種類とそのスコープについては、インデックス化できるスパンタグのタイプ を参照してください。
システム構成において使用可能なTroubleshooting MetricSetsの数の計算方法については、スパンタグのインデックス作成の制限 を参照してください。
インデックス化する追加のスパンタグの選択に関するガイダンスは、どのスパンタグを追加的にインデックス化するかの判断 を参照してください。
APMのデフォルトのインデックス付きスパンタグ 🔗
APMは、以下のテーブル内のスパンタグに対してデフォルトでインデックスを作成し、Troubleshooting MetricSetsを作成します：
タグ |
例 |
タイプ |
説明 |
|---|---|---|---|
|
|
グローバル |
スパンに関連付けられたサービスが実行される環境。 |
|
|
すべてのサービス |
ルートスパンが |
|
|
すべてのサービス |
サービスのルートスパンの操作名。 |
|
|
すべてのサービス |
該当するものがあれば、スパンのHTTPメソッド。実際のスパンタグのフィールド名は、 |
|
|
すべてのサービス |
スパンに関連付けられたサービスのタイプ。実際のスパンタグのフィールド名は |
|
インストルメンテーションを設定する際に指定するサービス名。 |
すべてのサービス |
インストルメントし、トレースデータのエクスポート元であるサービス。 |
インデックス化できるスパンタグのタイプ 🔗
インデックス化できるスパンタグのタイプは3つです：
タイプ |
例 |
説明 |
|---|---|---|
グローバル |
テナントクラス、アプリケーションID |
トレース全体で単一の値のみを持つタグ。これは、スパンタグの値をトレース全体に関連付けます。 |
すべてのサービス |
バージョン、ホスト、ステータスコード |
大部分のサービスまたはすべてのサービスのために存在するタグ。これは、スパンタグ値をトレース内のサービスと関連付けます。値はトレース内のサービス間で変わる可能性があります。 |
特定のサービス（1つまたは複数） |
ジョブID、データベース名 |
トレース内の単一のサービスのためにのみ存在するタグ。これは、スパンタグ値をトレース内の単一のサービスと関連付けます。 |
スパンタグにインデックスを付ける方法については、スパンタグをインデックス化してTroubleshooting MetricSetsを生成する を参照してください。
追加のスパンタグをインデックス化しないことを選択した場合でも、トレース全体を分析する際にスパン内のタグを表示することができます。また、トレースをダウンロードし、スパンタグによってデータを手動でフィルタリングしたり処理したりすることもできます。トレースのダウンロード方法については、トレースのダウンロード を参照してください。
スパンタグのインデックス作成の制限 🔗
APMは、インデックス化されたスパンタグの値のすべての一意なセットごとにTroubleshooting MetricSetsを生成するため、インデックス化できるスパンタグの数は、スパンタグが生成するTroubleshooting MetricSetsの数に依存します。これは、インデックス付きタグのカーディナリティ寄与度としても知られています。生成できるTroubleshooting MetricSetsの数はSplunk APMの契約で制限されている場合があるので、スパンタグをインデックス化する際にはこの制限のことを覚えておいてください。詳細については、Splunk APMの料金 を参照してください。
潜在的なTroubleshooting MetricSets数の判断 🔗
タグのインデックス化によって生成される可能性のあるTroubleshooting MetricSetsの総数を判断するには、サービス、エンドポイント、操作、および環境の値の各一意のセットに関連付けられた各インデックス付きタグのインデックス付きタグ値の数を乗算します。
例えば、frontend と checkoutservice という2つのサービスについて考えてみましょう。それぞれのサービスは2つのリージョンに存在しています。frontend サービスには5つのエンドポイントがあり、 checkoutservice には2つのエンドポイントがあります。region と endpoint は各サービスのインデックス付きタグです。このシナリオでは、他のインデックス付きタグはありません。
frontend の5つのエンドポイントに、一意なリージョンの数である2を掛け、checkoutservice の2つのエンドポイントに、一意なリージョンの数である2を掛けた結果を足すと、可能な組み合わせは最大14、という結果が得られます： (2 * 5) + (2 * 2) = 14。これは、常に14のTroubleshooting MetricSetsがあるということを意味するわけではありません。ある region 、またはある endpoint でトレースを収集した場合、Troubleshooting MetricSetは、その region または endpoint に対してのみ存在します。
次のテーブルは、これら2つのサービスと複数の値を持つ2つのインデックス付きタグがある場合に、考えられるTroubleshooting MetricSetsのサンプルセットを示しています：
# |
サービス |
リージョン |
エンドポイント |
|---|---|---|---|
1 |
|
|
|
2 |
|
|
|
3 |
|
|
|
4 |
|
|
|
5 |
|
|
|
6 |
|
|
|
7 |
|
|
|
8 |
|
|
|
9 |
|
|
|
10 |
|
|
|
11 |
|
|
|
12 |
|
|
|
13 |
|
|
|
14 |
|
|
|
どのスパンタグを追加的にインデックス化するかの判断 🔗
Troubleshooting MetricSetsを使い切らないようにするために、どのスパンタグが最もインデックス化する価値があるかを検討しましょう。以下は、どのスパンタグが最も有用かを判断するのに役立ついくつかの質問です：
インシデントが発生したときに見るべき属性はあるか？
Kubernetesを実行している場合、
k8s.pod.nameをインデックス化して、特定のKubernetesポッドによるサービスのパフォーマンスを見ることができます。複数のバージョンやビルドのコードを同時に実行することがあるか？
versionやbuild_idのタグにインデックスを付けることで、アプリケーションの特定のバージョンやビルドにしたがってインフラストラクチャを分解することができます。複数のリージョンや障害ドメインにサービスをデプロイすることがあるか？
サービスのメトリクスを特定の
regionスパンタグ別で表示して、特定のリージョンやゾーンにおけるリソースの問題を識別すると、有用です。複数の製品を監視するか？
特定の製品のサービスの実行状況を把握するためには、複数の製品タイプのトレースを同時に表示するのではなく、
product_categoryのようなスパンタグを使用して単一の製品タイプのトレースのメトリクスを表示することができます。どの程度のカーディナリティが必要か？
スパンタグの中には、実用的ではない可能性のあるカーディナリティレベルを提供するものがあります。例えば
query_idをインデックス化すると、すべての一意のクエリごとにTroubleshooting MetricSetsを生成する可能性がありますが、多くの場合、このレベルのカーディナリティは必要ありません。一時的なリソースを表すタグはあるか？
container_idのように一時的なリソースを表すスパンタグのインデックス化は、避けることが最適です。
インデックス化するスパンタグを選択したら、スパンタグをインデックス化してTroubleshooting MetricSetsを生成する でその方法を確認してください。
This page was last updated on 2023年03月17日.