推定サービスのパフォーマンスを分析する 🔗

場合によっては、リモートサービスがまだインストルメントされていなかったり、インストルメンテーションが不可能だったりするために、そのトレースが有効になっていないことがあります。Splunk APMは、リモートサービスを呼び出すスパンが必要な情報を持っていれば、リモートサービスまたは推定サービスの存在を推測することができます。

Splunk APMは、推定サービス内で発生している操作を表すために、関連するトレースに推定スパンを追加します。Splunk APMがサービスを推定する方法の詳細については、Splunk APMは推定サービスをどのように識別するのか？を参照してください。

次の表は、一般的な推定サービスのタイプについて説明したものです：

タイプ	例	備考
汎用サービス（サービスマップ内の点線の円）	AWSサービス	このサービスタイプには、外部サービスプロバイダー、汎用リモートプロシージャコール（RPC）、HTTPサービスが含まれます。各タイプの詳細については、以下のセクションを参照してください：推定HTTPサービス推定リモートプロシージャコール（RPC）サービス推定汎用サービスシステムが多数のHTTPサービスとやりとりする場合、HTTPサービスを推定することで、Troubleshooting MetricSets（TMS）のカーディナリティが増加する可能性があります。その場合、過剰なカーディナリティを防ぐために、組織でHTTPサービスの推定を無効にすることができます。詳しくは HTTPサービスの推定を管理するを参照してください。
パブリッシャー/サブスクライバーキュー（pub/sub）（サービスマップ内の点線の矢印）	Kafka、Kinesis	pub/subキューの推定の詳細は、推定パブリッシャー/サブスクライバー（pub/sub）キューを参照してください。
データベース（サービスマップ内の点線の円柱）	MySQL、AWS S3、Redis、MongoDB	推定サービスについて利用可能な情報は？で説明する詳細に加えて、Splunk APMは推定されたSQLデータベースに対して追加の分析を提供します。Splunk APMのデータベースインサイトの詳細については、Database Query Performanceの監視を参照してください。

推定サービスについて利用可能な情報は？ 🔗

推定サービスはインストルメントされていないため、Splunk APMは、推定サービスを呼び出すインストルメント済みサービスからのスパンにしかアクセスできません。Splunk APMは推定サービスをサービスマップ内の推定された場所に配置し、関連するクライアント側のスパンに基づいて、Troubleshooting MetricSets （TMS）、またはリクエスト、エラーおよび時間（RED）メトリクスを提供します。これらのメトリクスを使用して、Tag Spotlight でトラブルシューティングを続けることができます。推定サービスが他の未インストルメントのサービスにサービスを提供している場合、これらのレポートされるREDメトリクスでは、推定サービスのインタラクションの全体像を把握できないことがあります。

サービスマップ内での推定サービスの表示 🔗

推定サービス、pub/sub、およびデータベースは、サービスマップ内の推定された場所に表示されます。サービスマップで推定サービスを選択すると、そのサービスタイプ、サービス名、およびリクエスト、エラーおよびレイテンシ（RED）メトリクスを表示できます。メトリクスは、インストルメントされたサービスからの参照スパンに基づいており、推定サービスのインタラクションの全体像を提供しない場合があります。

トレースビュー内での推定サービスの表示 🔗

推定サービス、pub/sub、およびデータベースは、トレースウォーターフォールビューでもスパンとして表示されます。以下のスクリーンショットのように、グレーのボックスにイタリック体で表示されます：

このスクリーンショットは、トレースビューに表示される推定スパンの例を示しています。

トレースウォーターフォールで推定スパンを選択すると、対応する親スパンのメタデータが表示されます。ウォーターフォール視覚エフェクトでグレーのストライプのバーとして表示される操作の長さも、親スパンから継承されたものであり、推定サービスでの操作時間を正確に表していない可能性があります。

Monitoring MetricSetsを作成して推定サービスをチャート化し、アラートを発する 🔗

注釈

Monitoring MetricSetsでサポートされるのは、サードパーティまたは未インストルメントのHTTPサービスのみです。

推定サービスに対してMonitoring MetricSet（MMS）を作成することができます。MMSを使用して、ダッシュボード内で推定サービスのメトリクスをチャート化し、推定サービスに対するアラートを発するディテクターを作成することができます。カスタムディメンションを使用して推定サービス用のMonitoring MetricSetsを作成するを参照してください。

Splunk APMは推定サービスをどのように識別するのか？ 🔗

クライアントスパンまたはプロデューサースパンに対応するサーバースパンがない場合、Splunk APMは、対をなさないスパンに、未インストルメントのサービスとのインタラクションを示すタグが含まれているかどうかをチェックします。

推定サービスを識別するために、Splunk APMはまず推定サービスの type を示すタグをチェックし、次にサービスの name を示すタグをチェックします。Splunk APMは、これらのサービスタイプの1つとのインタラクションを示すタグ（1つまたは複数）を持つクライアントスパンまたはプロデューサースパンを特定した後、未インストルメントのサービスにおける操作を表す推定スパンを作成します。

推定サービスのタイプと推定の方法の表は、推定サービスのタイプと、Splunk APMが各タイプの推定サービスを識別するために使用するタグおよび推定メソッドの一覧です。pub/sub推定サービスの場合、推定スパンは対応するクライアントスパンまたはプロデューサースパンからメタデータを継承し、そのスパンに直接添付されます。

pub/sub以外の推定サービスタイプでは、Splunk APMは追加のロジックを適用して、最も重要なアプリケーションレベルの情報のみを確実に取得します。対応するサーバースパンを持たない複数のクライアントスパンが存在する場合、推定スパンはこれらのクライアントスパンのうち最も親となるスパンのメタデータを継承します。そして、推定サービススパンは、これらのクライアントスパンのうち最も新しいスパンに添付されます。そうでない場合、対応するサーバースパンを持たない単一のクライアントスパンが存在する場合は、推定スパンはそのクライアントスパンからメタデータを継承し、同じスパンに添付されます。

HTTPサービスの推定を管理する 🔗

HTTPサービスの推定を設定することで、推定サービスがサービスマップに表示され、Troubleshooting MetricSetsを生成するように制御することができます。

HTTPサービスを推定することの利点は、推定サービスのインストルメント済みサービスとのインタラクションを可視化できることです。考えられるデメリットは、システムから呼び出されるHTTPサービスがたくさんある場合、サービスマップが混雑してTMSのカーディナリティが増える可能性があることです。

Splunk APMの管理者は、推定HTTPサービスを APM Configuration で管理し、個別のシステムに基づいて柔軟性を提供することができます。

前提条件 🔗

推定HTTPサービスを構成するには、adminロールが必要です。

HTTPサービスを推定するためのSplunk APMの設定 🔗

以下の手順に従って、Splunk APMで推定HTTP サービスを設定します：

Splunk APMのランディングページから APM Configuration を選択し、メニューから APM Service & Traces を選択します。APM Services & Traces ページが開きます。
Inferred services で、Inferred HTTP service の行を探し、Configure を選択します。設定ダイアログボックスが開きます。
Configure Inferred HTTP Services の設定ダイアログボックスで、HTTPサービスの推定を選択します。
変更を Save します。

注釈

HTTPサービスを推定すると、新しい推定サービスごとにTroubleshooting MetricSetsが生成されるため、Troubleshooting MetricSetのカーディナリティが増加します。Subscription Usage を選択すると、現在のカーディナリティの使用状況が表示されます。カーディナリティの管理については、Monitoring MetricSetsでのカーディナリティのトラブルシューティングを参照してください。

推定サービスのタイプと推定の方法 🔗

次の表は、推定サービスのタイプおよびタグと、Splunk APMが各推定サービスのタイプを識別するために使用する推定のメソッドの一覧です。これらの推定ルールで使用されるスパンタグは、OpenTelemetryのセマンティック規約に基づいています。

Splunk APMは、以下のタイプのサービスを推定します：

推定HTTPサービス
推定リモートプロシージャコール（RPC）サービス
推定汎用サービス
推定パブリッシャー/サブスクライバー（pub/sub）キュー
推定データベース

推定HTTPサービス 🔗

Splunk APMがHTTPサービスを推定する場合、インストルメント済みのサービスがリモートのHTTPエンドポイントと通信しているということを意味します。

推定HTTPサービスにサービス名を割り当てるために、Splunk APMは以下のことを行います：

参照スパンの span.kind が CLIENT と等しいことを確認します。
peer.service がHTTPサービスであることを保証するために、以下のロジックを適用します：
1. peer.service が存在し、かつ、以下のうち1つ以上が存在する場合、 peer.service からサービス名が抽出されます。
  
  http.host
  
  OpenTelemetryのセマンティック規約のバージョン1.16.0以下をサポートするライブラリ内の http.url、または、OpenTelemetryのセマンティック規約のバージョン1.17.0以降をサポートするライブラリ内の url.full
  
  OpenTelemetryのセマンティック規約のバージョン1.16.0以下をサポートするライブラリ内の net.peer.name、または、OpenTelemetryのセマンティック規約のバージョン1.17.0以降をサポートするライブラリ内の server.address
ステップ2がtrueでない場合は、以下のタグ内で、順番にサービス名を探します。これらのタグがすべて見つかった場合は、最初に現れたタグからサービス名を推定します。これらのタグがいずれも見つからない場合、Splunk APMは、そのスパンが推定HTTPサービスには関連していないものと見なします。
1. http.host：ホスト名はそのまま抽出
2. peer.hostname：ホスト名はそのまま抽出
3. peer.address：ホスト名はURLから抽出
4. OpenTelemetryのセマンティック規約のバージョン1.16.0以下をサポートするライブラリでは、ホスト名は http.url から抽出されます。OpenTelemetryのセマンティック規約のバージョン1.17.0以降をサポートするライブラリでは、ホスト名は url.full から抽出されます。
5. OpenTelemetryのセマンティック規約のバージョン1.16.0以下をサポートするライブラリでは、ホスト名は net.peer.name からそのまま抽出されます。OpenTelemetryのセマンティック規約のバージョン1.17.0以降をサポートするライブラリでは、ホスト名は server.address から抽出されます。

注釈

サービスマップのノイズを減らし、カーディナリティを管理するために、Splunk APMはホスト名のないサービスやIPアドレスをホスト名として使用しているサービスを除外します。IPアドレスを有効にする必要がある場合は、営業担当者にお問い合わせください。

推定リモートプロシージャコール（RPC）サービス 🔗

Splunk APMがRPCサービスを推定する場合、インストルメント済みのサービスがリモートプロシージャコールを行っているということを意味します。

RPCサービスを推定するために、Splunk APMは以下のことを行います：

参照スパンの span.kind が CLIENT と等しいことを確認します。
参照スパンに rpc.system スパンタグが含まれていることを確認します。このタグは、grpc、java_rmi、wcf などのリモートシステムを識別するために使用されます。
以下のタグ内で、以下の順番で、サービス名を探します。これらのタグがすべて見つかった場合は、最初に現れたタグからサービス名を推定します。これらのタグがいずれも見つからない場合、Splunk APMは、そのスパンが推定RPCサービスには関連していないものと見なします。
1. rpc.service
2. OpenTelemetryのセマンティック規約のバージョン1.16.0以下をサポートするライブラリでは、net.peer.name。 OpenTelemetryのセマンティック規約のバージョン1.17.0以降をサポートするライブラリでは、server.address。
3. rpc.system

推定汎用サービス 🔗

これは、peer.service スパンタグを使用して汎用サービスを推定するためのキャッチオールレイヤーです。

クライアントスパンから汎用サービスを推定するために、Splunk APMは以下のことを行います：

参照スパンの span.kind が CLIENT と等しいことを確認します。
peer.service タグからサービス名を探します。
peer.service タグが存在する場合、そのタグからサービス名を推定します。 peer.service タグが存在しない場合、そのスパンは推定汎用サービスに関連していないものと見なされます。

AWSサービスに関する注意事項： AWSサービスを識別するには、スパンに http.url が含まれている必要があります。Splunk APMはこのタグの値にヒューリスティックな手法を適用して、URLからAWSサービスのタイプを判断します。

推定パブリッシャー/サブスクライバー（pub/sub）キュー 🔗

Splunk APMがパブリッシャー/サブスクライバーキューを推定する場合、それはインストルメント済みのサービスが未インストルメントのpub/subとやりとりしているということを意味します。推定pub/subを識別するために、Splunk APMは以下のことを行います：

参照スパンの span.kind が PRODUCER または CLIENT と等しいことを確認します。
スパンが messaging.destination （OpenTelemetryのセマンティック規約バージョン1.16.0以下をサポートするライブラリ内）または messaging.destination.name （OpenTelemetryのセマンティック規約バージョン1.17.0以上をサポートするライブラリ内）のいずれかを含んでいることを確認します。以下のタグの値が、メッセージの送信先のトピックやチャネルの名前を指定するために使用されます。
1. messaging.system と messaging.destination.name の両方が存在する場合、推定サービス名は< messaging.system タグの値>:< messaging.destination.name タグの値> と等しくなる。
2. messaging.system がNULLの場合、推定サービス名は< messaging.destination.name タグの値>と等しくなる。
3. messaging.destination.name がNULLの場合、推定サービス名は< messaging.system タグの値>と等しくなる。

推定データベース 🔗

Splunk APMがデータベースを推定する場合、インストルメント済みのサービスが未インストルメントのデータベースを呼び出していることを意味します。

データベースを識別するには、参照スパンの kind が client と等しく、スパンに以下のタグのうち少なくとも1つが含まれている必要があります：

db.system
db.name
db.type
db.instance

推定データベースの name を決定するために、Splunk APMは、以下の順序で以下のロジックを適用します：

db.system タグが存在する場合、その値は、mysql や redis などのように、照会されるデータベースのタイプを指定するために使用されます。このタグのみが存在する場合、その値は推定データベースの service.name としても使用されます。
db.name タグが存在する場合、その値は db.system と連結されて推定サービス名： db.system:db.name を形成します（例： mysql:sql_db_1 ）。
If the db.connection_string tag is present and its value conforms to a known format such as Java database connectivity (JDBC), Splunk APM extracts the database name portion of the URL and concatenates it with the value of db.system to form the database name, such as mysql:dbname. If the value of db.connection_string does not conform to a known format or the database portion cannot be extracted and db.name also does not exist, Splunk APM uses the raw value of db.connection_string as the database name. If db.system also exists, the 2 values are concatenated.

Splunk APMは、サポートされているSQLデータベースの追加分析も提供します。詳しくは Database Query Performanceの監視を参照してください。

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

Related Topics