コンセプト

Dynamic Graphは、Instanaを強化するコアテクノロジーです。 これは、コンポーネントのすべての物理的および論理的な依存関係を理解するアプリケーションのモデルです。 コンポーネントは、ホスト、OS、JVM、Cassandraノード、MySQLなど、アプリケーションの個々の部分です。グラフには、物理​​コンポーネント以上のものがあります。トレース、アプリケーション、サービス、クラスター、テーブルスペースなどの論理コンポーネントも含まれます。 コンポーネントとその依存関係は、Instana AgentとSensorによって自動的に検出されます。つまり、グラフはリアルタイムで最新の状態に保たれます。

グラフ内のすべてのノードは、メトリック、構成データ、セマンティック知識と機械学習アプローチに基づいて計算されたヘルス値などの状態情報で継続的に更新されます。 また、この知識はグラフ内の依存関係を分析して、サービスやアプリケーションなどの論理グループを見つけ、そのレベルへの影響を理解し、問題の重大度を導き出します。 グラフ全体が永続的であるため、Instanaアプリケーションは時間内で前後に移動して、グラフの知識ベース全体を多くの運用上のユースケースに活用できます。

ダイナミックグラフに基づいて、アプリケーションまたはサービスに対する変更と問題の影響を計算し、影響が重大な場合、相関する問題と変更のセットを組み合わせてインシデントとします。 インシデントは、問題と変更が時間とともにどのように進化するかを示し、Instanaがインシデントの根本原因を直接指すことを可能にします。 変更があれば自動的に検出され、周囲のノードへの影響を計算します。 変更は、正常性の低下(「問題」と呼ばれる)、構成の変更、プロセス、コンテナ、またはサーバーの展開または出現/消失である可能性があります。

これを具体的にするために、Elasticsearchクラスターを使用してWebインターフェースを使用して製品を検索する単純なアプリケーションをどのようにモデル化して理解するかを見てみましょう。 実際、これはひとつのマイクロサービスにすぎませんが、Instanaのクラスターと依存関係をどのように理解するかを示しています。

動的アプリケーションについて

Elasticsearchクラスターの動的グラフのモデルを開発して、これがどのように機能し、分散環境や流動環境でこれが役立つ理由を理解しましょう。

技術的にはJavaアプリケーションである単一のElasticsearchノードから開始するため、グラフは次のようになります。

dynamic-graph-2

ノードには、ホストで自動的に検出されたコンポーネントとそれらの関係が表示されます。 Elasticsearchノードの場合、JVM、プロセス、Dockerコンテナー(ノードがコンテナー内で実行されている場合)、およびそれが実行されているホストを検出します。 Amazon AWSのようなクラウド環境で実行されている場合、その可用性ゾーンも検出し、グラフに追加します。

各ノードには、プロパティ(JVM_Version = 1.7.21など)およびリアルタイムの関連するすべてのメトリック(ホストのI / Oおよびネットワーク統計、JVMのガベージコレクション統計、ESノードによってインデックス付けされたドキュメント数など)があります。

ノード間のエッジは、それらの関係を表します。 この場合、これらは「実行」関係です。 たとえば、ESノードはJVM上で「実行」されます。

Elasticsearchクラスターの場合、クラスターを構築している複数のノードがあります。

dynamic-graph-3

この場合、グラフ全体にクラスターノードの状態と状態を表すクラスターノードを追加しました。 クラスターを構成するXNUMXつすべてのElasticsearchノードに依存しています。

Elasticsearchの論理単位はインデックスです。インデックスは、Elasticsearchのドキュメントにアクセスするためにアプリケーションによって使用されます。 クラスター内のESノードに配布されるシャードで物理的に構造化されます。

グラフにインデックスを追加して、アプリケーションで使用されるインデックスの統計と健全性を理解します。

dynamic-graph-4

さらに、簡単なSpring BootアプリケーションでElasticsearchインデックスにアクセスすると仮定します。

これで、グラフにSpring Bootアプリケーションが含まれるようになりました。

dynamic-graph-5

Instana Javaセンサーは分散トレースを記録するため、InstanaはSpring BootアプリケーションがElasticsearchインデックスにアクセスするかどうかを認識します。 これらのトレースをグラフ内の論理コンポーネントと相関させ、さまざまなトレースの統計とヘルスを追跡します。

このグラフを使用して、さまざまなElasticsearchの問題を理解し、サービス全体の健全性への影響を分析する方法を示すことができます。

2つの異なる問題があると仮定しましょう。

  1. ひとつのホストのI/O問題により、インデックス/シャードデータの読み取り/書き込みが遅くなります。
  2. ひとつのElasticsearchノードのスレッドプールはオーバーロードされているため、スレッドが解放されるまでリクエストを処理できないため、リクエストはキューに入れられます。

dynamic-graph-8

dynamic-graph-9

この場合、ホスト(1)にI/O問題が発生し始めます。 私たちのヘルスインテリジェンスは、ホストの健康状態を黄色で表示し、問題トラッカーに問題を送信します。 数分後、ES(Elasticsearch)ノード(2)がこの影響を受け、ヘルスインテリジェンスは、このノードのスループットがこのノードを黄色としてマークするレベルに低下することを確認し、問題を再度発生させます。 エンジンは2つの問題を相互に関連付けてひとつのインシデントに追加しますが、この場合は問題としてマークされませんが、クラスターの状態は良好であるため、サービス品質に影響しません。

次に、別のESノード(3)で、クエリを処理するためのスレッドプールがいっぱいになり、要求がプールされます。 これによりパフォーマンスが大きく影響されるため、エンジンはノードのステータスを赤としてマークします。 これはESクラスターに影響を与え(4)、スループットが低下するにつれて黄色に変わります。 生成された2つの問題は、最初のインシデントに集約されます。

クラスターはインデックスのパフォーマンスに影響を与えるため(5)、インデックスに黄色のマークを付け、インシデントに問題を追加します。 これで、製品検索トランザクションのパフォーマンスが影響を受け、パフォーマンスヘルス分析によりトランザクションが黄色(6)としてマークされ、アプリケーションのヘルスにも影響します(7)。

アプリケーションとトランザクションの両方が影響を受けると、製品検索のパフォーマンスが低下し、ユーザーが影響を受けることを示す黄色のステータスでインシデントが実際に発生します。 I/O問題とThreadpool問題という2つの根本原因へのパスが強調表示されています。 スクリーンショットに見られるように、Instanaはインシデントの進化を示し、ユーザーは問題が発生した時点でコンポーネントにドリルダウンできます-その時点での正確な履歴環境とメトリックを含みます。

これは、Instanaのユニークな機能を示しています。

  • グラフを使用して物理、プロセス、およびトレース情報を組み合わせて、依存関係を理解し​​ます。
  • 単一コンポーネントの正常性だけでなく、クラスター、アプリケーション、およびトレースの正常性も理解するためのインテリジェンス。
  • 問題が重大かどうかを理解するためのインテリジェントな影響分析。
  • 問題の根本原因を示し、実用的な情報とコンテキストを提供します。
  • グラフ、そのプロパティ、メトリック、変更および問題の履歴を保持し、すべてのコンポーネントの状態と依存関係を明確に表示して特定の問題を分析する「タイムシフト」機能を提供します。

現代の環境で根本原因を見つけることは、今後数年間でさらに難しくなります。 上記の簡単な例では、根本原因を見つけることは、コンテキスト、依存関係、および影響を理解することなく簡単な作業ではないことを示しています。 新しいリリースが頻繁にプッシュされることで、常にサービスを追加および削除するマイクロサービスに基づく「リキッド」システムを考えてください。Instanaは、状態と状態をリアルタイムで追跡し、これらの変更または問題の影響を理解します。 これはすべて、手動構成なしでリアルタイムに行われます。

用語

ゾーン

ゾーンは異なる大陸および地域に存在できます。 それらは失敗するか、異なるパフォーマンス特性を持つ可能性があります。

ホスト/マシン

物理、仮想、または「サービスとして」。 各ホストには、ボトルネックになる可能性のあるCPU、メモリ、IOなどのリソースがあります。 各ホストはひとつのゾーンで実行されます。

コンテナ

ホスト上で実行され、KubernetesやApache Mesosなどのスケジューラーで管理できます。

プロセス

コンテナ(通常はコンテナごとにひとつ)またはホストで実行します。 JavaやPHPなどのランタイム環境だけでなく、Tomcat、Oracle、Elasticsearchなどのミドルウェアも可能です。

クラスタ

多くのサービスはグループまたはクラスターとして機能できるため、外部の世界にはひとつの分散プロセスとして表示されます。 クラスター内のインスタンスの数は変化する可能性があり、クラスターのパフォーマンスに影響を与える可能性があります。

サービス

前述の物理的なビルディングブロック上で実行される多くのインスタンスと異なるバージョンを持つことができる論理的な作業単位。

エンドポイント

特定のコマンドをシステムの残りの部分に公開するサービスのパブリックAPI。

アプリケーションの視点

共通のコンテキスト(タグを使用して宣言)で定義された一連のサービスとエンドポイントのパースペクティブ。

トレース

トレースは、サービスエンドポイント間の同期呼び出しと非同期呼び出しのシーケンスです。 サービスは互いに対話し、ユーザー要求の結果を提供します。 データフロー内のデータの変換には、多くのサービスが含まれます。

コー​​ル

監視対象プロセス内のアクティビティ、通常は2つのサービス間のリクエストを記述します。 トレースは、ひとつ以上の呼び出しで構成されます。 コールは、ひとつまたは2つのスパンで構成されます。

  • エントリースパン: たとえば、計装されていないプロセスから計装されたプロセスへのHTTP要求。
  • エグジットスパン: たとえば、インストルメント済みプロセスからデータベースへのデータベース呼び出し(データベースはインストルメント化されていません)。
  • エグジットとエントリーのスパンのペア: たとえば、インストルメント済みプロセスから別のインストルメント済みプロセスへのHTTP要求。 クライアントプロセスのエグジットスパンと、応答を処理するプロセスのエントリースパンがあります。
  • 中間スパン: たとえば、SDK経由で追加されたカスタムスパン、インストルメント済みインプロセスキャッシング、またはインストルメント済みビューテクノロジー。

スパン

Instanaトレーサーによってデータが収集される最小の粒度レベル。 スパンは、監視対象プロセス内のアクティビティを表します。たとえば、着信または発信HTTPリクエスト、受信メッセージ、データベース呼び出しなどです。

  • セルフタイム: セルフタイムはスパンのプロパティであり、基礎となるサービスを呼び出さずにスパン自体で費やされた時間を示します。
  • 待ち時間: 待機時間は、基礎となるサービスへの呼び出しが戻るまで待機するのに費やされた時間を示します。
  • ネットワーク時間: ネットワーク時間は、エグジットスパンとエントリースパンの間に常に存在し、エグジットスパンとエントリースパンの間の時間を表します。

使用法

ダイナミックグラフは自動的に作成および更新されます。 サービスなどの一部のコンポーネントの定義は、サービス構成を通じてさらに指定できます。

強力なダイナミックフォーカス機能を使用して、グラフのトラバースとスコープを実現できます。