（時間不太夠，所以昨天預告的 Portfolio Management 範例我們改天再聊，今天先用一個比較小的主題讓我再次喘息一下。）

今天我們來看另一個 GitLab 產品發展方向，那就是現在很夯的關鍵字 Observability 可觀測性。

在 Product Direction - Monitor:Observability 的頁面中，有以下幾個重點：

• 首先在 GitLab 的文件結構中，Observability 目前是放在 Monitor 這個大主題之下，光是這點可能就有得吵了(笑)，因為我知道有一些人認為 Observability 的涵蓋範圍大於 Monitor，又或者 Observability 與 monitoring 兩者的切入角度是不同的。
• 目前在 Observability 有四大類的功能
  • Error Tracking（已正式釋出）
    可視化、集中化的追蹤與管理 Error。這應該是 Sentry 及相容 Sentry 的功能。
  • Distributed Tracing（還在 beta）
    還在開發中的新功能，但沒意外就是 OpenTelemetry 的 Traces。原廠應該會比照其他功能，讓 GitLab 也能保存與顯示這些 Traces 的資訊，讓他跟其他資訊建立關聯。
  • Metrics（還在 beta）
    還在開發中的新功能，但沒意外就是 OpenTelemetry 的 Metrics。原廠應該會比照其他功能，讓 GitLab 也能保存與顯示這些 Metrics 的資訊，讓他跟其他資訊建立關聯。
  • Logging（還在 beta）
    我想你應該猜到了，所以這個沒意外就是 OpenTelemetry 的 Logs。原廠應該會比照其他功能，GitLab 也能保存與顯示這些 Logs 的資訊，讓他跟其他資訊建立關聯。
• 原廠也簡單的詮釋了什麼是 Observability
  • 即是透過 Telemetry data（包含 traces、metrics、logs）幫助團隊可以針對應用程式的效能、可用性、使用者體驗做出視覺化與分析。而這麼做是為了幫助團隊，更容易知曉應用程式發生了什麼現象，以便解答各種問題與狀況的根本原因。
• 這個產品發展方向的 Vision
  • 果不其然，依然為了是強化 GitLab 這個 The one platform，將更多關於應用程式和 infra 的資訊與工作流程整合在同一個平台，提升團隊的維運效率。
• 在發展這個產品方向時，有幾項 Principles（以下用我自己的話詮釋內容）
  • Developer-first
    注重開發團隊的需求，因此會走向能幫助企業「左移」可觀測性與監控的產品發展方向。
  • Support Platform engineers
    繼續搭上平台工程的熱潮，GitLab 認為支援 Platform team，提供可觀測性，能間接幫助到開發團隊。
  • Cloud-Native first
    延續 GitLab 既有的功能發展方向，繼續擁抱 Cloud Native。
  • Working out of the box
    要讓實踐可觀測性夠簡單、夠好用，最好是打開一個開關就能直接開箱即用，免去團隊要做一堆繁瑣的組態配置。
  • Unified Data Platform
    延續 GitLab 既有的功能發展方向，要讓 GitLab 成為各種資訊的匯總中心，在 GitLab 上實現各種資訊的彼此關聯，在 GitLab 上實現 single source of truth。
  • Integrated UI
    延續 GitLab 既有的功能發展方向，讓可觀測性能與 GitLab 各頁面 UI 有良好的整合，與前兩項也算是有關，讓使用者可以更無痛與方便的直接就能在 GitLab 的 UI 上取得可觀測性的資訊（避免使用者還要跳離開到其他的平台或工具 UI。）
  • OpenTelemetry as the instrumentation standard
    毫無懸念，GitLab 也是跟著 OpenTelemetry 走。這也吻合 GitLab 長久以來一直是擁抱開源生態系。
• 目前已經發布了哪些 Observability 的功能？功能開發的進展？下一步會做什麼？
  • 如前述四大功能，Error Tracking 功能已經正式推出，OpenTelemetry 相關功能都還在 beta，會盡快讓它們能正式推出，讓客戶可以開始實踐第一步的可觀測性。
  • 接下來會處理，讓可觀測性的資訊可以與 GitLab 既有的功能有更多整合，包含 UI 的整合。
  • 還有一些繼續實驗與探詢的功能發展方向，像是 Automatically discover 這種可以幫助團隊更自動的將需要監控的元件納入管轄的功能；或是能否收集更多和 deployments workflows 有關的資訊；以及將可觀測性運用在 GitLab 自己本身。
• GitLab 因為收購了 Opstrace，有確實幫助 GitLab 發展可觀測性的功能。

我自己覺得 GitLab 對於 Observability 的觀點，有抓到一個關鍵重點，就是「左移」。傳統來說「監控」與相關的任務都被直接切割歸屬於 Ops 端負責的事務，但這種一刀切的做法，正是過往以來產生 silos 或資訊斷層的原因之一。

可觀測性目前在 GitLab 上仍屬於比較新的主題，因此可以看到對應的功能都還在持續開發測試中，但至少都已經進入 beta，沒意外的話，也許在幾個月內就會正式推出了，有興趣的人可以繼續保持關注。

另外 GitLab 也有針對 Observability 做競品分析，有興趣的人可以查看 Competitive Landscape - Monitor:Observability，看看 GitLab 是怎麼定位自己與評論其他競品的。

圖片來源 - 吉卜力工作室 https://www.ghibli.jp/works/ged/#&gid=1&pid=42

參考資料

• https://about.gitlab.com/direction/monitor/observability/