トレースの概念

呼び出しスタック は、コード実行の番号付きリストです。 コードが他のコードを呼び出すたびに、新しいコードがスタックの最上位に配置されます。 Callstacks は、すべてのプログラミング言語のランタイムによって使用され、通常は stacktraceとして出力されます。 エラーが発生すると、スタック・トレースはエラーの原因となった呼び出しに戻ります。

例えば、以下のエラー・メッセージは Apple は数値ではありませんを示しています。 呼び出しスタックと組み合わせると、エラーが発生した複雑なシステムで絞り込むことができます。 NumberUtil アルゴリズムは多くの場所で使用される可能性があるため、通常、メッセージのみでは不十分です。

Thread.run()
  HttpFramework.service()
    HttpFramework.dispatch()
      ShoppingCart.update()
        ShoppingCart.updateCart()
          ShoppingCart.parseQuantity()
            ShoppingCart.convertParams()
              NumberUtil.convert()  <-- Error: "Apple is not a number"
 

エラーが発生した理由を理解するには、呼び出しスタックを使用して、エラーから関連するビジネス・メソッド (この場合は ShoppingCart.parseQuantity()) までトレースバックします。

呼び出しスタック自体はモニタリングには不十分です。 これらは読み取りが容易ではなく、システムのパフォーマンスと可用性を全体的な正常性に相関させるための情報を提供しません。 コード実行で何が行われるかを確認し、相関させるには、プロセス・アクティビティー、リソース使用量、キューイング、アクセス・パターン、負荷とスループット、システム、およびアプリケーションの正常性などの情報を検討します。

サービス指向アーキテクチャー (SOA) の導入により、呼び出しスタックが分割されています。 例えば、 ShoppingCart ロジックがサーバー A にあり、 NumberUtil がサーバー B にあるとします。 サーバー B のエラー・トレースには、構文解析エラーの短い呼び出しスタックのみが含まれています。 サーバー A では、サーバー B で問題が発生したことを示す新しいエラーが生成されますが、問題自体は示されません。

トラブルシューティングが容易な単一のエラー・コール・スタックではなく、2 つのエラーを持つ 2 つのコール・スタックになります。 また、この 2 つの間には接続が存在しないため、両方に同時にアクセスすることは不可能です。

サーバー A:

Thread.run()
  HttpFramework.service()
    HttpFramework.dispatch()
      ShoppingCart.update()
        ShoppingCart.updateCart()
          ShoppingCart.parseQuantity()
            ShoppingCart.convertParams()
              RestClient.invokeConversion() <-- Error: Unkown
 

サーバー B:

Thread.run()
  HttpFramework.service()
    HttpFramework.dispatch()
      NumberUtil.convert()  <-- Error: "Apple is not a number"
 

分散トレースの背後にある考え方は、2 つのエラー呼び出しスタックを相互に接続することによって、この問題を修正することです。 ほとんどの実装では、単純なメカニズムを使用して呼び出しを行います。サーバー A がサーバー B を呼び出すと、アプリケーション・パフォーマンス・モニター (APM) ツールは、APM システム内の呼び出しスタック間の共通参照点として機能する ID を呼び出しに追加します。 このメカニズムは 相関 と呼ばれ、1 つのエラーを生成するために 2 つの呼び出しスタックを結合します。

Thread.run()
  HttpFramework.service()
    HttpFramework.dispatch()
      ShoppingCart.update()
        ShoppingCart.updateCart()
          ShoppingCart.parseQuantity()
            ShoppingCart.convertParams()
              RestClient.invokeConversion()
                Thread.run()
                  HttpFramework.service()
                    HttpFramework.dispatch()
                      NumberUtil.convert()  <-- Error: "Apple is not a number"
 

リモート呼び出しが行われる場所と、呼び出しスタックのどのサーバー部分で呼び出しが実行されたかを理解することにより、 ShoppingCart がエラーのコンテキストであり、 NumberUtil が原因でショッピング・カート・アクティビティーが失敗したことを知ることができます。

ただし、上記の例では、APM ツールが、パフォーマンス測定の実行および表示に使用されるのと同じメカニズムを使用してエラーをトレースすることを示しています。 トレースには、以下のようにパフォーマンス番号の注釈が付けられています。

413 Thread.run()
413   HttpFramework.service()
413     HttpFramework.dispatch()
412       ShoppingCart.update()
411         ShoppingCart.updateCart()
211           ShoppingCart.parseQuantity()
210             ShoppingCart.convertParams()
200               RestClient.invokeConversion()
 10                 Thread.run()
 10                   HttpFramework.service()
 10                     HttpFramework.dispatch()
  5                       NumberUtil.convert()
 

ショッピングカートの更新処理にかかる合計時間は約413ミリ秒です。数値変換（NumberUtil.convert()）には5ミリ秒かかりました。その間の時間は多くの呼び出しに分散しているため、顕著な急激な変化を探していることになります。 この例では、カート (ShoppingCart.updateCart()) の更新には合計 411 ミリ秒かかりましたが、構文解析 (ShoppingCart.parseQuantity()) には 211 ミリ秒しかかかりませんでした。これ自体がリモート呼び出しの実行にほとんどの時間を費やしていました。

トレースの継続性とは、1 つの外部要求によって起動された呼び出しが 1 つのトレースに収集されることを意味します。 Instana HTTP ヘッダー、 gRPC メタデータ、 Kafka メッセージヘッダー、AMQPヘッダー、JMSヘッダーなど、プロトコル固有の手法を用いてメタデータを追加します。 メタデータを追加すると、すべてのプロトコルおよびサービスにわたってトレースの継続性が確保されます。

メタデータをサポートしない通信プロトコルは、トレース継続性をサポートしません。つまり、このようなプロトコルを介して別のサービスを呼び出すと、発信呼び出しはトレース・ツリー内のリーフになります。 呼び出しの受信側で行われる作業は、そのトレースの一部ではありません。 代わりに、呼び出しを受信すると新しいトレースが開始され、受信側でトリガーされる後続のすべての呼び出しはこの新しいトレースに属します。

トレースの継続性は、以下の場合にはサポートされません。

• Kafka バージョン 0.10 まで (Kafka は、バージョン 0.11でヘッダーを導入しました)
• Node.js パッケージ kafka-node を使用した Kafka メッセージの送受信 (つまり、パッケージはヘッダーをサポートしません)。 Node.js で Kafka を使用する場合は、トレースの連続 kafkajs 性をサポートしているため、 kafka-node の代わりに npmkafkajs パッケージを使用してください。 詳細については、（受信メッセージのトレースを継続するための追加の注意事項 ）を参照してください
• NATS および NATS ストリーミング・メッセージング
• Microsoft Message Queue

以下の Instana トレーサーは、や X-INSTANA-T といった独自のヘッダー に加え、 HTTP または X-INSTANA-SHTTPS 通信向けの W3C トレースコンテキスト仕様をサポートしています：

• .NET Core
• .NET
• HTTPd
• Clojure
• Go
• Haskell
• Java
• Kotlin
• Node.js
• Python
• Ruby
• Scala

以下の Instana トレーサーは、現在、 W3C トレースコンテキストの指定に対応していません。 プロプラエタリー・ヘッダー ( X-INSTANA-T や X-INSTANA-S など) のみがサポートされています。

• Envoy
• NGINX
• PHP

異なるサービス間でトレースの連続性を確保するため、 Instana のトレーサーは、プロトコルに応じて異なるヘッダーやメタデータプロパティを使用します。