部落格版本 OpenTelemetry 入門指南：建立全面可觀測性架構

OpenTelemetry 入門指南︰建立全面可觀測性架構

淺談OpenTelemetry

OpenTelemetry以前小弟也是有很粗淺的介紹.

2019年5月, OpenTracing(CNCF項目)與OpenCensus(Google開源項目)兩大社區宣佈合併成為一個名為OpenTelemetry的新項目, 簡稱OTel.
目的是提供一個開源的Observability的pluggable框架, 解決Telemetry資料的資料模型定義、檢測、採集、處理、輸出等標準化問題, 並提供一組與第三方vendor無關的標準化SDK、API與一些instrument工具.

ps. 原本使用OpneTracing和OpenCensus的專案並不需要特別改動就能接入OpenTelemetry了
像OTel-Go, 裡面有個bridge資料夾, 裡面就是在做這轉換跟橋接
OTel-Go bridge

2021年2月 OTel在trace這功能發布了1.0版本的釋出.

OTel官網上有這麼一段話

An application is properly instrumented when developers don’t need to add more instrumentation to troubleshoot an issue, because they have all of the information they need.

它希望作到開發人員不需要添加更多的工具來解決在可觀測性的問題上, 只要用了OTel的SDK, 你的程序就會被正確地檢測, 且幾乎擁有必須的所有資訊.

所以OTel就是檢測程序的機制, 從程序開始讓整個軟體系統可以被觀測.
程序必須能發出Log、Metric、Trace, 把這些檢測資料給送到可觀測性的後端服務裡.

這句話就呼應到昨天提到的三本柱了.

OTel兼容所有非常多工具(Jaeger,Prometheus等等).
它支持把檢測資料給導出到很多商用服務上.
因為OTel如上文, 它只提供一個框架, 給軟體專案使用一個統一的標準, 這樣對開發人員來說, 就很方便了, 以往各部門或各公司甚至不同公司的軟體專案, 只要統一用上OTel, 都能讓各程序吐出的檢測資料互通有無.

設計目標

且OTel社區在做這些套件或API時, 有給一些蠻嚴格的規定, 一起看看.

We do not want to create hard breaks in support, of any kind, which leave users stranded on older versions. It MUST always be possible to upgrade to the latest minor version of the OpenTelemetry SDK, without creating compilation or runtime errors.

Never create a dependency conflict between packages which rely on different versions of OpenTelemetry. Avoid breaking all stable public APIs.

原文

它們希望別開發出新版本是有breaking change的, 相信很多大大有這種感受.
公司很多老系統, 使用的框架或依賴的套件都停在某個舊版本後, 就沒在升級上去了. 就是因為有breaking change的產生.
尤其對於可觀測性框架來說, 這變因的出現是致命的.
就很可能導致整套系統在某個地方產生不可觀測的斷點.

Signal Lifecycle

上圖大誤

OTel把Logs、Metrics、Trace加上Baggage(在Span中傳遞的上下文資訊), 稱為Signal信號.

OTel只提供檢測模型定義跟規範, 所以各語言都有各自語言生態圈的人們在協助開發. 他們於這些Signal的套件開發上需要顯示幾個狀態Expenimental、Stable、Deprecation和Removed

• Expenimental
  • 就跟我們軟體用的發布版號, 尾字有-alpha, -beta, -rc一樣, 實驗性質的版本, 功能不完整, 且可能不會正式發佈, 專案上不應該依賴使用.
• Stable
  • 完整且通過嚴格的測試的版本
  • 可以Long term dependeny, 安心的使用
  • 在API, SDK和Contrib核心包上都遵守著向下兼容的要求, 文章有特別註明MUST
• Deprecation
  • 慢慢會被替換, 但不是現在
• Removed
  • 不再支持.
  • 發生這情況時, 其版本號一定會對主要版本號進行更動(能參考Semantic Versioning).

舉例:

1. OpenTelemetry Collector Contrib
   Status Beta
   

2. OpenTelemetry .NET
   在三個Signal上的支持都來到Stable
   

Long Term Support

• API
  • 官方規定主要版本的API, 至少要支援3Y+
• SDK
  • 至少支援1Y+
• Contrib核心包
  • 至少1Y+

今日小總結

OTel框架在設計開發上, 有著明確的目標與嚴謹的規範.
我們選用上應該選用Stable的版本, 才有LTS的支持.
未來升級上也不太需要擔心兼容性問題.

參考資料

OpenTelemetry
OpenTelemetry-Versioning and stability for OpenTelemetry clients
服務開發雜談系列-OpenTelemetry介紹
Semantic Versioning

OpenTelemetry 入門指南︰建立全面可觀測性架構

幹話王部落格 Observability