エンドポイント

オンラインで編集する

エンドポイントは、サービスの API を定義し、サービスによって公開される操作に対するきめの細かいビューを提供します。 特定のサービスに対する呼び出しはすべて、単一のエンドポイントで行われます。 すべてのエンドポイントには、 BATCH、 SHELL、 DATABASE、 HTTP、 MESSAGING、 RPCという、自動的に検出された単一のタイプがあります。 サービスと同様に、エンドポイントはアプリケーション・パースペクティブのレンズを通して表示できます。

エンドポイントは、静的に宣言することも、(通常は SpringBoot 名などのインフラストラクチャー・タグを使用して決定されるサービスとは異なり) 呼び出しタグに従うこともできます。 例えば、{call.http.method} {call.http.path} という組み合わせが HTTP サービスの通常のエンドポイントになります。

サービスに別個のエンドポイントを定義するもう 1 つの利点は、主に「モノリス」を使用することで、HTTP/REST API、データベース・アクセス、メッセージ・バス統合など、さまざまなフレームワークやテクノロジーをサービスに組み込むことができることです。 API のタイプごとに少なくともエンドポイントを作成し、場合によってはプロトコルの詳細、メトリック、統計などをさらに分離することにより、API タイプごとに収集されます。

Instana では、デフォルトのルールに基づいてエンドポイントが自動的にマップされます。 詳しくは、 エンドポイント・マッピングを参照してください。

事前定義ルール

オンラインで編集する

Instana あらかじめ定義された一連のルールに基づいて、エンドポイントを自動的にマッピングします。 以下の規則は降順で考慮されます。 ルールが一致すると、それぞれのエンドポイントが作成されます。

ルール タグ
カスタム・エンドポイント・ルール ユーザーによって定義されたタグ ( カスタム・エンドポイント・マッピングを参照)
HTTP ヘッダーによるユーザー定義のエンドポイント名 {call.http.header.x-instana-endpoint}
SDK スパン・データのユーザー定義エンドポイント名 {call.tag.endpoint}
OpenTelemetry 定義済み操作名 {otel.operation}
Jaeger 定義された操作名 {call.tag.jaeger.operation}
Zipkin 定義済み操作名 {call.tag.zipkin.operation}
SOAP アクション HTTP ヘッダー {call.http.header.soapaction}
RPC WSDLネームスペースを使用して {call.rpc.method-1}
RPC {call.rpc.method}
GraphQL {call.graphql.operationType?} {call.graphql.operationName?}
16 進パターンではなくバッチ Quartz タイプ {call.batch.jobType}
期限の代わりにバッチ四半期タイプ {call.batch.jobType}
接頭部付きバッチ 16 進数 {call.batch.job-1}
Batch Quartz 数値接尾辞 {call.batch.job-1}
Spring バッチ・ジョブ {call.batch.job-1}
バッチ {call.batch.job}
プリズマモデル {call.database.statement-1}
プリズマ・モデル・フォールバック プリズマ
JDBC 解析済みステートメント {call.database.statement-1}
JDBC ストアード・プロシージャー・ステートメントの結果 {call.database.statement-1}
Neo4j 解析済みステートメント {call.database.statement-1}
Cassandra 解析済みステートメント {call.database.statement-1}
Cosmos 非 sql コマンド {call.database.schema-1}
ElasticSearch 複数のインデックス {call.database.schema-1}
ElasticSearch 単一索引 {call.database.schema}
ElasticSearch アクション {call.database.commandType}
ElasticSearch その他 API エンドポイント その他 API エンドポイント
照会から解析された MongoDB コレクション {call.database.schema-1}.{call.database.statement-2}
MongoDB コレクションは照会から解析できません {call.database.schema-1}
名前空間から解析された MongoDB コレクション {call.database.schema}
DynamoDB テーブル {call.database.schema}
Redis コマンド {call.database.statement}
AWS S3 バケット {call.database.schema}
AWS S3 操作 その他 API エンドポイント
GCS バケット {call.database.schema}
GCS 操作 その他 API エンドポイント
Azure Storage コンテナ {call.database.schema}
Azure Storage 操作 その他 API エンドポイント
Memcache/ Memcached / EhCache 操作 {call.database.commandType}
Couchbase バケット {call.database.schema}
データ・グリッド・キャッシュ {call.database.schema}
Couchbase 解析済みステートメント {call.database.statement-1}
エアロスパイク声明 {call.database.statement}
ステートメントを含む IMS DB {call.database.statement}
IMS DB (ステートメントなし) IMS DB
データベースのフォールバック {call.database.commandType}
一時メッセージ・キュー 一時キュー
IBM MQ アドレスを使用したspan {call.messaging.address-1}
IBM ACE アドレスを使用したspan {call.messaging.address-1}
AzureQueue のメッセージング・デフォルト交換 {call.messaging.exchangeType}
Apache RocketMQ アドレスを使用したspan {call.messaging.address-1}
メッセージング汎用 {call.messaging.address}
RabbitMQ のメッセージング・デフォルト交換 デフォルトの交換
一時メッセージ・キュー 一時キュー
z/OS API にアクセス {call.zcee.apiName}
HTTP パステンプレートを使用して {call.http.method?} /{call.http.pathTemplate-1}
HTTP ルートID付き {call.http.routeId}
「 API 」バージョン以降で利用可能な場合、最初の HTTP パスセグメント {call.http.method?} {call.http.path-1}
HTTP ルートパスを指定するメソッド {call.http.method} /
HTTP ルートパス {call.http.method?} /
汎用イベント {call.event.source}
引数なしのシェル・バイナリー名および引数なしのスクリプト名の取得 {call.shell.command-1} {call.shell.command-2}
引数なしのシェル・バイナリー名の取得 {call.shell.command}
名前とバージョンを持つサービスとしての機能 {faas.functionname}:{faas.functionversion}
名前のみを持つサービスとして機能 {faas.functionname}
ID を持つサービスとしての機能 {cloud.id}
SDK.name {call.sdk.name}

エンドポイント・マッピング

オンラインで編集する

エンドポイントは、エンドポイント・タイプに基づいて自動的にマップされます。

例えば、Instana では、アクセス可能であればパス・テンプレートに基づいて HTTP エンドポイントが自動的にグループ化されます。

/hospital/1948/patient/291148
/hospital/728/patient/924892
/hospital/47/patient/25978
/hospital/108429/patient/1847

前の例では、同じアプリケーションコードによって処理され、したがってパフォーマンスプロファイルが共通している前述のエンドポイントは、次のようにグループ化され、まとめて報告されます：

/hospital/{hid}/patient/{pid}

これは自動的に行われるため、既知のフレームワークについてはユーザーによる操作は不要です。

パステンプレートが利用できない場合、エンドポイントは最初のパスセグメントにマッピングされるか、 必要に応じて設定することができます。

以下に、パス・テンプレートが使用できない場合の例をいくつか示します。

  • モニター対象サービスでパス・テンプレートが使用されていません。
  • トレーサーはパス・テンプレートをサポートしません。
  • 認証の失敗など、一部のエッジでは、トレーサーはパス・テンプレート情報にアクセスできません。
  • 宛先サービスはモニターされず、クライアントからの出口スパンはパス・テンプレートを認識しません。

独自のトレースコードを作成する場合は、同様の結果を得る方法について、当社の「 カスタムトレースのベストプラクティス」 をご覧ください。

エンドポイント・マッピングのカスタマイズ

オンラインで編集する

Instana では、サービスごとに、サービス・エンドポイントの抽出方法を制御する構成を 1 つ設定できます。 構成にアクセスするには、サービス・ダッシュボードに移動し、エンドポイント・タブに移動して「エンドポイントの構成」を押します。

アプリケーション依存関係マップの概要

なお、カスタムエンドポイントの設定は、 HTTP ベースのサービスでのみ利用可能です。

カスタム・エンドポイント・ルール

オンラインで編集する

Instana には、常に抽出チェーンの一部である以下の 3 つのデフォルト HTTP ルールが付属しています。

  • 検出されたフレームワーク: 検出されたフレームワークで指定されたエンドポイントが抽出されます (アクセス可能な場合)。
  • /*: 最初のパス・パラメーターに基づいてエンドポイントを抽出します。
  • 指定なし: 先行する規則と一致しない呼び出しは、 このエンドポイントに割り当てられます。

追加の構成を指定するためには、複数のカスタム・ルールを定義できます。 これを行うには、任意の HTTP サービスからカスタムエンドポイント設定ダイアログを開き、「 カスタム HTTP ルールの追加 」を選択します。 その後に表示されるダイアログで、特定のパス (実際のルール)、および定義されたパスが予期どおりに機能しているかどうかを確認するための複数のテスト・ケースを定義できます。 パスには、/api や /myShopEndpoint のように静的セグメントや、/{productId} のようなパス・パラメーターを使用することも、/* を使用してすべてのセグメントに一致させることもできます。

ダイアログのルール・テスター部分では、ルールを検証する複数のテスト・ケースを定義できます。 例えば、クエリー /api/*/{version} を指定した場合、以下のテスト・ケース /api/anyName/123 は一致しますが、/otherApi/anyName/123 は一致しません。

アプリケーション依存関係マップの概要

順次評価

オンラインで編集する

ルールは先頭から最後尾へと順に適用され、呼び出しは最初に一致したルールに割り当てられます。 変更シーケンスは、単にルールを再配列しますが、ドラッグ&ドロップのみをします。 Instana のデフォルト・ルールは無効にできますが、並べ替えることはできません。

アプリケーション依存関係マップの概要

合成エンドポイント

オンラインで編集する

ヘルス・チェック・エンドポイントの呼び出しなど、合成トラフィックのみを受信するエンドポイントにより、アプリケーションとサービスの KPI がゆがめられる可能性があります。 Instana は、これらのエンドポイントを自動検出し、 合成 のマークを付けて、アプリケーションおよびサービスの KPI に影響を与えないようにします。

Instana での合成エンドポイントの使用方法

オンラインで編集する

合成エンドポイントで収集されたすべての呼び出しは、無制限分析で合成としてマークされ、アプリケーション・パースペクティブ、サービス、およびエンドポイントの各ビューの KPI に対してカウントされません。

合成エンドポイント

それらの呼び出しはアプリケーション・パースペクティブおよびサービスの KPI に対してカウントされませんが、個々の合成エンドポイントには、非合成版のものと同様に独自のダッシュボードがあります。

合成エンドポイント

デフォルトの合成エンドポイント

オンラインで編集する

デフォルトでは、合成エンドポイントは以下の URL パターンによって識別されます。

組み込みルールを無効にし、カスタムルールを指定して、追加のエンドポイントを「Synthetic」としてフラグ付けすることができます。 詳細については、「 Syntheticエンドポイントのカスタムルール 」のドキュメントを参照してください。 組み込みおよびカスタムエンドポイントルールの設定は、 [サービス] リストにある [サービスの設定] ボタンからアクセスできます。

合成エンドポイントのカスタム・ルール

オンラインで編集する
注: カスタム・ルールは、すべてのサービスにわたってグローバルに適用されます。

構成をサポートするために、影響を受けるエンドポイントおよびサービスが表示されます。

合成エンドポイントの構成

合成呼び出し

オンラインで編集する

エンドポイント全体を合成としてマークできるだけでなく、個々の呼び出しに合成のマークを付けることもできます。 これは特に、合成チェックで「実動」API を使用する場合に役立ちます。これは一般的に 素晴らしい アイデアです。

合成呼び出しルール

オンラインで編集する

以下の条件が 1 つ以上満たされている場合、呼び出しは Instana で合成としてマークされます。

無制限分析での合成呼び出し

オンラインで編集する

合成呼び出しは、デフォルトでは、無制限分析で非表示になっています。これらの呼び出しは、誤りが非常に多くなった 場合にのみパフォーマンス分析に役立つ傾向があるためです。 無制限分析で合成呼び出しもクエリーするには、「非表示の呼び出し」->「合成呼び出し」スイッチを使用してオプトインする必要があります。

無制限分析でのシンセティック呼び出しへのオプトイン

「指定なし」エンドポイント

オンラインで編集する

呼び出しをエンドポイントに自動的にマップするのに十分な情報がない場合 (例えば、十分なデータを指定せずにエンドポイントが手動でインスツルメントされた場合など)、それらの呼び出しは特殊な「指定なし」エンドポイントにマップされます。

その他のエンドポイント

オンラインで編集する

特定のサービスで検出されたエンドポイントが多すぎる場合、呼び出しは特殊な「その他」エンドポイントにグループ化されます。 この安全機能は、一連のエンドポイントを妥当なサイズに保つためのものです。

通常、 Instana の既定のルールまたはカスタムルールのいずれかが、1件の着信を多数のエンドポイントに分散させている場合に、この現象が発生します。

たとえば、 Instana の定義済みルールの一つには、 HTTP への呼び出しを、 URL 内で最初に検出されたパスセグメントから名前が取得されたエンドポイントにマッピングするものがあります。 これらのセグメントが動的な値 (「GET /blue-item」、「GET /red-item」など) から作成されている場合、 このルールを適用すると、エンドポイントの数が膨大になり、実用的ではありません。

HTTP のエンドポイントを扱う場合、 エンドポイント抽出ルールの設定を変更することで、状況が改善される可能性があります。

内部トリガー・エンドポイント

オンラインで編集する

Instana によって自動的にキャプチャーされたトレースは通常、サービスへの着信呼び出しから始まります。 ただし、 Instana SDK を使用する場合、サービスからの発信呼び出しを起点としてトレースを開始することが可能です。 その場合、Instana では、読みやすさを向上させるために、そのサービスに対する合成親呼び出し (「内部トリガー」エンドポイントにマップされる) が作成されます。

内部トリガー・エンドポイント

エンドポイントのフローマップ

オンラインで編集する

エンドポイント・フロー・マップには、エンドポイントのアップストリーム・エンドポイントとダウンストリーム・エンドポイントが表示されます。

エンドポイントフローマップの制限

オンラインで編集する

エンドポイント・フロー・マップには、現在、20 秒以内に終了する短時間実行の同期トレースについてのみ正確なデータが表示されます。 それ以外の場合は、エンドポイント・フロー・マップに不正確なデータが表示される可能性があります。