追蹤概念

Callstacks

呼叫堆疊 是代碼執行的排序清單。 每當程式碼呼叫其他程式碼時，新程式碼會放在堆疊頂端。 Callstacks 是由所有程式設計語言的執行時期所使用，且通常列印為 堆疊追蹤。 當發生錯誤時，堆疊追蹤可讓您追蹤回導致錯誤的呼叫。

例如，下列錯誤訊息指出 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 上發生錯誤，但未指出問題。

您最後發現兩個呼叫堆疊有兩個錯誤，而不是容易疑難排解的單一錯誤呼叫堆疊。 與此同時，兩者之間沒有關聯，因此無法同時存取兩者。

伺服器 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"

分散式追蹤 背後的構想是透過將兩個錯誤呼叫堆疊彼此連接來修正此問題。 大部分實作都使用簡單機制; 當伺服器 A 呼叫伺服器 B 時， APM 工具會將 ID 新增至呼叫，作為 APM 系統中呼叫堆疊之間的一般參照點。 此機制稱為 相關性 ，為了產生一個錯誤，它會結合兩個呼叫堆疊。

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 毫秒，其本身花費大部分時間來執行遠端呼叫。

追蹤連續性

追蹤連續性表示將一個外部要求所觸發的呼叫收集到一個追蹤中。 Instana 採用特定通訊協定專用的方法來新增 meta 資料，例如 HTTP 標頭、 gRPC meta 資料、 Kafka 訊息標頭、AMQP 標頭、JMS 標頭等。 這可確保所有通訊協定和服務之間的追蹤連續性。

不支援任何 meta 資料的通訊協定不支援追蹤連續性。 這表示當透過這類通訊協定呼叫另一個服務時，送出呼叫是追蹤樹狀結構中的葉節點。 在呼叫的接收器中發生的工作不是該追蹤的一部分。 相反地，接收呼叫會啟動新的追蹤，而在接收端中觸發的所有後續呼叫都屬於這個新的追蹤。

在下列情況下，不支援追蹤連續性:

• Kafka 最高版本 0.10 (Kafka 在 0.11版中引進了標頭) ，
• 使用 Node.js 套件 kafka-node 傳送或接收 Kafka 訊息 (該套件不支援標頭。 在 Node.js中使用 Kafka 時，建議使用 npm 套件 kafkajs 而非 kafka-node 。 使用 kafkajs，支援追蹤連續性，請注意這些 其他註解 ，以繼續追蹤送入訊息)。
• NATS 及 NATS 串流傳訊
• Microsoft 訊息-佇列

W3C 追蹤環境定義支援

除了 專有標頭 X-INSTANA-T/X-INSTANA-S之外，下列 Instana 追蹤器還支援 HTTP/HTTPS 通訊的 W3C 追蹤環境定義 規格:

• .NET Core
• .NET
• Apache HTTPd
• Clojure
• 執行
• Haskell
• Java
• Kotlin
• Node.js
• Python
• Ruby
• Scala

下列 Instana 追蹤程式目前不支援 W3C 追蹤環境定義 指定。 僅支援 專有標頭 X-INSTANA-T/X-INSTANA-S :

• Envoy
• NGINX
• PHP

追蹤標頭

為了確保不同服務之間的 追蹤連續性 ， Instana 追蹤程式會根據通訊協定使用不同的標頭或 meta 資料內容。