コンセプト

従来のアプリケーションパフォーマンス管理(APM)ソリューションは、アプリケーションのパフォーマンスと可用性の管理に関するものです。

APMツールのアプリケーションは 静的な エージェントを使用して監視されるコードランタイムのセット(JVMやCLRなど)。 通常、アプリケーションは各エージェントの構成パラメーターとして定義されます。

この概念は、従来の3層アプリケーションの優れたモデルでしたが、現代の(マイクロ)サービスアプリケーションでは機能しなくなりました。 サービスは常にひとつのアプリケーションにのみ属しているわけではありません。 会社のオンラインストアやPOSソリューションでも使用されているクレジットカード決済サービスを考えてみてください。 この問題の解決策は、すべてのサービスをアプリケーションとして定義することですが、それによっていくつかの新しい問題が発生します。

  • 監視するアプリケーションが多すぎます。 すべてのサービスをアプリケーションとして扱うと、数百または数千のアプリケーションになります。 ダッシュボードを使用してそれらを監視しても機能しません。人間にとってはデータが多すぎます。
  • コンテキストの喪失。 すべてのサービスは個別に扱われるため、依存関係を理解し​​、サービスの役割と問題のコンテキストを理解することは不可能です。

Instanaは、アプリケーション階層全体にサービス、エンドポイント、およびアプリケーションの観点を持つ次世代APMを提供します。 私たちの主な目標は、ビジネスのサービス品質の監視を簡素化することです。 トレースおよびコンポーネントセンサーから収集したデータに基づいて、実際に実装されているサービスからアプリケーションランドスケープを直接発見します。 収集されたデータに基づいて、すべての個々のサービスの健全性、そしてその後、アプリケーション全体の健全性を知ることができます。

アプリケーションの視点

「アプリケーション」という用語はあいまいであり、さまざまなチームが明確に異なるものを記述するためにそれを使用する場合があります。 Instanaは、アプリケーションの代わりに、アプリケーションの観点を提供して、チームにとって意味のある種​​類のセマンティクスをキャプチャできるようにします。

マルチテナントオファリングを実行するチームは、テナント(tenant:onetenant:two)をアプリケーションとしてキャプチャしたいと考えています。 eコマースサイトを運営する別のチームは、米国(zone:us)とドイツ語(zone:eu)の店舗を2つの別個のアプリケーションとしてキャプチャしたい場合があります。 別のチームは、異なる環境(k8s.env:prodk8s.env:dev)をアプリケーションとしてキャプチャしたいと思うでしょう。 そして最後に、ある顧客は、機能的に連携する一連のサービスをアプリケーションにグループ化することができます。 これらの各アプリケーションには、独自のセマンティクスとさまざまなユースケースが付属しています。

application-perspectives

アプリケーションの観点では、サービス全体、またはそれらのサービスへの呼び出しのサブセットのみをオーバーレイできます。 アプリケーションの観点は、完全に、部分的に、またはまったく重ならない場合があります。 サービスとエンドポイントは、複数のアプリケーションの定義に含まれるか、まったく含まれない場合があります。

アプリケーションパースペクティブの使用

アプリケーションは基本的に呼び出しのグループであり、一致する呼び出しは タグ。 新しいアプリケーションパースペクティブを作成するには、アプリケーションパースペクティブインベントリに移動し、[+アプリケーションパースペクティブの作成]を選択します。 ダイアログで、アプリケーションの観点を構成するひとつ以上のタグを選択します。 これらの条件に一致するすべての呼び出しは、このアプリケーションと呼び出しに関連付けられます 任意のデータベースまたはメッセージングサービス アプリケーション内で呼び出されます。

application-creation-dialog

service.name、endpoint.nameタグ、およびagent.tagやhost.nameなどのインフラストラクチャエンティティタグは、コールの発信元と宛先の両方に適用できます。 デフォルトでは宛先に適用されますが、フィルターの編集ダイアログでソースに変更できます。 送信元と宛先を組み合わせることにより、たとえば、agent.zone「prod」からagent.zone「test」に向けて発行されたコールをグループ化するアプリケーションを定義できます。

タグは演算子と結合できます。 ユーザーは、次のタグと結合する各タグに対してANDまたはORを選択できます。 AND結合とOR結合を組み合わせて使用​​する場合、AND結合の境界はOR結合よりも高くなります。 たとえば、タグ定義tag.A AND tag.B OR tag.c AND tag.dの場合、Instanaはそれを(tag.A AND tag.B)OR(tag.c AND tag.d)のように解釈して処理します。

アプリケーションパースペクティブを更新または削除するには、[構成]タブを選択します。 アプリケーションパースペクティブが削除されても、選択した時間枠内に存在した限り、インベントリにリストされたままになります。

KPIとアラートの観点から、アプリケーションを解釈する方法は2つあります。

  • インバウンドコールモード:KPIとそれぞれのアラートの計算は、アプリケーションの外部から開始された呼び出しのみに基づいており、サービスの宛先は選択されたアプリケーションパースペクティブの一部です。 これにより、アプリケーションのパースペクティブを、消費者が認識する方法で追跡できます。
  • 全コールモード:KPIの計算は、アプリケーションに対して行われた各呼び出しに基づいています。 それがアプリケーションの境界にあるのか、アプリケーションの奥深くにあるのか。 このモードは、アプリケーションの全体像です。

アプリケーションパースペクティブを閲覧するときは、インバウンドコール全コールをいつでも切り替えて表示でき、表示される情報はそれに応じて調整されます(現時点ではサービス依存マップを除く)。

Application Perspectiveの[構成]タブでは、組み込みイベントを介した問題の検出に適用されるデフォルトモードを構成することもできます。 デフォルトが指定されていない場合、組み込みイベントはすべての呼び出しのKPIに依存します。これは、2つのモードの導入前に作成されたアプリケーションパースペクティブとの後方互換性のためです。 既存のアプリケーションパースペクティブの構成を更新してデフォルトモードを指定すると、組み込みイベントの動作が自動的に調整され、デフォルトモードに依存します。

アプリケーションパースペクティブ内での着信またはすべてのコールの表示

インバウンドセレクターまたはすべてのコールセレクターがダッシュボードで使用可能な場合はいつでも、パースペクティブをデフォルトから変更できます。 アプリケーションパースペクティブ内でサービスやエンドポイントを選択すると、境界設定が継承されます。

application-inbound-all-calls-choice

サービス

サービスは、システムの残りの部分にパブリックAPIを提供する論理コンポーネントと見なすことができ、APIはそのエンドポイントで構成されます。 サービスが監視されており、コールを発信および受信しています。 サービスへのリクエストは、特定のエンドポイントへの単一の呼び出しになります。

サービスは単独で、またはアプリケーションの観点からレンズと見なすことができます。 多くの場合、サービスは、パッケージやコンテナなどのひとつの「展開ユニット」にマッピングされます。 このコンテナの複数のインスタンスが同時に動作する場合、それらはすべて同じ論理サービスにマッピングされます。

サービスタイプは、エンドポイントからの継承を通じて自動的に割り当てられます。 たとえば、サービスにHTTPエンドポイントとBATCHエンドポイントの両方がある場合、サービスにはHTTPタイプとBATCHタイプの両方が割り当てられます。 サービスのKPI(コール、エラーコール、レイテンシ)は、タイプに関係なく、すべてのコールの集約を表示します。

サービスの使用

Instanaは、デフォルトのルールに基づいてサービスを自動的にマップします。 これらのルールは、通話とインフラストラクチャのデータを調べ、認識されるとすぐにサービスを作成します。 さらに、チームはカスタムルールを追加できます。 詳細については、後述のサービスマッピングを参照してください。

エンドポイント

エンドポイントはサービスのAPIを定義し、サービスが公開する操作の詳細なビューを許可します。 サービスへのすべての呼び出しは、単一のエンドポイントで発生します。 また、すべてのエンドポイントには、自動的に検出される単一のタイプ(バッチ、シェル、データベース、HTTP、メッセージング、RPC)があります。 サービスと同様に、エンドポイントはアプリケーションの観点から見ることもできます。

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

サービスの個別のエンドポイントを定義するもうひとつの利点は、主に「モノリス」を使用すると、サービスに多くの異なるフレームワークとテクノロジーを含めることができることです。 HTTP / REST API、データベースアクセス、メッセージバス統合など。APIの種類ごとに少なくともエンドポイントを作成し、プロトコルの詳細、メトリック、統計などのさらに別の種類のAPIごとに分割することができます。

エンドポイントでの作業

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

エンドポイントのグループ化-パステンプレート

Instanaはスマートです。 多くのフレームワークでは、InstanaはRESTフィンガープリントに基づいてエンドポイントを自動的にグループ化します。 例として、次のようなエンドポイント(同じアプリケーションコードによって提供されているため、共有パフォーマンスプロファイルがあります):

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

はグループ化され、次のようにレポートされます:

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

これは自動的に行われ、既知のフレームワークではユーザーの手順は不要です。

独自のトレースコードを作成する場合(OpenTracingなど)、同じ結果を得る方法についてはオープントレーシングのセクションを参照してください。

合成エンドポイント

合成エンドポイント(ヘルスチェックなど)は、アプリケーションとサービスのKPIにカウントされないシミュレートされたトラフィックを表します。

synthetic-endpoints

個々の合成エンドポイントのKPIは引き続き利用可能です。

synthetic-endpoint 1

分析ビューでは、非合成呼び出しでデフォルトで検索が行われますが、これはcall.is_syntheticタグを使用してオーバーライドできます。

synthetic-endpoints-analyze

合成エンドポイントの構成方法については、後述のセクションを参照してください。

「指定されていない」エンドポイント

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

「その他」エンドポイント

特定のサービスで検出されたエンドポイントが多すぎる場合、コールは特別な「その他」エンドポイントの下にグループ化されます。 この保護は、エンドポイントのセットを適切なサイズに保つことを目的としています。

通常、Instanaの事前定義されたルールまたはカスタムルールのひとつが、コールをそれぞれひとつのコールを受信する多数のエンドポイントにグループ化するときに発生します。

たとえば、Instanaの事前定義されたルールのひとつは、URLで見つかった最初のパスセグメントに由来する名前を持つエンドポイントにHTTP呼び出しをマッピングしています。 これらのセグメントが動的な値(たとえば、「GET / blue-item」、「GET / red-item」…)から構築されている場合、このルールを適用すると、多数のエンドポイントが発生します。

HTTPエンドポイントを処理する場合、エンドポイント抽出ルールの構成を変更することで状況が改善される場合があります。

コンフィギュレーション

サービスマッピング

サービスはAPMの不可欠な部分であり、システムの論理ビューを示します。 サービスは、ホスト、コンテナ、プロセスなどのインフラストラクチャコンポーネントから派生します。 コンテナなどの特定のインフラストラクチャコンポーネントをひとつまたは複数のサービスに割り当てる行為は、サービスマッピングと呼ばれます。

Instanaでは、事前定義された広範なルールセットに基づいてすべてのサービスを自動的にマッピングします。 このように、ほとんどの場合、Instanaユーザーは何もする必要がありません。 サービスは自動的に検出され、ダッシュボード、メトリック、およびルールが利用可能になります。

サービスマッピングのカスタマイズ

デフォルトのサービスマッピングをカスタマイズするには、次の4つの方法があります。 カスタムサービスルール、使用して サービス名 INSTANA_SERVICE_NAME環境変数を指定するか、HTTPヘッダーX-Instana-Serviceを指定するタグ。 ことに注意してください カスタムサービスルール INSTANA_SERVICE_NAME環境変数などを使用してサービスが特に構成されている場合でも、他のすべてのルールよりも優先されます。

カスタムサービスルール

カスタムサービスルールを使用する良い例は、インフラストラクチャコンポーネントの既存のメタ情報を活用することです。 たとえば、ユーザーはcom.acme.service-name:myserviceのようなドメイン固有の情報でDockerコンテナーにラベルを付けています。 このラベルからサービスをマップするには、サービスのインベントリで[カスタムサービスの構成]をクリックし、キーdocker.labelおよびcom.acme.service-nameを追加します。 現在com.acme.service-nameというラベルを持つコンテナを渡すすべての呼び出しは、myserviceなど、その値によって名前が付けられているサービスに関連付けられています。 カスタムサービスマッピングを作成するために使用できる他の多くのタグがあります。

サービスマッピングに複数のキーを追加することもできます。すべてのキーは一致する必要があります。 たとえば、ホストゾーンに基づいてステージングサービスを分離する場合は、host.zonedocker.label:com.acme.service-nameの2つのキーを追加できます。 そうすれば、prod-myserviceとdev-myserviceなどの2つのサービスを分離できます。

custom-service-rule

特別なタグservice.default_nameを使用すると、カスタムサービスルールを使用して、追加のタグでサービスのデフォルトルールを拡張することもできます。 たとえば、自動作成されたサービスをホストゾーンごとに分割する場合は、タグservice.default_nameおよびhost.zoneを使用してカスタムサービスルールを作成できます。

呼び出しタグservice.nameを使用する

ユーザーは、ユーザーコード内で非常にカスタマイズされたマッピングを可能にするサービスでこれらに注釈を付けることにより、非常に特定の呼び出しを関連付けることもできます。 サービスアノテーションは、呼び出しの検索/分析のためにservice.nameタグに変換されます。

呼び出し注釈を追加するには、いくつかのオプションがあります。

Java Trace SDKの使用とサービスの命名に関する詳細については、それぞれの「変換と命名」セクションも参照してください。

INSTANA_SERVICE_NAME環境変数の指定

プロセスでINSTANA_SERVICE_NAME環境変数を設定することにより、環境変数の値は、そのプロセスを宛先とするすべての呼び出しのサービス名として使用されます。

Instanaによって認識される環境変数の詳細については、「一般参照-環境変数」ページをご覧ください。

X-Instana-Service HTTPヘッダーの指定

呼び出しでX-Instana-Service HTTPヘッダーを設定することにより、宛先(HTTP要求を受信するサービス)は、ヘッダーで提供された値でタグ付けされます。

注意: X-Instana-Service HTTPヘッダーは自動的に収集されません。 それが機能するには、Instanaエージェントを適切に構成する必要があります。「カスタムHTTPヘッダーのキャプチャ」を参照してください。

事前定義されたルール

以下の規則は、上から下の順序で考慮されます。 ルールが一致すると、それぞれのサービスが作成されます。

ルール

タグ

ユーザー定義のもの: 

カスタムサービスルール

ユーザーが定義したタグ(カスタムサービスルール参照)
呼び出しタグservice.nameを使用{call.service.name}
HTTPヘッダーX-Instana-Serviceを使用する{call.http.header.X-Instana-Service}
トレースSDKサービス名{call.tag.service}
Jaegerサービス名{call.tag.jaeger.service}

Zipkinサービス名

{call.tag.zipkin.service}
インフラストラクチャベース: 
Consulクラスター名Consul@{consul.cluster.name}
Cassandraクラスター名{cassandra.cluster.name}
Elasticsearchクラスター名{elasticsearch.cluster.name}
Couchbaseクラスター名{couchbase.cluster.name}
MongoDBレプリカセット名{mongo.replicaSetName}

Kafkaクラスター名

{kafka.cluster.name}
AWS ECSコンテナー名{container.label.com.amazonaws.ecs.container-name}
AWS ECSタスクファミリー{container.label.com.amazonaws.ecs.task-definition-family}
Kubernetesコンテナ名{kubernetes.container.name}
Cloud Foundryアプリケーション名{cloudfoundry.app.name}
Docker Swarmサービス名{docker.label.com.docker.swarm.service.name}
MarathonアプリケーションID{marathon.app.id-1}
Nomadタスク名{nomad.task.name}
Rancher 1プロジェクトのサービス名{container.label.io.rancher.project_service.name}
コンテナイメージ名{container.image.name-1}
JBoss / Tomcatデプロイメント名(解析済み){call.deployment.name-1}
Dropwizard{dropwizard.name}
Spring Boo{springboot.name}
JBoss{jboss.server.name} {jboss.node.name?}
WebLogic{weblogic.server.name}
WebSphere{websphere.server.name}
RedisポートRedis@{redis.port} on {host.name}
Neo4jポートeo4j@{neo4j.port} on {host.name}
Memcached

ポート

Memcached@{memcached.port} on {host.name}
VarnishポートVarnish@{varnish.port} on {host.name}
ClickHouseポートClickHouse@{clickhouse.httpPort} on {host.name}
MongoDB

データベース名

MongoDB@{mongo.port} on {host.name}
Zookeeper ポートZookeeper@{zookeeper.clientPort} on {host.name}
SolrバージョンSolr@{solr.version} on {host.name}
SolrSolr on {host.name}
PostgreSQLポートPostgreSQL@{postgresql.port} on {host.name}
CockroachDBポートCockroachDB@{cockroachdb.port} on {host.name}
MySQLポートMySQL@{mysql.port} on {host.name}
OracleDBポートOracleDB@{oracledb.port} on {host.name}
MSSQLデータベースsidMSSQL@{mssql.instance}
MariaDBポートMariaDB@{mariadb.port} on {host.name}
Kafka versionKafka@{kafka.version} on {host.name}
ActiveMQブローカー名{activemq.broker.name}
RabbitMQバージョンRabbitMQ@{rabbitmq.version} on {host.name}
JVM名(解析済み){jvm.app.name-1}
JVM名{jvm.app.name}
ホスト環境を備えたNode.jsアプリケーション{nodejs.app.name}
Pythonスナップショット名{python.app.name}
Ruby名{ruby.app.name}
Go名{go.app.name}
利用可能な場合、ホストヘッダー(解析済み)を使用するPHP{call.http.host-1}
PHP / PHP-FPMワーカープールPHP
CLR名{clr.app.name}
.Net Core{netcore.app.name}
Crystal{crystal.app.name}
Haskell{haskell.app.name}
コールベース: 
Shell Span生成されたプロセス
WSDL名前空間を持つオブジェクトを使用したRPCサービスのスパン{call.rpc.object-1}
オブジェクトを使用したスパンRPCサービス{call.rpc.object-1}
ホストとのスパンHTTPサービス{call.http.host-1}
スパンHTTPサービス解析URL{call.http.url-1}
スパンデータベースFTPサービス{call.database.connection}
スパンデータを使用したMongoDBデータベース名{call.database.schema-1}
Elasticsearchデータベース名、常にスパンデータからの接続を使用{call.database.connection-1}
スパンデータからのCouchbaseホスト名{call.database.connection-1}
スパンデータベーススキーマ{call.database.schema}
データベース接続をスパンし、スキーマが空の場合にURIからスキーマを抽出{call.database.connection-1}
ホストを使用したスパンデータベースサービス{call.database.connection-1}
スパンデータベースタイプ(接続とスキーマが空の場合、タイプのみを表示){call.database.type}
アドレスを使用したスパンメッセージングサービス{call.messaging.address-1}
アドレスを使用したスパンメッセージングサービス{call.messaging.address}
スパンメッセージングタイプ(アドレスが空の場合、タイプのみを表示){call.messaging.type}
スパンSDK名SDK
RPC-RMIスパンのスパンRMI名RMI

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

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

たとえば、HTTPエンドポイントは、アクセス可能な場合、パステンプレートに基づいて自動的にマッピングされます。 パステンプレートが使用できない場合、エンドポイントは最初のパスセグメントにマップされるか、必要に応じて構成できます。

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

Instanaでは、サービスごとに、サービスエンドポイントの抽出方法を制御するひとつの構成を使用できます。 構成にアクセスするには、サービスダッシュボードに移動し、[エンドポイント]タブに移動して[エンドポイントの構成]をクリックします。

configuration

カスタムエンドポイントの設定は、httpベースのサービスでのみ使用できます。

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

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

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

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

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

rule_config

逐次評価

ルールは上から下に適用され、最初に一致したルールにコールが割り当てられます。 変更シーケンスは、単にルールを並べ替えるだけで、ドラッグアンドドロップします。 Instanaのデフォルトルールは無効にできますが、並べ替えることはできません。

cascading

合成エンドポイント

合成トラフィックのみを受信するエンドポイント(ヘルスチェックエンドポイントへの呼び出しなど)は、アプリケーションとサービスのKPIを歪める可能性があります。

Instanaは、これらのエンドポイントを自動検出し、アプリケーションおよびサービスKPIに影響を与えないようにすることができます。

さらに、カスタムルールを追加して、追加のエンドポイントにフラグを付けることができます。 ルールはグローバル(すべてのサービス)に適用され、サービスリストの上部にある[サービスの構成]ボタンをクリックするとアクセスできます。

ビルトインルールは無効にでき、カスタムルールは追加、無効、および削除できます。 構成を支援するために、影響を受けるエンドポイントとサービスが表示されます。

synthetic-endpoints-config

アプリケーション依存マップ

依存マップは各アプリケーションで利用可能であり、以下を提供します。

  • アプリケーション内のサービスの依存関係の概要。
  • 通信パスとスループットを理解するためのサービス間の呼び出しの視覚的表現。
  • アプリケーションのアーキテクチャをすばやく理解するためのさまざまなレイアウト。
  • サービスビュー(ダッシュボード、フロー、通話、問題)に簡単にアクセスできます。

dependency_map

エラーメッセージ

エラーメッセージは、サービスのコード実行中に発生したエラーから収集されたすべてのメッセージです。 たとえば、処理中に例外がスローされ、アプリケーションコードによってキャッチおよび処理されない場合、この呼び出しはエラーメッセージとともに「エラーメッセージ」タブにリストされます。 例として、HTTP 500でリクエストに応答するServletのdoGetメソッドの未処理の例外があります。

ログメッセージ

ログメッセージは、インストルメントされたロギングライブラリ/フレームワークから収集されます(たとえば、サポートされているライブラリのリストの「ロギング」セクションを参照)。 サービスがロギングライブラリを介して重大度がWARN以上のログメッセージを書き込むと、そのメッセージは[ログメッセージ]タブに表示されます。 さらに、キャプチャされたログメッセージは、トレースのコンテキストでトレースの詳細に表示されます。 ログメッセージが重大度ERROR以上で書き込まれた場合、エラーとしてマークされます。 重大度がWARNより低いログメッセージは追跡されないことに注意してください。

インフラ

アプリケーションパースペクティブビューまたはサービスダッシュボードから、インフラストラクチャモニタリングビューに表示される対応するインフラストラクチャコンポーネントに移動できます。

「監視対象外」のインフラストラクチャコンポーネント

アプリケーションまたはサービスのインフラストラクチャコンポーネントのリストには、「監視対象外」のホスト/コンテナ/プロセスが表示または含まれることがあります。

「監視対象外」コンポーネントは、このサービスの一部またはすべての呼び出しについて、特定のインフラストラクチャコンポーネントにリンクできなかったことを示します。 サービスは「論理」エンティティであるため、多くの場合、監視対象プロセスを介してサービスをインフラストラクチャコンポーネントにリンクできます。 これは、たとえばサードパーティのWebサービスには当てはまりません。サードパーティのWebサービスは監視しませんが、ホスト名+パスに基づいてサービスとエンドポイントを作成します。 ホストまたはプロセスが不明であるため、これらのサービスにより、「不明」なインフラストラクチャコンポーネントが表示されます。