Docs » Splunk APMでサービス、スパン、トレースを管理する » 推定サービスのパフォーマンスを分析する

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

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

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

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

タイプ

例

備考
汎用サービス
（サービスマップ内の点線の円）

AWSサービス
このサービスタイプには、外部サービスプロバイダー、汎用リモートプロシージャコール（RPC）、HTTPサービスが含まれます。各タイプの詳細については、以下のセクションを参照してください：
システムが多数の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メトリクスでは、推定サービスのインタラクションの全体像を把握できないことがあります。

Splunk APMは、推定サービスの Monitoring MetricSets （MMS）を作成しません。なぜなら、MMSは span.kind = SERVER または span.kind = CONSUMER のスパンからリアルタイムで作成されるものであり、Splunk APMは、インストルメントされていないサービスからサーバー側またはコンシューマー側のスパンを受信しないからです。つまり、推定サービスがランディングページのサービスリストに表示されていても、APMのランディングページやダッシュボード、アラートでは推定サービスに関するリアルタイムのMMSデータを取得することはできず、推定サービスに基づいてディテクターを作成することもできません。

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

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

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

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

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

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

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

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

推定サービスを識別するために、Splunk APMはまず推定サービスの type を示すタグをチェックし、次にサービスの name を示すタグをチェックします。Splunk APMは、これらのサービスタイプのいずれかとのインタラクションを示すタグ（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 サービスを設定します：

  1. Splunk APMのランディングページから APM Configuration を選択し、メニューから APM Service & Traces を選択します。APM Services & Traces ページが開きます。

  2. Inferred services で、Inferred HTTP service の行を探し、Configure を選択します。設定ダイアログボックスが開きます。

  3. Configure Inferred HTTP Services の設定ダイアログボックスで、HTTPサービスの推定 を選択します。

  4. 変更を Save します。

注釈

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

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

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

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

推定HTTPサービス 🔗

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

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

  1. 参照スパンの span.kind が CLIENT と等しいことを確認します。

  2. http.host、http.url、net.peer.name のうち1つ以上が存在し、peer.service も存在する場合は、peer.service をサービス名に使用します。これにより、peer.service がHTTPサービスであることが保証されます。

  3. 以下のタグ内で、以下の順で、サービス名を探します：

    1. http.host：ホスト名はそのまま抽出

    2. peer.hostname：ホスト名はそのまま抽出

    3. peer.address：ホスト名はURLから抽出

    4. http.url：ホスト名はURLから抽出

    5. net.peer.name：ホスト名はそのまま抽出

  4. これらのタグのいずれかが見つかった場合、最初に現れたタグからサービス名を推定します。これらのタグが1つも見つからない場合、そのスパンは推定HTTPサービスに関連していないものと見なされます。

注釈

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

推定RPCサービス 🔗

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

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

  1. 参照スパンの span.kind が CLIENT と等しいことを確認します。

  2. 参照スパンに rpc.system スパンタグが含まれていることを確認します。このタグは、grpc、java_rmi、wcf など、リモートシステムを識別するために使用されます。

  3. rpc.service、net.peer.name、rpc.system のタグの順にサービス名を探します。

  4. これらのタグのいずれかが見つかった場合、最初に現れたタグからサービス名を推定します。これらのタグが1つも見つからない場合、そのスパンは推定RPCサービスに関連していないものと見なされます。

推定汎用サービス 🔗

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

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

  1. 参照スパンの span.kind が CLIENT と等しいことを確認します。

  2. peer.service タグからサービス名を探します。

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

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

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

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

  1. 参照スパンの span.kind が PRODUCER または CLIENT と等しいことを確認します。

  2. スパンが messaging.destination （OpenTelemetryのセマンティック規約バージョン1.16.0以下をサポートするライブラリ内）または messaging.destination.name （OpenTelemetryのセマンティック規約バージョン1.17.0以上をサポートするライブラリ内）のいずれかを含んでいることを確認します。以下のタグの値が、メッセージの送信先のトピックやチャネルの名前を指定するために使用されます。

    1. If both messaging.system and messaging.destination.name exist, the inferred service name is equal to <Value of messaging.system tag>:<Value of messaging.destination.name tag>.

    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は、以下の順序で以下のロジックを適用します：

  1. db.system タグが存在する場合、その値は、mysql や redis などのように、照会されるデータベースのタイプを指定するために使用されます。このタグのみが存在する場合、その値は推定データベースの service.name としても使用されます。

  2. db.name タグが存在する場合、その値は db.system と連結されて推定サービス名： db.system:db.name を形成します（例： mysql:sql_db_1 ）。

  3. 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 two values are concatenated.

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

This page was last updated on 2024年02月28日.