√介紹可觀測性
√介紹Opentelemetry的核心概念
重新認識可觀測性管理學大師彼得德魯克有一句話：“如果你無法衡量它，你就無法管理它”。在企業中，無論是管理人，還是管理事，抑或是管理系統，首先都需要衡量。衡量的過程其實是搜集信息的過程，有了足夠的信息才能做出正確的判斷，有了正確的判斷才能做出有效的管理和行動方案。
下面我用一個簡單模型來說明我對可觀測性的理解：
圖釋：通過觀測看到表象，通過判斷定位問題，通過優化解決問題。
可觀測性描述的就是“觀測-判斷-優化-再觀測”這個閉環的連續性、高效性。如果只有觀測而無法基于觀測做出判斷，則不能稱其具備可觀測性。如果只有經驗判斷而沒有數據支撐，也不能稱其具備可觀測性，這樣會導致組織高度依賴個人能力而帶來管理風險。如果優化之后無法反饋到觀測上，或者因優化引入新的技術而導致無法觀測，則其可觀測性不可持續。如果在觀測、判斷、優化的閉環中需要付出很高的成本和承擔很大風險，則其可觀測性的價值為負。
所以，當我們在談可觀測性的時候，其實更多考慮的是觀測者、管理者的感受，也就是說在我們遇到問題的時候，能否輕而易舉地在觀測平臺找到答案，沒有阻力也沒有困惑，這就是可觀測性。隨著企業的發展，組織架構（角色、觀測者）和管理對象（系統、被觀測者）都會隨之發展變化，當使用了一堆傳統的觀測工具，卻仍然無法滿足觀測者、管理者新的需求的時候，我們不禁要問：“可觀測性何在？”。
“可觀測”不等于“可觀測性”下面，我們來看一下我們習以為常的觀測方式。
圖釋：傳統的觀測工具是垂直的，觀測者需要從多個工具中進行問題判斷。
通常我們會基于自己想要的數據去搭建觀測工具。當我們想了解掌握基礎設施的健康狀況的時候，我們會很自然的想到搭建一個儀表盤，實時監測各項指標。當我們想了解業務是如何出問題的，我們會很自然的想到搭建一個日志平臺，隨時過濾排查業務日志。當我們想了解事務為什么高延遲，我們會很自然的想到搭建一個鏈路監測平臺，查詢拓撲依賴和各節點的響應時間。這種模式很好，幫助我們解決了很多問題，以至于我們從不懷疑可觀測性，我們信心滿滿。偶爾遇到大難題，把我們的儀表盤、日志平臺、鏈路平臺打開，所有的數據都在這里，我們堅信一定能找到問題的根因。即使花費了很長時間，我們也只是告訴自己要多學習，多了解掌握自己負責的系統，下一次我一定能更快找到根因。是的，當我們想要的數據都擺在面前的時候，我們還有什么理由怪罪觀測工具。
圖釋：人腦像一把尺子，根據經驗比對多個指標來發現它們的相關性。
圖釋：當發現指標有毛刺的時候，往往需要在大腦中構建復雜的日志查詢條件，費時不說還容易出錯。
我們會不辭勞苦地在各種指標數據中尋找可能的關聯性，得到關鍵線索后，我們會在大腦中構造出一堆復雜的日志查詢條件來驗證自己的猜想。就這樣比對、猜想、驗證，同時還要在各種工具中切換，不可否認很充實。
圖釋：系統規模龐大的時候，人已經無法去定位問題了。
傳統的系統相對簡單，上述方式行之有效。現代IT系統的關鍵詞是分布式、池化、大數據、零信任、彈性、容錯、云原生等，越來越龐大，越來越精細，越來越動態，同時也越來越復雜。通過人去尋找各種信息的關聯性，再根據經驗判斷和優化，顯然是不可行的，耗時耗力還無法找到問題根因。
傳統的工具是垂直向的，引入一個新的組件的同時也會引入一個與之對應的觀測工具，這樣是保證了數據的全面性，但丟失了數據的關聯性和分析排查的連貫性（換句話說，我們方方面面都監控到了，但遇到問題，還是不能很好地發現和定位）。此時我們很自然的想到做一個統一的數據平臺，想象中把所有數據放在一個平臺就能解決關聯性的問題，但往往實際情況是我們只是把數據堆在一個地方，用的時候還是按傳統的方式各看各的。我們只是把無數根柱子（工具），融合成了三根柱子：一個觀測指標、日志、鏈路的統一平臺，數據統一了，但關聯性還得靠人的知識和經驗。
這里邊最關鍵的其實是解決數據關聯的問題，把之前需要人去比對、過濾的事交給程序去處理，程序最擅長此類事同時也最可靠，人的時間更多的用在判斷和決策上。這在復雜系統中，節省的時間會被放大很多倍，就這點小事就是可觀測性看得見的未來。
圖釋：未來觀測工具需要通過時間和上下文來關聯數據
那么，如何做數據關聯呢？說起來很容易，那就是做時間+空間的關聯。在我們的統一數據平臺上，由于數據是來自于各種觀測工具的，雖然我們在數據格式上統一成了metric、log、trace，但不同工具的metric、log、trace的元數據截然不同，而如果我們在這個統一數據平臺上去梳理和映射這些元數據的話，這將是龐雜、難維護、不可持續的。那該如何做呢？答案就是標準化。只有將標準化、結構化的數據喂給觀測平臺，觀測平臺才能從中發現巨大價值。統一數據平臺只是在數據格式上進行了標準化，而要想將trace、metric、log關聯還必須建立context的標準化，context就是數據的空間信息，再疊加上時間信息的關聯就可以發揮真正的觀測價值。
Opentelemetry做了什么？Opentelemetry（以下簡稱：OTel）就是解決數據標準化問題的一個項目，OTel由以下幾部分組成：
跨語言的標準規范（Specification）：定義了數據、上下文、API、概念術語等的規范。這是OTel的核心，它使得所有觀測數據有機地統一起來，這樣觀測平臺才能自動比對、自動過濾，同時也為AI提供了高質量的數據。接收、處理、輸出觀測數據的工具（Collector）：一個用于接收OTel觀測數據的工具，并支持通過配置pipeline對觀測數據進行處理，輸出給指定的后端。各種語言的SDK（SDK）：基于OTel標準的API實現的各種語言的SDK，用來支持自定義開發觀測數據采集器。采集器（Instrumentation）：開箱即用的觀測數據采集器。OTel是開源項目，所有內容都可以在Github找到，下面我介紹幾個關鍵的概念：屬性從數據的角度看屬性是一個鍵值對，本質上屬性描述了空間信息，方便從空間上做數據關聯。OTel定義了很多通用的屬性，如果定義不明確或數據不一致時，是沒法自動關聯分析的。下面是Otel定義的K8S的Pod屬性：
資源
從數據的角度看資源是一個鍵值對集合，本質上資源描述的是觀測對象。相同觀測對象的Metric、log、trace都有相同的資源數據（或稱：相同上下文），這樣就可以自動發現相關性。
事件
從數據的角度看事件是一個時間戳和一組屬性組成的，用來描述某個時間發生了某件事。本質上事件是一個時間+空間的組合。
指標
從數據的角度看指標是事件的聚合，在一個活躍的系統中，相同的事件會不斷發生，指標提供了一個跨時間和空間的總覽。沉浸在細節不一定有見解，跳出來，從更高的維度鳥瞰可能尋找到靈感。
跨度
從數據的角度看跨度由：操作名稱、開始時間、持續時間、一組屬性組成。跨度（又稱：span）描述的是一個過程，如果說事件是在一個時間點構建了時間和空間的相關性，那么跨度就是在一個時間段上構建了時間和空間的相關性。
信號
信號是對標準遙測數據的抽象，相同數據模型的數據被歸為一個信號。如：一個Metric是一個信號，所有Metric都具有統一標準的數據模型。一個Trace是一個信號，所有Trace都具有統一標準的數據模型。信號有一個重要的特性就是供應商無關，任何可觀測系統供應商要支持OTel，都必須要按OTel的信號模型收集、上報、處理數據，這是保障高效數據關聯的關鍵。
上下文
所有信號都基于相同的上下文，如：在同一個服務中采集的Metric、log、trace具有相同的上下文（如：service.id和service.name）。這其實就是在空間上建立的數據的關聯。
敬畏工程OTel在數據層面提供了標準規范和許多拿來即用的工具，大大方便了構建可觀測平臺，但是真正落地去構建適合自己的、全面可擴展的、穩定可靠的、低成本高效益的可觀測平臺是一個大工程，不是簡單引入就可以的。這其中涉及到大數據引擎、高基數分析引擎、關系引擎、AI引擎等系統難題。此外，如何設計一個簡單、高效、準確、協同、專業的平臺也不是一蹴而就的，需要懂數據也要懂技術還要懂設計。
我把可觀測平臺分以下層次：
數據展示+人工關聯比對+人工判斷：大多數傳統觀測平臺在這一層。信息關聯展示+人工判斷：部分觀測平臺通過梳理映射可以做一些相關性展示，減少人工發現的時間成本。信息判斷 x 人工判斷：極少部分觀測平臺做了數據的高度標準化，可以根據相關性給出見解和建議。信息判斷+行動：沒有觀測工具能只依靠工具做判斷。博睿數據在數據采集層有十多年的技術積累，探針穩定可靠，部署簡單。在數據處理方面也經受住了大業務量的客戶考驗，技術上不斷創新形成了極具優勢的架構。在數據標準化、結構化設計方面也形成了自己的體系。可以說我們剛跨越了第2層來到第3層，我們將從觀測廣度和深度兩個方面豐富標準化的數據，基于此同時不斷深化數據相關性，加上我們自研的SwiftAI中臺賦能，未來將給出更多更精準的信息判斷，幫助客戶快速落地高效可持續的觀測--判斷--優化閉環。?
X 關閉
X 關閉