自動ディスカバリーおよびモニター
自動ディスカバリーおよびモニターは、効率的で適応性の高いシステム管理を提供します。 手動構成をなくすことで、大規模なアプリケーションの変更にシームレスに適応し、物理コンポーネント、論理コンポーネント、およびビジネス・コンポーネントにわたる包括的な適応範囲を確保します。 このアプローチは、このような障害の影響を最小限に抑えるために、リアルタイムで異常を検出します。 この高度なモニタリング・ソリューションは、最新の動的アプリケーションの信頼性とパフォーマンスを維持するために不可欠な、システム管理に対する徹底的かつ適応的なアプローチを提供することに優れています。
「私たちの規模では、人間はすべてのシステムの状況を継続的にモニターすることはできません」。 - Netflix。」
これは、パフォーマンス・チューニングの専門家が情報を手動で分析して相関させ、実動のボトルネックとエラーを識別するために主に使用する従来の APM ツールに当てはまります。 規模と動的性が大きくなるにつれて、この作業は干し草の中から 1 本の針を探すようなものになります。 関連付ける必要がある可動部分とメトリックが多すぎます。
マシン・インテリジェンス・アプローチがシステム管理に適用される場合、コア・モデルとデータ・セットは障害ケーブルでなければなりません。 マイクロサービス・アプリケーションは、数百から数千のビルディング・ブロックで構成されており、常に進化しています。 そのため、すべてのブロックとその依存関係を理解する必要があります。これには、ディスカバリーに対する高度なアプローチが必要です。
自動ディスカバリーおよびモニターのコンポーネント
自動ディスカバリーおよびモニターは、物理コンポーネント、論理コンポーネント、およびビジネス・コンポーネントを対象としています。
物理コンポーネント
- データ・センターまたはアベイラビリティー・ゾーン -ゾーンは異なる大陸および地域に存在します。 これらのゾーンは、障害が発生することも、パフォーマンス特性が異なることもあります。
- ホスト/マシン -物理、仮想、またはサービスとして提供されます。 各ホストには、ボトルネックになる可能性のある CPU、メモリー、IO などのリソースがあります。 各ホストは 1 つのゾーンで実行されます。
- コンテナー -ホスト上で実行され、 Kubernetes や Apache Mesos などのスケジューラーによって管理できます。
- プロセス -コンテナー内またはホスト上で実行されます。 プロセスには、Java や PHP などのランタイム環境や、Tomcat、 Oracle、または Elasticsearchなどのミドルウェアを含めることができます。
- クラスター -多くのサービスが 1 つのグループまたはクラスターとして機能できるため、外部には統一された分散プロセスとして表示されます。 クラスター内のインスタンスの数は変化する可能性があり、クラスターのパフォーマンスに影響を与える可能性があります。
論理コンポーネント
- サービス -前述の物理ビルディング・ブロックの上で実行されている多数のインスタンスおよび異なるバージョンを持つことができる作業論理単位。
- エンドポイント -特定のコマンドをシステムの残りの部分に公開するためのサービスのパブリック API。
- アプリケーション・パースペクティブまたはアプリケーション -タグを使用して宣言された共通コンテキストによって定義された一連のサービスおよびエンドポイントのパースペクティブ。
- トレース -サービス間の同期通信と非同期通信のシーケンス。 サービスは相互に通信し、ユーザー要求の結果を配信します。 データ・フロー内のデータを変換するプロセスには、多くのサービスが含まれる場合があります。
- Calls -2 つのサービス間の要求。 トレースは、1 つ以上の呼び出しで構成されます。
ビジネス・コンポーネント
- ビジネス・サービス -固有のビジネス価値とサービスを提供するサービスとアプリケーションの構成。
- ビジネス・プロセス -プロセスを形成するテクニカル・トレースの組み合わせ。 例えば、e-コマースにおける「購入」トレース、ERP における注文トレース、および顧客への配達における FedExの物流のトレースを表すことができます。
異なるバージョンの何千ものサービス・インスタンスが、複数の大陸の異なるゾーンにある何百ものホストで実行され、そのユーザーにアプリケーションを提供するのが一般的です。 これにより、アプリケーションのサービス品質が保証され、ビジネス価値が提供されるように、完全に連携する必要があるコンポーネント間の依存関係のネットワークが作成されます。 従来のモニター・ツールでは、1 つのコンポーネントがしきい値を超えた場合にアラートが出されることがあります。 ただし、これらのコンポーネントの 1 つ以上が失敗しても、アプリケーションの品質が確実に影響を受けるわけではありません。 したがって、最新のモニター・ツールは、コンポーネントのネットワーク全体とそれらの依存関係を理解して、サービスの品質をモニター、分析、および予測する必要があります。
変更の識別およびカタログ
前述のように、サービスとその依存関係の数は、SOA ベースのアプリケーションの数の 10 倍から 100 倍になります。これは、モニター・ツールにとって課題となります。 継続的デリバリーの方法論、自動化ツール、およびコンテナー・プラットフォームにより、アプリケーションの変更率が飛躍的に増加するため、状況は悪化しています。 この動的環境では、手動で変更に対応したり、新しくデプロイされたブロックにモニター・ツールを継続的に構成したりすることは実用的ではありません。 例えば、オーケストレーション・ツールによってスピンアップされる新規コンテナーなどです。 そのため、最新のモニター・ソリューションでは、各ブロックを分析して理解する前に、それらのブロックを自動的かつ即時に検出する必要があります。
パーシスタンスを維持するには、後続の変更をリンクする必要があります。また、任意の時点でモードを再構成して、インシデントを調査することができます。
この変更は、以下の図に示すように、どのビルディング・ブロックでもいつでも発生する可能性があります。
Instana の包括的なディスカバリー・プロセス
Instana Dynamic APM ソリューションの重要な要素は、Instana エージェント・アーキテクチャー、特にセンサーを使用することです。 これらのセンサーはミニ・エージェントです。 ミニ・エージェントは、特定のエンティティーを接続およびモニターするように設計された小規模なプログラムです。 これらは、単一のエージェント (ホストごとに 1 つ) によって自動的に管理されます。このエージェントは、ホスト上にスタンドアロン・プロセスとしてデプロイされるか、コンテナー・スケジューラーを介してコンテナーとしてデプロイされます。
エージェントは、 AWS ゾーン、ホストまたは Kubernetes上で実行される Docker コンテナー、 HAProxy、 Nginx、JVM、 Spring Boot、 Postgres、 Cassandra 、または Elasticsearchなどのプロセス、およびこれらのクラスターなどの物理コンポーネントを自動的に検出します。 検出されたコンポーネントごとに、エージェントはその構成データを収集し、変更のモニターを開始します。 また、コンポーネントごとに 1 秒ごとに重要なメトリックを送信します。 エージェントは、JMX や Dropwizard などのサービスによって提供されるメトリックを自動的に検出して使用します。
その後、エージェントはサービス・コードへのトレース機能の注入を開始します。 例えば、HTTP 呼び出し、データベース呼び出し、および Elasticsearch に対する照会をインターセプトします。 これは、スタック・トレースやペイロードなどの各呼び出しのコンテキストをキャプチャーします。
このデータをトレースに結合し、依存関係とサービスを検出し、変更と問題を検出するインテリジェンスは、サーバー上で行われます。 そのため、エージェントは軽量であり、数千のホストに注入できます。
Instana は、新世代のモニター・ソリューションの自動、即時、および継続的なディスカバリー用に設計されています。
データの収集
Instana は、複数のセンサーを備えた単一のエージェントを使用しており、現在数百以上のテクノロジーをサポートしています。 詳しくは、 サポートされるテクノロジーの構成およびモニターを参照してください。 これらのセンサーは拡張機能ではありません。 センサーは、エージェントによって更新、ロード、およびアンロードされます。 オプションのコマンド・ライン・インターフェースは、エージェントの状態、個々のセンサー、およびエージェント・ログへのアクセスを提供します。
センサーは、特定のテクノロジーを自動的にディスカバーおよびモニターし、そのデータをエージェントに渡すように設計されています。 エージェントは、Instana Service Quality Engine へのすべての通信を管理します。 ディスカバリーの後、センサーは、コンポーネントの状態を正確に表すために、詳細データとメトリック・データを収集します。 特定のセンサーは、現在のテクノロジーに基づいてアプローチを調整することにより、それぞれのテクノロジーに関する特定のタイプのデータを収集します。
センサーは、以下のデータを収集します。
- 構成: 変更を追跡するために現在の設定と状態をカタログします。
- イベント: 初期ディスカバリー、状態変更 (オンラインおよびオフライン)、エンティティーの正常性ルールの失敗に基づいて問題またはインシデントをトリガーする組み込みイベント、および任意のエンティティーの個々のメトリックのしきい値に基づいて問題またはインシデントをトリガーするカスタム・イベント。
- トレース: プログラミング言語プラットフォームに基づいてトレースをキャプチャーします。
- メトリック: パフォーマンスを示すテクノロジーの定性的属性。
また、ディスカバリーはセンサー内で再帰的に行われます。 例えば、Java マシン・センサーはスタックを継続し、Tomcat や SpringBootなどのフレームワークをディスカバーし、エージェントが適切な追加センサーをロードするのを支援します。
このデータをトレースに結合し、依存関係とサービスを検出し、変更と問題を検出するインテリジェンスは、サーバー上で行われます。 そのため、エージェントは軽量であり、数千のホストに注入できます。
Instana バックエンドは、ストリーミング・テクノロジーを使用します。このテクノロジーは、エージェントからストリーミングされる 1 秒当たり数百万件のイベントを処理することができます。 このストリーミング・エンジンは効果的にリアルタイムであり、シチュエーションを処理してユーザーに表示するのに 3 秒しかかかりません。