アプリケーションのモニタリング
Instana は、次世代の APM と、それらのサービス、エンドポイント、およびアプリケーション・パースペクティブのアプリケーション階層を紹介しています。 主な目的は、ビジネスのサービス品質のモニターを簡素化することです。 Instanaは、トレースとコンポーネントセンサーから収集したデータに基づいて、実装されているサービスから直接アプリケーションランドスケープを検出します。
従来の Application Performance Management （APM）ソリューションは、アプリケーションのパフォーマンスと可用性を管理するものだった。
APM ツール用のアプリケーションは、エージェントを使用してモニターされるコード・ランタイム (JVM や CLR など) の静的セットです。 通常、アプリケーションは各エージェントで構成パラメーターとして定義されます。
この概念は、従来型の 3 層アプリケーションに適したモデルでしたが、最新の (マイクロ) サービス・アプリケーションには有効ではありません。 サービスは、必ずしも 1 つのみのアプリケーションに属するとは限りません。 例えば、ある企業のオンライン・ストアとPOSの両方で利用されるクレジットカード決済サービスを考えてみよう。 各サービスをアプリケーションとして定義すれば、この問題は解決するかもしれないが、次のような新たな課題が生じる：
- 監視するアプリケーションが多すぎる ：すべてのサービスをアプリケーションとして扱うと、何百、何千ものアプリケーションが発生する。 ダッシュボードを使用してアプリケーションを監視することは、データの過負荷のために実用的ではなくなります。
- 文脈の喪失 ：すべてのサービスを個別に扱うと、依存関係や、問題の広い文脈におけるサービスの役割を理解することが難しくなる。
サマリー
待ち時間の分布
待ち時間分布図は、アプリケーション、サービス、またはエンドポイントの待ち時間関連の問題を調査するのに最適です。 チャート上でレイテンシーの範囲を選択し、"View in Analytics "メニューを使用することで、 Unbounded Analyticsで特定のコールをさらに調査することができます。
インフラの問題と変更
サマリー］ タブには、アプリケーション、サービス、またはエンドポイントに関連するインフラストラクチャの問題と変更が表示されます。 この情報は、誤発信率や遅延の増加など、興味深いアプリケーション・メトリクスの変化との相関関係を特定するのに役立ちます。
特定の問題または変更について詳しく知るには、チャート上で目的の時刻範囲を選択し、 イベントの表示 メニュー項目をクリックします。これにより、 イベント ビューが表示されます。
処理時間
処理時間チャートは、アプリケーション、サービス、またはエンドポイント自体（Self ）での処理に費やされた時間と、下流の依存関係の呼び出しに費やされた時間を理解するのに役立ちます。このチャートは、呼び出しの種類（ Http、 Database、 Messaging、 Rpc、 SDK など）ごとに分類されています。
例えば、 Shop サービスへの呼び出しの待ち時間が 1000ms、 Shop サービスが 300ms を要する Payment サービスへの HTTP 呼び出しを行い、次に 200ms を要する Catalog サービスへの別のデータベース呼び出しを行う場合、 Shop サービスの自己処理時間は 1000-300-200=500ms となる。
タイム・シフト
メトリックスを過去の時間枠と比較するには、画像のようにタイムシフト機能を使用します。 ヒストリカル・データに対してメトリックを比較する場合は、精度が低下することに注意してください。
アプリケーション依存関係マップ
依存関係マップは、各アプリケーションで利用可能であり、以下を提供する、
- アプリケーション内のサービス依存関係の概要。
- 通信パスとスループットを把握できる、サービス間の呼び出しのビジュアル表示。
- アプリケーションのアーキテクチャーを迅速に理解できる各種レイアウト。
- サービス・ビュー (ダッシュボード、フロー、呼び出し、および問題) への快適なアクセス。
エラー・メッセージ
エラーメッセージは、サービスのコード実行中に発生したエラーから収集されたメッセージです。 例えば、処理中に例外がスローされ、アプリケーション・コードによってキャッチまたは処理されなかった場合、その例外は 「エラーメッセージ 」タブに表示されます。 例えば、サーブレットの doGet メソッドで未処理の例外が発生すると、要求は HTTP 500 で応答されることになります。
ログ・メッセージ
ログ・メッセージは、計装化されたロギング・ライブラリやフレームワークから収集される。 例えば、 サポートされているライブラリのリストの 「ロギング」のセクションを参照してください。 サービスがロギングライブラリを通して重大度 WARN 以上のログメッセージを書き込むと、そのメッセージはログメッセージタブに表示されます。 また、キャプチャされたログメッセージは、そのトレースのコンテキストでトレースの詳細に表示されます。 ERROR 以上の重大度でログ・メッセージが書き込まれた場合は、エラーとしてマークされます。 重要度が WARN 以下のログメッセージは追跡されない。
インフラストラクチャー
アプリケーションパースペクティブ］ビューまたは［サービス］ダッシュボードから、 ［インフラストラクチャ監視］ ビューに表示されている対応するインフラストラクチャコンポーネントに移動できます。
「モニター対象外」インフラストラクチャー・コンポーネント
アプリケーションやサービスのインフラコンポーネントのリストには、「監視対象外」のホスト、コンテナ、プロセスが含まれることがある。
Unmonitored "コンポーネントは、あるサービスに対する一部またはすべてのコールについて、それを特定のインフラストラクチャー・コンポーネントにリンクすることができなかったことを示す。 サービスは "論理的 "なエンティティであり、通常、監視プロセスを通じてインフラストラクチャ・コンポーネントにリンクされる。 これはサードパーティーのウェブサービスには適用されない。サードパーティーのウェブサービスは監視されないが、ホスト名＋パスに基づいてサービスとエンドポイントが作成される。 ホストもプロセスも不明であるため、これらのサービスは「不明」のインフラストラクチャー・コンポーネントに関連付けられている。
スマート・アラート
構成されているすべてのスマート・アラートのリストが表示されます。 アラートをクリックして、その構成の表示、変更、または改訂履歴の表示を行います。 必要に応じて、アラートの無効化や削除も行うことができます。
アラートの追加方法については、 スマートアラートのドキュメントを参照してください。
タイムレンジ調整
Instana のダッシュボードや分析で使用される時間範囲は、タイムピッカーで選択された時間範囲と若干異なる場合があります。 ダッシュボードまたはアナリティクスの時間範囲は、最初と最後の部分バケットを除きます。 例えば、1月20日午後3時15分にタイムピッカーで「 直近24時間」 プリセットを選択すると、時間範囲は1月19日午後3時30分 January–3:00 1月20日午後3時00分に調整されます。 この調整は、それぞれのチャートの粒度が30分であるために行われる。 時間範囲を調整することで、同じページ上の異なるウィジェット間での一貫性を確保し、部分的なバケットを予期せぬ測定値の傾向（例えば、コール数の減少など）と誤解することを避ける。
概算データ
ダッシュボードを表示したり、アナリティクスで過去 7 日を超える特定の期間にわたってクエリを実行したりすると、さまざまなウィジェットに近似データ インジケータが表示されることがあります。これは、Instana がクエリを提供するために、統計的に有意なトレースと呼び出しの数を減らしてアクセスしていることを示すために使用されます。 例:
めったに発生しないトレースおよび呼び出しは、そのようなシナリオでは表示されない可能性があります。
コールレベル・メトリクスのサンプリング精度に関する注意
システムは、トレースIDハッシュに基づくランダムサンプリングを使用し、トレースレベルでの一貫したサンプリングを保証します。 しかし、これはコールレベルのメトリクスを分析する際に意味を持つ：
- サンプリングはコールごとではなく、トレースごとに行われる。 トレースサイズが大きく異なる場合（例えば、トレースあたりのコール数）、コールレベルのデータが歪む可能性がある。
- 例えば、 2.4 万コール以上の単一トレースは、システムがそれをサンプリングに含める場合、コールレベルのメトリクスに大きな影響を与える可能性がある。
- これは期待された動作であり、欠陥ではない。 これは、トレースベースのサンプリングがどのように機能するかを反映している。