コンセプト

「そして私たちの規模では、人間はすべてのシステムの状態を継続的に監視することはできません」。 – Netflix

これは、パフォーマンスチューニングの専門家が主に情報を手動で分析および相関させて、生産におけるボトルネックとエラーを識別するために使用されてきた従来のAPMツールに特に当てはまります。 より高いスケールとダイナミクスにより、このタスクは干し草の山で針を見つけるようなものです。 相関させるには可動部分とメトリックが多すぎます。

マシンインテリジェンスアプローチをシステム管理に適用する場合、コアモデルとデータセットは完璧でなければなりません。 マイクロサービスアプリケーションは、数百から数千のビルディングブロックで構成され、すべてが絶えず進化しています。 したがって、すべてのブロックとその依存関係を理解する必要があり、発見への高度なアプローチが求められるのです。

コンポーネント

アプリケーション監視でカバーする必要のある構成要素は :

物理的なコンポーネント

  • データセンター/アベイラビリティーゾーン – ゾーンは、異なる大陸および地域に存在できます。 それらは失敗するか、異なるパフォーマンス特性を持つ可能性があります。
  • ホスト/マシン –  物理、仮想、または「サービスとして」のいずれか。 各ホストには、ボトルネックになる可能性のあるCPU、メモリ、IOなどのリソースがあります。 各ホストはひとつのゾーンで実行されます。
  • コンテナ –  ホスト上で実行され、KubernetesやApache Mesosなどのスケジューラーで管理できます。
  • プロセス –  コンテナ(通常はコンテナごとにひとつ)またはホストで実行します。 JavaやPHPなどのランタイム環境だけでなく、Tomcat、Oracle、Elasticsearchなどのミドルウェアも可能です。
  • クラスター –  多くのサービスはグループまたはクラスターとして機能できるため、外部の世界にはひとつの分散プロセスとして表示されます。 クラスター内のインスタンスの数は変化する可能性があり、クラスターのパフォーマンスに影響を与える可能性があります。

論理コンポーネント

  • サービス –  前述の物理的なビルディングブロック上で実行される多くのインスタンスと異なるバージョンを持つことができる論理的な作業単位。
  • エンドポイント –  サービスのパブリックAPI。特定のコマンドをシステムの残りの部分に公開します。
  • アプリケーションパースペクティブ(アプリケーションとも呼ばれる) –  共通のコンテキスト(タグを使用して宣言)で定義された一連のサービスとエンドポイントのパースペクティブ。
  • トレース – トレースは、サービス間の同期および非同期通信のシーケンスです。 サービスは互いに対話し、ユーザー要求の結果を提供します。 データフロー内のデータの変換には、多くのサービスが含まれます。
  • コー​​ル 2つのサービス間の要求を記述します。 トレースは、ひとつ以上の呼び出しで構成されます。

ビジネスコンポーネント

  • 業務サービス – 独自のビジネス価値とサービスを提供するサービスとアプリケーションの構成にすることができます。
  • ビジネス プロセス – プロセスを形成する技術的なトレースの組み合わせ。 例として、eコマースでの「購入」トレース、ERPでの注文トレース、それに続く顧客への配送におけるFedExのロジスティクスのトレースがあります。

異なるバージョンの数千のサービスインスタンスが、複数の大陸の異なるゾーンの数百のホストで実行され、ユーザーにアプリケーションを提供することは珍しくありません。 これにより、コンポーネント間の依存関係のネットワークが作成され、アプリケーションのサービス品質が確保され、ビジネス価値がもたらされるように、完全に連携する必要があります。 従来の監視ツールは、単一のコンポーネントがしきい値を超えると警告を発しますが、これらのコンポーネントのひとつまたは多くが故障しても、アプリケーションの品質が確実に影響を受けるわけではありません。 したがって、最新の監視ツールは、サービスの品質を監視、分析、予測するために、コンポーネントのネットワーク全体とその依存関係を理解する必要があります。

変更の特定とカタログ化

説明したように、サービスの数とその依存関係はSOAベースのアプリケーションよりも10〜100倍多く、監視ツールに課題をもたらします。 状況はさらに悪化しています。継続的配信方法、自動化ツール、コンテナプラットフォームは、アプリケーションの変更率を指数関数的に増加させ、人間が変更に対応したり、監視ツールを新しく展開されたブロックに継続的に構成することを不可能にします(例:オーケストレーションツールによってスピンアップされた新しいコンテナー)。 そのため、最新の監視ソリューションでは、ブロックを分析して理解する前に、すべてのブロックを自動的かつ即時に検出する必要があります。

その後、変更を以前のスナップショットにリンクして、永続性を維持し、特定の時点でモードを再構築してインシデントを調査できるようにする必要があります。

変更はいつでもすべての構成要素で発生する可能性があります。 各コンポーネントの変更例については、次の図を参照してください。

auto-discovery-2

Instanaがどのようにしてパズルのすべてのピースを発見するか

Instana Dynamic APMソリューションの重要な要素は、エージェントアーキテクチャ、具体的にはセンサーの使用です。 センサーはミニエージェントです。ひとつのものを接続して監視するために特別に設計された小さなプログラムです。 それらはシングルエージェント(ホストごとにひとつ)によって自動的に管理され、ホスト上のスタンドアロンプ​​ロセスとして、またはコンテナスケジューラを介したコンテナとして展開されます(データ収集のエージェントとセンサーの詳細をご覧ください)。

エージェントはまず、AWSのゾーン、ホストまたはKubernetesで実行されているDockerコンテナー、HAProxy、Nginx、JVM、Spring Boot、Postgres、Cassandra、Elasticsearchなどのプロセス、およびCassandraクラスターなどのこれらのプロセスのクラスターなどの物理コンポーネントを自動的に検出します。 検出した各コンポーネントについて、エージェントは構成データを収集し、変更の監視を開始します。 また、一秒ごとに各コンポーネントの重要なメトリックの送信を開始します。 エージェントは、JMXやDropwizardなどのサービスによって提供されるメトリックを自動的に検出して利用します。
auto-discovery-1

次のステップとして、エージェントはサービスコードにトレース機能を挿入し始めます。 たとえば、HTTP呼び出し、データベース呼び出し、Elasticsearchへのクエリをインターセプトします。 スタックトレースやペイロードなど、各呼び出しのコンテキストをキャプチャします。

このデータをトレースに結合し、依存関係とサービスを検出し、変更と問題を検出するインテリジェンスはサーバー上で実行されます。 したがって、エージェントは軽量であり、数千のホストに注入できます。

自動、即時、および継続的な検出は、新世代の監視ソリューションの要件です。 Instanaは、この要件に基づいて基本的に設計されています。