トレースおよび呼び出しの分析

「Unbounded Analytics」 でトレースを確認します。ここでは、 Instana によって収集されたトレースや呼び出しを調査できます。 それぞれの呼び出しでのアプリケーションの動作をわかりやすく示すために、呼び出しがシステムに着信するたびに、各呼び出しをモニターします。

トレースの表示

  1. サイドバーで「アプリケーション」をクリックします。
  2. 「アプリケーション」ダッシュボードで、アプリケーションまたはサービスを選択します。
  3. アプリケーションまたはサービスのダッシュボードで、「呼び出しの分析」をクリックします。
  4. 「分析」ダッシュボードでは、アプリケーション、サービス、およびエンドポイントごとに呼び出しを分析し、Instana が表示するデータをサービス別、エンドポイント別、および呼び出し名別にそれぞれ細分化できます。 「 アプリケーション」 で、 「通話 」または「 トレース」 を選択します。
  5. グループをクリックしてから、トレースを選択します。

トレース分析の表示

トレース分析

トレースまたは呼び出しのフィルタリングとグループ化

「分析」 ダッシュボードでは、任意のタグを使用してトレースまたは呼び出しをフィルタリングおよびグループ化できます。 分析呼び出しでは、ANDOR の論理演算子を使用してフィルターを接続し、大括弧を使用してグループ化できます。 トレースの分析では、AND 演算子のみを使用できます。

照会ビルダー

データをフィルターに掛けるには、2 つのアプローチがあります。

  • 照会ビルダー
  • フィルター・サイドバー

両方とも独立して使用できますが、組み合わせると良好な結果が得られます。

照会ビルダー

アナリティクスダッシュボードのクエリビルダー を使用して、最初の結果セットを絞り込んでください。 「フィルターの追加」をクリックすると、application.name タグ、service.name タグ、および endpoint.name タグを、agent.taghost.name などのインフラストラクチャー・エンティティー・タグとともに、呼び出しのソースと宛先の両方に適用できます。 デフォルトでは、宛先に適用されます。 ソースに変更するには、タグ名の前のセレクターをクリックし、ソースを選択します。 ソースと宛先を組み合わせることで、「この 2 つのサービス間のすべての呼び出しを表示する」や、「自分の agent.zone「production」から agent.zone「test」に対して発行されたすべての呼び出しを表示する」などの照会を作成できます。 ソースまたは宛先の選択は、呼び出し自体のプロパティーであり、ソースや宛先から独立している、call.http.pathcall.tag などの呼び出しタグでは使用できません。

グループ化を適用するには、「グループの追加」をクリックし、いずれか 1 つのタグを選択します。 デフォルトのグループ化では、エンドポイント名 (endpoint.name) タグが使用されます。 フィルターに一致する個々のトレースおよび呼び出しを検査するには、グループを拡張して結果をピークにするか、 「このグループにフォーカス」 をクリックしてグループ化を解除し、選択したグループの値で結果をさらにフィルターに掛けることができます。 タグは呼び出しのソースまたは宛先に適用できるため、 この 1 つのサービスに対するすべての呼び出しを発信者別に分類して表示などの照会を表現できます。 どのグループにも一致しない呼び出しは、 Tag not presentという名前の特別なグループに表示されます。例えば、 agent.zone の場合、これは 'agent.zone' タグを使用しない呼び出しになります。 一致しない agent.zone を結果から削除するには、is present 演算子を使用して追加フィルターを適用します。 ソースと宛先によるグループ化は、「トレース分析」でも使用できません。このビューで使用可能なグループは、特定の呼び出しのソースまたは宛先から独立しているためです。

前の例では、アプリケーションの Catalogue (user-journey) でフィルターに掛け、エンドポイント名でグループ化して呼び出しをリストしています。

フィルター・サイドバー

クエリビルダーのフィルターを適用して取得した結果をもとに、アナリティクスダッシュボードの「 フィルターサイドバー 」でさらにフィルターを追加することで、データを素早く絞り込むことができます。

サイドバー

同じタグ・カテゴリー内の項目は論理 OR によって連結され、異なるタグ・カテゴリーは論理 AND によって連結されます。 フィルターサイドバーで選択されたすべてのフィルターは、適用済みのクエリビルダーのフィルターに対して論理積( AND )で適用されます。 フィルターサイドバーのヘッダーには、すべてのタグにわたる選択項目の合計数が表示され、適用されているサイドバーフィルターをすべて素早く解除することができます。

注意: 現在、「トレースの分析」では、単一タグの複数選択はサポートされていません。

前の例では、クエリビルダーで「 Catalogue (user-journey) アプリケーション」でフィルタリングし、 フィルタサイドバーで「サービス」 catalogue-demo または「 選択 discount-svc 済み」でフィルタリングしています。

フィルタサイドバーのタグのいずれかで素早くグループ化するには、グループ化に適した各タグの横に表示されているグループ化ボタンをクリックしてください。 これが、前述した、照会ビルダーでグループ化を素早く構成する方法です。 同様に、特定のフィルター・サイドバー・タグがグループ化することもできます。現在グループ化に使用されているタグ上のグループ化解除ボタンをクリックすることで、グループ化を解除することもできます。

既知の制限

ログ・タグによる呼び出しのグループ化: log.level または log.messageによって呼び出しをグループ化する場合、特殊グループ Tag not present は、他のタグの場合のようには表現されません。

待ち時間の分布

「待ち時間の分布」グラフを使用して、トレースと呼び出しの待ち時間を検査できます。 チャート上で遅延範囲を選択すると、フィルターがそれに応じて調整されます。 表内の以下の結果は、指定された待ち時間範囲内のトレースまたは呼び出しのみを表示するように更新されます。

待ち時間分布ビュー

トレース・ビュー

トレース・ビューを表示するには、「分析」ダッシュボードでグループを選択してから、トレースをクリックします。 呼び出しを選択すると、その呼び出しがそのトレースのコンテキストで表示されます。

トレース・ビュー

サマリーの詳細

トレースのサマリーの詳細には、以下が含まれます。

  • トレース名 (通常は HTTP エントリー)。
  • 発生元のサービスの名前。
  • タイプまたはテクノロジー。
  • コア KPI:
    • 他のサービスへのサブ呼び出し。
    • エラーの呼び出しの数。
    • トレース内のエラーの数。
    • トレース内の警告の数。
    • trace duration. トレース内の最初の呼び出しの開始から最後の呼び出しの終了までの間隔。

タイムライン

トレースのタイムラインには、以下が表示されます。

  • トレースを開始した時刻。
  • トレース全体で呼び出されたサービスの発生順。

呼び出しチェーンはルート・エレメント (span) からハングします。 単純な 3 層システムでは、標準的な深さは 4 レベルです。 これに対して、分散サービス・アーキテクチャーまたはマイクロサービス・アーキテクチャーを備えたシステムでは、さらに長くなることが予期されます。 データベース項目ごとに 1 つの HTTP 呼び出しなど、トレースまたは定期的な呼び出しパターンのサブコールが長い場合は、呼び出し構造の優れた概要がタイムラインに表示されます。

スパンの詳細を表示するには、タイムライン・グラフ内のスパンをクリックします。 特定の呼び出し内で時間が費やされた場所の詳細を表示するには、タイムライン・グラフに表示されている呼び出しの上にカーソルを移動します。

呼び出しの詳細には、以下の種類の時間が含まれます。

  • Self: 呼び出しがダウンストリーム呼び出しの外部で費やす時間 (つまり、呼び出し内で費やされた時間)。
  • Waiting: すべてのダウンストリーム呼び出しが完了するのを待機するために呼び出しが費やした時間。
  • Network: 呼び出し元の Exit Span Time と呼び出しの Entry Span Time との間の時差。
  • Total: 呼び出しの合計時間です。

サービス

タイムライン・グラフの下にリストされるサービスでは、サービスごとにすべての呼び出しがまとめられ、呼び出し回数、集約時間、発生したエラーがリストされます。 各サービスには独自の色が付いています (この例では、ショップは青、製品検索は緑です)。 サービスを選択すると、その詳細が「アプリケーションとサービス」ダッシュボードに表示されます。

呼び出し

コール・ビュー

トレース・ツリーには、アップストリームおよびダウンストリームのサービス呼び出しの構造が、呼び出しのタイプとともに表示されます。 特定の呼び出しを探索するには、トレース・ツリーの個々の部分の表示を展開または省略します。 呼び出しを選択すると、その詳細が「サービスとエンドポイント」ダッシュボードに表示されます。

孤立した呼び出し

呼び出しの親呼び出しが欠落している場合、その呼び出しは孤立呼び出しと見なされます。 終了していない、または別の APM ツールに送信されているなど、さまざまな理由でコールが欠落している可能性があります。 親子関係により、呼び出しツリー内の呼び出しの位置が決定されるため、孤立呼び出しの位置は不明です。 孤立呼び出しは、ルート呼び出しに直接付加されます。 ルートと孤立呼び出しの間のエッジにインディケーター・アイコンが表示されます。

孤立呼び出し

呼び出しの詳細

呼び出し詳細サイドバーを表示するには、タイムライン・グラフで呼び出しを選択します。 表示される詳細には、呼び出しのソースと宛先、エラー、状況コード、およびスタック・トレースが含まれます。

トレースを保存する

表示されているトレースを手動で長期保存(最長13か月)するには、 「トレースを保存」 ボタンをクリックしてください。 あるいは、「トレース詳細」ビューを15秒以上表示したままにすることで、トレースを自動的に保存することもできます。 ただし、大規模なトレースの長期保存はサポートされていません。

ログとエラーのキャプチャー

サービスが誤った応答を返すか、ERROR レベルまたは WARN レベル (またはフレームワークに応じた類似のレベル) を検出すると、Instana はエラーを自動的にキャプチャーします。

短い Exit 呼び出しの自動集計

Instana は常に、ユーザーがサービス対話を最大限に理解できるようにし、実際のアプリケーションへの影響を最小限に抑えようとします。 ただし、状況によっては、その目的を達成するために Instana がデータを破棄しなければならない場合があります。

システム内の一般的な問題は、いわゆる 1+N 照会問題です。これは、コードが 1 回のデータベース呼び出しを実行して項目のリストを取得し、その後に N 回の個別呼び出しを実行して個々の項目を取得するという状況を記述します。 この問題を修正するには、通常、1 つの呼び出しだけを実行し、他の呼び出しをその呼び出しに結合します。

呼び出し名の横にあるアイコンは、バッチにまとめられた要求の数を示します。 呼び出しの詳細は、最も重要なサービス呼び出し (例えば、所要時間が最も長い要求やエラーが発生した要求) の詳細と一致します。 表示された呼び出しの所要時間とエラー件数は、バッチにまとめられているすべての呼び出しから集計されます。

呼び出しバッチ処理の例

サービス対話の集計は、以下の制約内でのみ行われます。

  • 類似タイプのアクセス・パターンが高頻度であり、反復が多い
  • 個別サービス呼び出しの所要時間が 10 ミリ秒未満
  • 呼び出し間の時間が 10 ミリ秒未満

パラメーターのキャプチャー

パフォーマンスへの影響が懸念されるため、現時点では、 Instana のトレースセンサーはメソッドのパラメータや戻り値を自動的に取得しません。 追加データをオンデマンドでキャプチャーするには、SDK を使用します。

長時間実行タスク

タイムアウト、高負荷、またはその他の環境条件の数が原因で、呼び出しが応答するまでにかなりの時間がかかる場合があります。 トレースには、このような呼び出しが何十個も何百個も含まれている可能性があります。 Instana は、ユーザーにトレース情報をできるだけ早く提供することを目的としているため、実行時間が長いスパンは、最初はプレースホルダーに置き換えられます。 長期実行スパンが最終的に戻ると、プレースホルダーは再び正しい呼び出し情報に置き換えられます。

バッチ処理によるトレース処理

スパン処理パイプラインのハイパフォーマンスおよびほぼリアルタイムの性質により、遅れて到着するスパンと非同期に到着するスパンは、結果のトレースにリンクされるときに若干異なります。 トレース・ビューの情報ボックスがユーザーに表示され、誤った形式のトレースに関する情報が提供されます。

Instana をご利用のお客様には、以下の現象が発生する可能性があります:

  • トレース・ビューでは、トレースのすべてのサブコールが表示されるわけではありません。
  • 同じトレース ID を持つ複数のトレースがリストされ、全体のトレースが部分的に表示されます。
  • 呼び出しは、対応するアプリケーション・パースペクティブにマップされない可能性があり、その後、Unbounded Analytics で欠落する可能性があります。
  • 呼び出しは、対応するサービスにマップされない可能性があり、その後、Unbounded Analytics で実行されない可能性があります。
  • フロー・マップに矛盾する呼び出しカウントが表示される場合があります。
  • フロー・マップに矛盾するサービス・マッピングが示されている可能性があります。

このトレースは複数のバッチで処理されました

この状態では、結果のトレースが既に処理されている 2 秒間隔の後に、いくつかのスパンが到着します。 この方法では、キャプチャーされたすべてのスパンが表示されますが、一部の相関が正しくない可能性があります。

これにより、 Instana のデータモデルにおいて、次のような不整合が生じる可能性があります:

  • 出口スパンとそれに対応するエントリー・スパンは、単一の呼び出しにマージされない場合があります。
  • 呼び出しが正しいサービスにマップされない可能性があります。
  • 呼び出しが正しい親呼び出しにリンクされていない可能性があります。
  • 呼び出しでインフラストラクチャー・タグが欠落している可能性があります。
  • 呼び出しがアプリケーション・パースペクティブにマップされていないか、正しくマップされていない可能性があります。

以下のイメージは、同様のトレースを示しています。すべてのスパンは、ルート・スパンのコンテキストで処理されるため、単一のバッチでトレースにリンクされます。

単一バッチで処理されるトレース

概算データ

トレースと呼び出しは 7 日間保持されます。 この期間を過ぎると、保持される呼び出し数の概算データ・インディケーターと、元の呼び出し数の見積もりが表示されます。 そのようなシナリオでは、めったに発生しないトレースおよび呼び出しは表示されない可能性があります。

注: 選択した期間の timepicker 開始日が7日以上前であり、終了日が過去7日以内である場合、その期間の一部については完全なデータが保持されているとしても、選択した期間全体が近似データを用いて分析されます。 データ・セット全体を分析する場合は、選択した時刻範囲が過去 7 日以内に始まることを確認してください。

概算データ標識

アプリケーション・パースペクティブの正確なメトリックは、過去 31 日間保持されます。 グループを展開するか、グループを削除して個々の呼び出しを表示すると、保持されている呼び出しとおおよそのデータ標識のみが表示されます。

31 日を超えると、メトリックと呼び出しの両方が概算になります。

近似グループ化データ標識

コールレベルの指標におけるサンプリング精度に関する注記

このシステムは、トレースIDのハッシュ値に基づくランダムサンプリングを採用しており、これによりトレースレベルでの一貫したサンプリングが保証されます。 しかし、これはコールレベルの指標を分析する際に、いくつかの点で影響を及ぼします:

  • サンプリングは呼び出しごとではなく、トレースごとに行われます。 トレースごとの呼び出し回数が大きく異なる場合、呼び出しレベルのデータに偏りが生じる可能性があります。
  • たとえば、100万回以上の呼び出しを含む単一の異常なトレースが、システムによってサンプリング対象に含まれた場合、呼び出しレベルのメトリクスに多大な影響を与える可能性があります。
  • これは想定された動作であり、不具合ではありません。 これは、トレースベースのサンプリングがどのように機能するかを示しています。

制限

HTTP 名前が指定されていないパラメータは、呼び出し解析の際には無視され、フィルタリングやグループ化には使用できません。 たとえば、クエリ文字列 を含むリクエスト =val1&key=val2の場合、値 を持つ名前付き keyval2 パラメータ のみが認識されます。 名前が指定されていないパラメータは無視 =val1 されます。 ただし、完全なクエリ文字列は、呼び出しの詳細で確認することができます。