AFK的Scale Cube以X軸、Y軸和Z軸方式定義出可擴展之架構設計方法，在擴展後的大量伺服器和運算節點、分層系統和服務出現應用服務效能問題時，很難在短時間準確找出根本問題，因此本文將說明如何使用OpenTelemetry可觀測性框架來解決分散式系統的效能監控問題。
在第192期2022年1月「五倍券之亂打爆銀行網站 可擴展架構設計有解」文章中，介紹了AFK的Scale Cube（https://akfpartners.com/growth-blog/scale-cube），以X軸、Y軸和Z軸方式定義出可擴展之架構設計方法，但隨著擴展後的大量伺服器和運算節點，分層系統和服務，當出現應用服務效能問題時，卻很難在短時間準確找出根本問題，甚至金融業一旦出現服務中斷，除了影響客戶及收益，主管機關也會裁罰，因此本文延續「原則十：務必使用分散式監控系統」內容，介紹如何使用OpenTelemetry可觀測性框架來解決分散式系統的效能監控問題。
大型資訊系統普遍面臨的維運問題
大型企業由於專業分工及IT分層負責，導致各部門只專注於職掌內之系統，當客戶反應問題時，若無設立資訊架構委員會，或是專責的架構師群，則難以一窺IT整體全貌，並迅速釐清因果，且每個IT團隊大多有一種先入為主的自我保護傾向，認為自身的應用程式寫得很好，若有效能問題必定是來自其他系統，所以若不採用標準作業程序規範來調查和解決系統問題，則會導致組織相互猜忌並浪費時間去猜測根本原因或採用無效的解決方案。
應用系統的問題隨時都可能會發生，可能是因為新功能上線或版本更新，應用系統下游相依的元件在既定計畫內或計畫之外的異動所導致，它們可能潛伏在系統中很多年，直到應用系統使用到特殊資料或資料量發生劇烈變化時才會發生。此時，應用系統架構師應該在識別和解決效能問題方面發揮作用，因為他們對組成應用系統的元件以及它們如何相互交互作用有廣泛且深入的了解，並且有主動部署應用系統性能監控（Application performance Monitoring，APM）工具的企業可以更早預測或檢測出效能問題並更快地解決這類問題。團隊除了利用監控數據來判斷根本原因和確定解決方案，更可利用這些經驗來改善測試方式和測試案例，而不是相互推卸責任。
資訊系統觀測工具簡介
使用效能和監控工具來捕抓動態數據和指標，利用這些指標來臆測目前面臨的系統問題，在反覆「觀察」的步驟中，從應用系統層是否有程式邏輯錯誤，到中間件、資料庫及系統層的效能問題，或是特定行銷活動造成網路壅塞影響整體系統效能，完全倚賴收集到的遙測數據，藉由調整不同時間跨度和不同的尺度及維度（各種服務），以便更好地了解正在發生的資訊系統問題，而這也是CNCF基金會的可觀測性框架OpenTelemetry以遙測的名稱來比喻相似的實踐精神。
目前用於調查效能問題的常見工具包括以下幾類：
‧應用系統分析工具，包括採樣分析器和檢測分析器（例如JDK Mission Control、Eclipse Memory Analyzer工具包或Java VisualVM），這些可用於開發過程或應用程式運行分析。
‧分散式跟蹤工具（例如OpenTelemetry、Jaeger和Zipkin），用於建構在基於微服務和雲原生架構上的應用系統。
‧作業系統和中間件效能監控工具，例如Prometheus或Telegraf。
‧整合分析和指標收集的應用系統效能監控工具（例如Dynatrace、Cisco - AppDynamics或New Relic），並且可能包含更現代化的功能，例如識別潛在問題的機器學習模型。
‧日誌聚合和分析工具，例如Datadog、Splunk和Elasticsearch - Logstash - Kibana（ELK）Stack。 ‧可擷取和解碼網路流量的網路分析工具。
可觀察性工具能從外部了解系統，當不知道其內部運作的情況下可提出有關此系統的可疑問題，因此能夠輕鬆解決和處理全新問題（unknown unknowns），並協助回答「為什麼會發生這樣情況？」。
為了能夠詢問系統各方面的問題，可對應用系統進行適當的檢測，因此，應用系統必須發送信號，例如追蹤（Traces）、指標（Metrics）和日誌（Logs），且OpenTelemetry官網指出，開發人員不需要添加更多工具來解決問題時，透過instrumentation-library手動∕自動檢測植入方式，工具就會提供應用系統本身擁有的所有信號（Signals）。
了解OpenTelemetry可觀測框架
OpenTelemetry是一種使用遙測收集和擷取指標、日誌及追蹤以便監控分散式微服務的開放標準。OpenTelemetry的發展來源可追溯到Google的Dapper系統，再到後來2018年所發布的OpenCensus，提供了包括指標和分散式追蹤的功能。Uber和Twitter等公司最初採用了OpenTracing，它僅只有追蹤單一用途，之後CNCF基金會嘗試建立一個整合指標（Metrics）、日誌記錄（Logging）和追蹤收集（Tracing）的開放標準框架，在2019年合併了OpenCensus和OpenTracing，成立了OpenTelemetry專案。
OpenTelemetry正在顛覆傳統的遙測監控方式，OpenTelemetry已經發展成為整合API、SDK和接收處理轉送的完整工具，目的在建立和管理遙測數據標準，提供一個與特定廠商無關的實作框架，透過配置可將遙測數據發送到可自行選擇的後端服務。它支援各種主流的程式語言和開源專案，包括Jaeger和Prometheus。
OpenTelemetry對於監控產業的發揮起顛覆性影響，讓框架的各種元件更好使用、更快速整合且更便宜就可替換，如圖1左邊支援各種系統信號來源，遵循標準OTEL Collector規格，就可送到右邊各種開源及商用監控平台和SaaS服務，並且支援各種主流語言的傳統遺留系統，避免商用監控產品因市場的利益關係，不再提供新版本而失去支援，除了應用系統開發商，監控產品供應商也體認到監控觀測標準的必要性，如果沒有標準，即便在交易服務中添加自定義的HTTP Header，也可能被中介設備（例如負載平衡器、防火牆和反向代理）丟棄，進而導致追蹤中斷。
圖1 OpenTelemetry框架支援各種平台監控數據。
此外，供應商支援OpenTelemetry標準大量簡化了開發⼈員使用來自各種不同分散式追蹤解決方案的現況，因此，只要監控產品供應商都將符合這標準，追蹤數據就不會出現斷點，可從網頁服務追蹤到後端服務，因此OpenTelemetry已成為遙測收集的產業標準。
另外，OpenTelemetry使用案例因組織的上雲策略（多雲、混合雲或雲原生）以及應用系統是否為微服務，在容器和Kubernetes中運行而有所不同，與其相對的建議OpenTelemetry方式如表1所示。
OpenTelemetry官方Demo範例說明
OpenTelemetry官方部落格在2022/10/24發表一篇技術文章「OpenTelemetry Demo now Generally Available!」（https://opentelemetry.io/blog/2022/announcing-opentelemetry-demo-release/），此範例專案展現OpenTelemetry支援各種主流程式語言的強大功能，透過多語言實作微服務架構的購物網站，藉此用以學習OpenTelemetry，整體架構詳見圖2。
圖2 OpenTelemetry Demo購物網站整體服務架構圖及服務實作的程式語言。
安裝步驟
請先安裝Kubernetes環境及Helm 3.X工具，接著執行以下指令：
#添加OpenTelemetry Helm儲存庫 helm repo add open-telemetry https: //open-telemetry.github.io/opentel emetry-helm-charts #安裝版本名稱為my-otel-demo的Helm chart模板 helm install my-otel-demo open- telemetry/opentelemetry-demo
安裝完成之後，就出現圖3所示的歡迎畫面了。
圖3 OpenTelemetry Demo安裝後的歡迎畫面。
服務對應
執行連接埠轉送，先將my-otel-demo-otelcol（OTEL Collector）對應到本地端，讓網頁JavaScript可傳送信號數據到此服務，再將my-otel-demo-frontendproxy對應到本地端，就可開啟範例購物網站和相關設定，以及監控儀表板：
#將本機4318 port對應到my-otel-demo- otelcol服務的4318 port kubectl port-forward svc/my-otel- demo-otelcol 4318:4318 #將本機8080 port對應到my-otel-demo- frontedproxy服務的8080 port kubectl port-forward svc/my-otel- demo-frontendproxy 8080:8080
分散式追蹤
使用瀏覽器開啟「http://localhost:8080/」，就可看到圖4的購物站首頁，點選望遠鏡商品，加入購物車後完成結帳，接著，再開啟「http://localhost:8080/jaeger/ui/」，將反向代理到Jaeger追蹤儀表板，挑選想要查詢的微服務，可顯示從前端（Frontend）網頁到後端各種服務的API串接關係，如圖5中甚至可查詢到Redis HGET方法。
圖4 OpenTelemetry Demo購物網站首頁。
圖5 Jaeger追蹤到購物車服務讀取Redis快取。
應用系統指標
若想查看應用系統的各項指標，則開啟「http://localhost:8080/grafana/」，此範例提供內建的Demo儀表板可顯示推薦服務（Recommendation）的CPU、Memory、次數、錯誤率、服務等待時間、每秒請求次數，如圖6所示。
圖6 Grafana監控Recommendation服務的儀表板。
若且透過Explore可搜尋已收集到的應用系統指標，如圖7是針對支付服務（Payment）交易金額，統計各種貨幣的累計金額，可看到22:10已到達1,390元USD，這指標是支付服務Node.js程式有針對貨幣類型客製化提供（https://github.com/open-telemetry/opentelemetry-demo/blob/main/src/paymentservice/charge.js#L70）。
圖7 Grafana監控Recommendation服務的儀表板。
從上面簡單的示範，就可收集到購物網站服務之間的API先後順序，過往追蹤（Tracing）必須要靠付費APM才能做到相同效果；而應用服務所呈現的指標，不同於K8s、EKS、GKE、AKS等PaaS所提供的是平台容器層的CPU、Memory、Storage、Networking資源監控，取而代之是應用層或業務邏輯關鍵指標，如HTTP連線數、API回應速度和累計交易金額等等，這些都是容器平台監控做不到的，且也不屬於容器平台層可以提供的。
目前OpenTelemetry可提供表2所列出的程式語言來達到無須修改程式的自動偵測方式，或整合OTEL SDK的手動偵測方式來達成可觀測性監控，而Demo專案有提供相對應服務的程式碼可供參考，以便實作整合到自己的應用系統中。
認識OpenTelemetry Collector架構
前面提到OpenTelemetry將對整個監控產業造成重大改變，主要是得力於OpenTelemetry Collector的架構設計，見圖8，把原本需要各自收集的日誌、追蹤和指標，透過提供自動植入功能或手動整合各種語言的OTEL SDK便可傳送監控信號到單一中間件，Opentelemetry-collector作為可觀測框架的中間層，解耦後端收集資訊的平台或SaaS，供應商無須再自行設計Agent程式和SDK，只要依照OTEL標準就可輕鬆切換Elastic、DynaTrace、Datadog、Jaeger、Zipkin等，徹底解決微服務監控問題。
圖8 傳統式各自監控方案與OpenTelemetry可觀測方案對應圖。
結語
藉由OpenTelemetry Demo專案可迅速掌握此可觀測性監控框架的使用，並使用OpenTelemetry Helm Charts只需要一兩行指令就可完成整個範例安裝，這便是雲原生技術的優點，把開發以外的旁枝末節工作盡量簡化；筆者因這次實作發現此Demo專案在Helm Charts 0.14.1版的Grafana Datasource參數和預設值無法達到開箱即用，發出Pull Request後榮幸成為0.14.2版的貢獻者（https://github.com/open-telemetry/opentelemetry-helm-charts/releases/tag/opentelemetry-demo-0.14.2）。
因OpenTelemetry近乎開箱即用的優勢，大幅減少導入分散式監控的困難度和學習曲線，因此，監控軟體供應商正從原本收集和擷取的功能轉向監控數據分析，這有助於推動MLOps/AIOps監控產業發展和廣泛採用，OpenTelemetry負責將遙測數據發送到後端商業所需OTEL收集器管道，便可利用信號數據進行自動化分析，期待未來可提供更加成熟的自動化維運和自動化監控告警軟體。
＜本文作者：鄭淳尹，Docker.Taipei社群共同發起人，台北富邦銀行雲端系統部架構師，曾任微軟MVP、國泰金控技術架構師、momo購物網架構師、臺北榮民總醫院資訊工程師、玉山銀行資訊處專員、宏碁eDC維運工程師。開源技術愛好者，曾在多間大學資工系擔任Docker容器技術講師，並翻譯審閱多本容器技術書籍。＞