推定サービスのパフォーマンスを分析する 🔗
場合によっては、リモートサービスがまだインストルメントされていなかったり、インストルメンテーションが不可能だったりするために、そのトレースが有効になっていないことがあります。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、およびデータベースは、トレースウォーターフォールビューでもスパンとして表示されます。以下のスクリーンショットのように、グレーのボックスにイタリック体で表示されます:

トレースウォーターフォールで推定スパンを選択すると、対応する親スパンのメタデータが表示されます。ウォーターフォール視覚エフェクトでグレーのストライプのバーとして表示される操作の長さも、親スパンから継承されたものであり、推定サービスでの操作時間を正確に表していない可能性があります。
Monitoring MetricSetsを作成して推定サービスをチャート化し、アラートを発する 🔗
注釈
Monitoring MetricSetsでサポートされるのは、サードパーティまたは未インストルメントのHTTPサービスのみです。
推定サービスに対してMonitoring MetricSet(MMS)を作成することができます。MMSを使用して、ダッシュボード内で推定サービスのメトリクスをチャート化し、推定サービスに対するアラートを発するディテクターを作成することができます。Create a Monitoring MetricSet for an inferred service を参照してください。
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サービス 🔗
Splunk APMがHTTPサービスを推定する場合、インストルメント済みのサービスがリモートのHTTPエンドポイントと通信しているということを意味します。
推定HTTPサービスにサービス名を割り当てるために、Splunk APMは以下のことを行います:
参照スパンの
span.kind
がCLIENT
と等しいことを確認します。peer.service
がHTTPサービスであることを保証するために、以下のロジックを適用します: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サービスには関連していないものと見なします。
http.host
:ホスト名はそのまま抽出peer.hostname
:ホスト名はそのまま抽出peer.address
:ホスト名はURLから抽出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
から抽出されます。
注釈
サービスマップのノイズを減らし、カーディナリティを管理するために、Splunk APMはホスト名のないサービスやIPアドレスをホスト名として使用しているサービスを除外します。IPアドレスを有効にする必要がある場合は、営業担当者にお問い合わせください。
推定リモートプロシージャコール(RPC)サービス 🔗
Splunk APMがRPCサービスを推定する場合、インストルメント済みのサービスがリモートプロシージャコールを行っているということを意味します。
RPCサービスを推定するために、Splunk APMは以下のことを行います:
参照スパンの
span.kind
がCLIENT
と等しいことを確認します。参照スパンに
rpc.system
スパンタグが含まれていることを確認します。このタグは、grpc
、java_rmi
、wcf
などのリモートシステムを識別するために使用されます。- 以下のタグ内で、以下の順番で、サービス名を探します。これらのタグがすべて見つかった場合は、最初に現れたタグからサービス名を推定します。これらのタグがいずれも見つからない場合、Splunk APMは、そのスパンが推定RPCサービスには関連していないものと見なします。
rpc.service
OpenTelemetryのセマンティック規約のバージョン1.16.0以下をサポートするライブラリでは、
net.peer.name
。 OpenTelemetryのセマンティック規約のバージョン1.17.0以降をサポートするライブラリでは、server.address
。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以上をサポートするライブラリ内)のいずれかを含んでいることを確認します。以下のタグの値が、メッセージの送信先のトピックやチャネルの名前を指定するために使用されます。messaging.system
とmessaging.destination.name
の両方が存在する場合、推定サービス名は<messaging.system
タグの値>:<messaging.destination.name
タグの値> と等しくなる。messaging.system
がNULLの場合、推定サービス名は<messaging.destination.name
タグの値>と等しくなる。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
)。db.connection_string
タグが存在し、その値がJavaデータベース接続(JDBC)などの既知のフォーマットに適合している場合、Splunk APMはURLのデータベース名部分を抽出し、db.system
の値と連結して、mysql:dbname
のようなデータベース名を形成します。db.connection_string
の値が既知のフォーマットに適合していない場合や、データベース部分が抽出できず、db.name
も存在しない場合、Splunk APMはdb.connection_string
の生の値をデータベース名として使用します。db.system
も存在する場合は、その2つの値が連結されます。
Splunk APMは、サポートされているSQLデータベースの追加分析も提供します。詳しくは Database Query Performanceの監視 を参照してください。