Docs » Splunk APMでスパンタグとMetricSetsを使ってサービスを分析する » APMのMetricSetsについて

APMのMetricSetsについて 🔗

MetricSetsは、Splunk APMでトレースとスパンから計算されるリクエスト率、エラー率、時間といった主要なパフォーマンス指標です。MetricSetsには2つのカテゴリがあります。高カーディナリティのトラブルシューティングに使用されるTroubleshooting MetricSets（TMS）と、リアルタイムの監視に使用されるMonitoring MetricSets（MMS）です。MetricSetsは、Splunk Infrastructure Monitoringでチャートへのデータ投入およびアラートの生成のために使用されるメトリック時系列（MTS）と似ています。詳細は メトリック時系列 を参照してください。MetricSetsは、Splunk APM固有のMTSです。

Troubleshooting MetricSets 🔗

Troubleshooting MetricSets（TMS）は、APMでカーディナリティの高いIDのトラブルシューティングに使用できるメトリック時系列（MTS）です。TMSは、スパンやワークフロー間の履歴比較を行うためにも使用できます。

Splunk APMは、デフォルトでいくつかのスパンタグをインデックス化しTroubleshooting MetricSetsを作成します。これらの各タグの詳細については、APMのデフォルトのインデックス付きスパンタグ を参照してください。APMによるこれらのスパンタグのインデックス化を変更したり停止したりすることはできません。

追加のスパンタグやプロセスをインデックス化することで、カスタムTMSを作成することもできます。スパンタグやプロセスをインデックス化して新しいTroubleshooting MetricSetsを作成する方法については、スパンタグをインデックス化してTroubleshooting MetricSetsを作成する を参照してください。

利用可能なTMSメトリクス 🔗

すべてのTMSは、以下のメトリクスを作成します。これは、リクエスト、エラーおよび時間（RED）メトリクスと呼ばれます。REDメトリクスは、サービスマップ内でサービスを選択すると表示されます。サービスマップ内でのREDメトリクスの使用方法の詳細については、シナリオ：KaiがSplunk APMのサービスマップを使用してエラーの根本原因を調査する を参照してください。

  • リクエスト率

  • エラー率

  • 根本原因エラー率

  • P50、P90、P99レイテンシ

Troubleshooting MetricSetsの測定精度は10秒です。Splunk APMは、各10秒のレポートウィンドウについて、メトリクスの分散から分位数をレポートします。

Splunk APM内でTMSを使用する 🔗

TMSは、サービスマップとTag Spotlightに表示されます。TMSを使用して、サービスマップをフィルタリングしたり、指定したインデックス済みのスパンタグまたはプロセスの値について内訳を作成したりできます。

サービスマップでサービス間の依存関係を表示する および Tag Spotlightを使用してサービスパフォーマンスを分析する を参照してください。

TMSの保存期間 🔗

Splunk Observability Cloudは、生のトレースと同じ期間にわたってTMSを保持します。デフォルトでは、保持期間は8日間です。

Troubleshooting MetricSetsの詳細については、スパンタグとTroubleshooting MetricSetsのリファレンスおよびベストプラクティス を参照してください。

Monitoring MetricSetsメトリックセットの監視 🔗

Monitoring MetricSets（MMS）は、チャートやダッシュボードといったSplunk APMでのリアルタイム監視機能を強化するメトリック時系列（MTS）です。MMSは、APMのリアルタイムのランディングページとダッシュボードビューに動力を供給します。またMMSは、アラートを生成するためにディテクターが監視するメトリクスでもあります。

MMSは、特定のエンドポイント、またはサービス内のすべてのエンドポイントの集合体に対して利用可能です。

エンドポイントレベルのMMSはサービス内の単一のエンドポイントのアクティビティを反映し、サービスレベルのMMSはサービス内のすべてのエンドポイントのアクティビティを集約します。MMSは、span.kind の値が SERVER または CONSUMER であるスパンのみに限定されます。

次のような場合、スパンは、kind の値がなかったり、kind の値が異なったりする可能性があります：

  • スパンの起点が、自己開始型の操作または推定サービスである場合

  • インストルメンテーションでエラーが発生した場合

以下のデフォルトのMMSに加えて、カスタムMMSを作成することができます。カスタムディメンションを使用してMonitoring MetricSetを生成する を参照してください。

利用可能なデフォルトのMMSのメトリクスとディメンション 🔗

MMSは以下のAPMコンポーネントで利用できます：

  • service.request

  • スパン

  • inferred.services

  • トレース

  • ワークフロー（ワークフローメトリクスは、ビジネスワークフローを作成するとデフォルトで作成されます。カスタムMMSは、ビジネスワークフローでは使用できません。）

各MMSは、各コンポーネントに対する6つのメトリクスを含みます。ヒストグラムMMSでは、各コンポーネントに対して1つのメトリクスがあります。使用したい特定のヒストグラムバケツにアクセスするには、ヒストグラム関数を使用します。

各メトリクスに対して、レスポンスが sf_error: true または sf_error: false のメトリック時系列（MTS）が1つ存在します。

説明

MMS

ヒストグラムMMS

リクエスト数

<component>.count

<component> （ count 関数を使用）

リクエスト時間の最小値

<component>.duration.ns.min

<component> （ min 関数を使用）

リクエスト時間の最大値

<component>.duration.ns.max

<component> （ max 関数を使用）

リクエスト時間の中央値

<component>.duration.ns.median

<component> （ median 関数を使用）

リクエスト時間のパーセンタイル

<component>.duration.ns.p90

<component> （ percentile 関数とパーセンタイル value を使用）

リクエスト時間のパーセンタイル

<component>.duration.ns.p99

<component> （ percentile 関数とパーセンタイル value を使用）

各MMSには、サービスパフォーマンスの監視とアラートに使用できるディメンションのセットがあります。

サービスディメンション 🔗

  • sf_environment

  • deployment.environment - このディメンションは、ヒストグラムMMSでのみ利用可能です。

  • sf_service

  • service.name - このディメンションは、ヒストグラムMMSでのみ利用可能です。

  • sf_error

推定サービスディメンション 🔗

  • sf_service

  • service.name - このディメンションは、ヒストグラムMMSでのみ利用可能です。

  • sf_environment

  • deployment.environment - このディメンションは、ヒストグラムMMSでのみ利用可能です。

  • sf_error

  • sf.kind

スパンディメンション 🔗

  • sf_environment

  • deployment.environment - このディメンションは、ヒストグラムMMSでのみ利用可能です。

  • sf_service

  • service.name - このディメンションは、ヒストグラムMMSでのみ利用可能です。

  • sf_operation

  • sf_kind

  • sf_error

  • sf_httpMethod （該当する場合）

トレースディメンション 🔗

注釈

トレースディメンションは、カスタムMMSではサポートされません。

  • sf_environment

  • deployment.environment - このディメンションは、ヒストグラムMMSでのみ利用可能です。

  • sf_service

  • service.name - このディメンションは、ヒストグラムMMSでのみ利用可能です。

  • sf_operation

  • sf_httpMethod

  • sf_error

ワークフローディメンション 🔗

ワークフローのメトリクスとディメンションは、ビジネスワークフローを作成するとデフォルトで作成されます。

注釈

ワークフローディメンションは、カスタムMMSではサポートされません。

  • sf_environment

  • deployment.environment - このディメンションは、ヒストグラムMMSでのみ利用可能です。

  • sf_workflow

  • sf_error

Splunk APM内でMMSを使用する 🔗

Splunk APM内でアラートとリアルタイム監視のためにMMSを使用します。Monitoring MetricSetsに基づいてチャート、ダッシュボード、アラートを作成できます。

タスク

ドキュメント

チャートの作成

Splunk Observability Cloudでチャートを作成する

ダッシュボードの作成

ダッシュボードの作成およびカスタマイズ

アラートの作成

Splunk APMでディテクターとアラートを設定する

APMダッシュボードでのサービスの監視

Splunk APMのダッシュボードを使用してサービスパフォーマンスを追跡する

MMSの保存期間 🔗

Splunk Observability Cloudは、MMSをデフォルトで13か月間保存します。

Monitoring MetricSetsとTroubleshooting MetricSetsの比較 🔗

エンドポイントレベルのMMSとサービスレベルのMMSにはTMSメトリクスのサブセットが含まれるため、Splunk APMでのコンテキストによってサービスのメトリクス値が異なることに気づくかもしれません。これは、MMSがダッシュボードビューのベースであり、MMSの kind には SERVER または CONSUMER しかないためです。対照的に、TMSはトラブルシューティングビューおよびTag Spotlightビューのベースであり、TMSは特定のメトリクスに限定されません。

例えば、ホストダッシュボードに表示される checkout サービスのメトリクスの値は、サービスマップに表示されるメトリクスの値と異なる場合があります。これは、このサービスに関連するスパンの kind の値が複数存在し、ダッシュボードを動かすMMSがそれを監視していないためです。

MMSとTMSを直接比較するには、特定のエンドポイントにフィルタリングすることでTMSをエンドポイントのみのデータに制限します。また、サービスマップをエンドポイントごと分解することもできます。

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