インフラストラクチャー相関

トレーサーは、着信呼び出しおよび発信呼び出しをキャプチャーするためにプロセスをインスツルメントします。 その後、これらの呼び出しは Instana バックエンドに報告され、そこでこれらの呼び出しのソースと宛先を既知のインフラストラクチャー・エンティティーにリンクしようとします。 ソース・プロセス (または宛先プロセス) がインスツルメントされると、必然的にソース・プロセス (または宛先プロセス) が、それに関するすべてを認識する Instana センサーによってもモニターされることを意味します。 トレーサーとセンサーの両方が同じ場所に配置されているため、両方ともホストとプロセスを認識しています。したがって、インフラストラクチャーのリンクが可能になります。

例えば、Python プロセスは、すべての着信呼び出しと発信呼び出しをキャプチャーする Python トレーサーによってインスツルメントされます。 このとき、このプロセスが実行されているホストで複数のセンサー (ホスト・センサー、プロセス・センサー、python センサー) がアクティブ化されます。 トレーサーとセンサーはどちらも Instana バックエンドにデータを個別に送信しますが、両方にプロセスに対する同じ ID が含まれています。 したがって、着信呼び出しの宛先および発信呼び出しのソースを Python プロセスにリンクすることができます。

多くの場合、 Instana のネイティブトレーサーではなく、 OpenTelemetry で計測されているサービスに対しても、インフラストラクチャの相関分析を行うことができます。 詳細やベストプラクティスについては、 「 OpenTelemetry のサービスマッピングとインフラストラクチャの相関関係」 を参照してください。

Instana Tracersは、データベース、メッセージングシステム、またはクラウドサービスを監視対象としていません。 ただし、これらの追跡対象外のシステムを呼び出すプロセスには計測機能が実装されているため、送信されるリクエストは適切に呼び出しに紐付けられます。 たとえば、 Java というトレーサーは、 Java プロセスから MySQL データベースへの送信リクエストを記録します。 これらのリクエストは、送信元を Java プロセス、宛先を MySQL データベースとする呼び出しとして解析されます。 このような呼び出しは Instana で確認でき、その宛先は多くの場合、呼び出しを受信するインフラストラクチャ・エンティティに関連付けられています。 このマッピングは、 Instana が送信元のクライアントリクエストのアドレス情報を監視対象のインフラストラクチャと一意に照合できる場合にのみ可能です：

一方、Instana は、Instana センサーの 1 つを介してデータベースまたはメッセージング・システムをモニターするため、プロセス、そのポート、およびホストについて認識しています。 その一方で、Instana は、発信要求を分析します。この要求には、宛先プロセスを推測するのに十分な情報 (通常、接続ストリングなどに含まれているホスト名や IP とポート) が含まれている可能性があります。

例えば、MySQL インスタンスへの発信要求には、接続ストリング jdbc:mysql://10.128.0.6:3306 が含まれているといった具合です。

インフラストラクチャー・モニターで対応する MySQL プロセスが検出されました。このプロセスは、ポート 3306 を公開し、IP 10.128.0.6 を公開するホストで実行されています。

IP とポートの両方が一致するため、以下のように、呼び出しと MySQL インスタンスがリンクされます。

Instana では、jdbc:mysql://mysql-svc のような Kubernetes サービス名が含まれた接続ストリングもサポートされます。 背後では、すべての名前空間およびクラスターでサービスを一意的に識別するために、サービス名の完全修飾が試行されます。 結果として、宛先が最終プロセスではなく、Kubernetes サービスにリンクされた呼び出しが検出されます。

クラウド・サービスの場合、プロセスはありませんが、考え方は同じです。モニター対象クラウド・サービスが共有する共通の ID と、そのサービスへの発信要求を探します。 これは例えば、AWS ARN などのリソース ID です。

リクエストのアドレス情報を既知のインフラストラクチャデータと照合できるとは限らない。 場合によっては、次の例に示すように、宛先システムに監視用ツールが導入されているにもかかわらず、データベース、メッセージング、またはクラウドサービスにおいて「監視対象外」のインフラストラクチャとして表示されることがあります

一部の監視対象データベース、メッセージングシステム、またはクラウド技術では、トレーサーが呼び出しから宛先インフラを一意に特定するのに十分なアドレス情報を抽出できないため、インフラの相関分析がサポートされていません。 たとえば、 Kafka のようなメッセージング呼び出しを追跡しても、多くの場合、宛先のキュー名やトピック名は特定できても、実際のメッセージングクラスタやサーバーまでは特定できないことがあります。

接続ストリングに指定されたホストや IP が、インフラストラクチャー・モニター側で認識されるホストや IP のいずれとも一致しない場合、呼び出しをインフラストラクチャーにリンクできないこともあります。 通常、これが生じるのは、特定のレベルの間接化が行われていて、リモート・データベース (またはメッセージング・サービスやクラウド・サービス) を呼び出すプロセスが次のようなホスト名を使用している場合です。

• システム /etc/hosts ファイル内のエントリ
• DNS CNAME エントリー
• プロキシーまたはロード・バランサーへのポインター
• Consul や Zookeeper などのサービス・ディスカバリー・サービスによって指定された別名

また、クライアントからのアドレス情報が複数のインフラストラクチャ・エンティティと一致する場合、コールをインフラストラクチャに紐付けることはできません。 このような状況は、複数のデータベースインスタンスがクライアントからのアクセス用に同じアドレスを使用する、高可用性データベース環境においてよく発生します。 データベース自体には監視機能が実装されていないため、 Instana では、候補となる宛先のうち、実際にデータベース呼び出しを実行したのがどれであるかを特定できません。

外部サービスは、定義上、Instana によってモニターされないため、インフラストラクチャー・モニター側からも可視ではありません。 これらのサービスについては何も認識されないため、これらのサービスの呼び出しは、既知のインフラストラクチャー・エンティティーにリンクされません。

以下のように、「インフラストラクチャー」タブで、これらの呼び出しを「モニター対象外」として識別できます。