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メトリクスでは、推定サービスのインタラクションの全体像を把握できないことがあります。

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

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

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

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

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

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

Create Monitoring MetricSets to chart and alert on inferred services 🔗

注釈

Only third-party or un-instrumented HTTP services are supported for Monitoring MetricSets.

You can create a Monitoring MetricSet (MMS) for inferred services. Use MMS to chart inferred service metrics in dashboards and create detectors to alert on your inferred services. See Create a Monitoring MetricSet with a custom dimension for an inferred service.

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

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

To identify an inferred service, Splunk APM first checks for tags that indicate the type of the inferred service, and then checks for tags that indicate the service name. After Splunk APM identifies a client or producer span with a tag or tags that indicate interaction with 1 of these service types, it creates an inferred span to represent the operation in the uninstrumented service.

推定サービスのタイプと推定の方法 の表は、推定サービスのタイプと、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. Verifies that the span.kind of the referring span is equal to CLIENT.

  2. To ensure that the peer.service is an HTTP service, applies the following logic:
    1. If peer.service exists and 1 or more of following also exist, the service name is extracted from peer.service.

      1. http.host

      2. http.url in libraries that support OpenTelemetry semantic conventions version 1.16.0 or lower or url.full in libraries that support OpenTelemetry semantic conventions version 1.17.0 or higher

      3. net.peer.name in libraries that support OpenTelemetry semantic conventions version 1.16.0 or lower or server.address in libraries that support OpenTelemetry semantic conventions version 1.17.0 or higher

  3. If step 2 is not true, looks for the service name in the following tags, in order. If any of these tags are found, infers the service name from the first appearing tag. If none of these tags are found, Splunk APM does not consider the span to be related to an inferred HTTP service.

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

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

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

    4. For libraries that support OpenTelemetry semantic conventions version 1.16.0 or lower, host name is extracted from http.url. For libraries that support OpenTelemetry semantic conventions version 1.17.0 or higher, host name is extracted from url.full.

    5. For libraries that support OpenTelemetry semantic conventions version 1.16.0 or lower, host name extracted as-is from net.peer.name. For libraries that support OpenTelemetry semantic conventions version 1.17.0 or higher, host name is extracted from server.address.

注釈

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

Inferred remote procedure call (RPC) services 🔗

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

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

  1. Verifies that the span.kind of the referring span is equal to CLIENT.

  2. Verifies that the referring span contains the rpc.system span tag. This tag is used to identify the remote system, such as grpc, java_rmi, or wcf.

  3. Looks for the service name in the following tags, in the following order. If any of these tags are found, infers the service name from the first appearing tag. If none of these tags are found, Splunk APM does not consider the span to be related to an inferred RPC service.

    1. rpc.service

    2. For libraries that support OpenTelemetry semantic conventions version 1.16.0 or lower, net.peer.name. For libraries that support OpenTelemetry semantic conventions version 1.17.0 or higher, server.address.

    3. rpc.system

推定汎用サービス 🔗

これは、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 2 values are concatenated.

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

This page was last updated on 2024年08月14日.