OpenTelemetry Java Getting Started 4
由於網路上的架構解說(包含官網)對我來說都沒有那麼清楚
所以參考各個解說資料與影片再搭配前面我練習的實作內容整理
參考資料有:
主要整理是由上述第三個參考為主
不過概念上不外乎是將metrics log統一標準化
讓服務串聯的有一個追蹤的標的
以RestfulAPI為例子,有可能常有API間串接:
A API call →B API call →C API
當A執行到請求B時,就會開始等待B回應
其他依序同理B等待C
最後當A取得B的回應後才完成整個A API服務的呼叫
在ABC這三者都是同一個請求,所以建立有一個可追蹤的id:
放大:
點開Loki其中一筆log就可以展開連動Tempo的畫面:
加上解說(注意,這個都是boot-otel-tempo-api專案的log而已):
其中任意一筆TraceId點開的Tempo就會看到:
而前面Loki圖中的Context Id(或稱Span Id)則是單一個程式專案內
不同Operation或是Thread local,或根據程式的執行順序來排定
由log內容可以發現,這個Operation可能是同一個Java Code元件
但是也可能不同:
而不同程式專案間上游程式專案服務(boot-otel-tempo-api)
呼叫下游(boot-otel-tempo-provider1)
在上游最後的Span(Operation)要轉成http序列化並且傳播(propagation)
導向下游開頭的Span(Operation)其中包含的動作:
首先是上游最後Spna要做Serializing context Inject
這可以理解為將inject context轉化為http header才打到下游去
然後下游的開頭Span接到第一步就是Extract其中http header的內容
其中Serializing context Inject傳播的內容可以猜得到就是Trace Id
否則無法比對不同程式專案服務間,對應的是哪一筆請求
其中header細節w3c規範內容怎麼傳播的,可以參考上面的參考影片
實際不是只有傳Trace Id而已
而整個運作以我們的範例是透過dependency的Framework形式
但是除了一些API外,我們並沒有辦法針對OpenTelemtry的運作內容進行修改
那些無法調整的部分稱為SDK
另外也有如前面筆記第一篇的Getting Started 1的方式
是執行jar時候另外加掛的agent jar →opentelemetry-javaagent.jar
這個連OpenTelemetry API都沒辦法用
但是連帶以javaagent的JAVA_OPTS執行時,自然就會幫我們額外寫log
並且是OTLP(OpenTelemetry)的格式
其他若要是給別的平台顯示(ex:Prometheus,Loki,Tempo...etc)
則需要Collector,在前篇的SpringBoot範例看起來對應就是依靠
volume_exporter這個Container
來轉化成有uri是/metrics提供Prometheus等使用
又或是說所謂Collector算是包含在OpenTelemetry的lib裡面
(2022/07/05補充:後來找到Collector較好的說明:
https://www.youtube.com/watch?v=9Sfm70u7yLo
也證明lib是Collector的其中一種形式,其他還有agent,gateway
其他OpenTelemetry Collector參考:
https://www.youtube.com/watch?v=FV9LTZoXSTg
)
volume_exporter這個Container只是額外對應給Prometheus等的設置
這邊並沒有找到比較好的解釋
我認為這個OpenTelemetry標準最大好處在未來
應該是不同程式的專案間API呼叫都有相同的Trace標準
Java Call C#專案的API,或是Java Call .Net API
都能追蹤到對應是哪一筆請求的Trace Id標準
另外也有看到Jenkins使用Opentelemetry的Plugin搭配Jaeger的使用
可以拿來分析Jenkins Job的執行效率:
