本文受訪嘉賓：蔣志偉，愛好技術的架構師，先後就職於阿里、Qunar、美團，前 pmcaff CTO，目前 OpenTelemetry 中國社群發起人，https：//github。com/open-telemetry/docs-cn 主要維護者。
有心人可能已經發現，可觀測問題正在悄然成為 IT 行業的熱門話題。尤其是從 2021 下半年到今日的一年間，對可觀測問題的討論，不斷見諸技術圈內，大有愈演愈烈之勢。
從技術的角度看，這是因為微服務架構逐漸普及，導致可觀測問題變得十分複雜。
差不多在五年前，分散式系統也已成熟，微服務架構尚未普及，可觀測問題就已經在桎梏技術團隊的工作效率。一個 To C 的軟體使用問題可能由客服發起，整條支撐鏈路的所有技術部門，都要逐一排查介面和日誌，流程非常原始，也非常低效。如果業務到達一個量級，支撐系統變多，兩名研發查上兩三個星期也是常事。
微服務架構普及後，問題變得更加嚴峻。一個服務被拆分成數個黑盒的、虛擬的微服務，故障排除徹底成為一種折磨。
從行業的角度看，則是因為 Datadog 在美上市，兩年間市值翻了三倍多（截止到 5 月 30 日，市值為308億美金），讓從業者看到：可觀測不但是個未被妥善解決的疑難老病，也有十分廣大的市場空間。巨大的需求背後，必然是急速擴張中的市場。
這一切都使可觀測成為 2022 年技術人必須關注的話題。
當我們談論可觀測，究竟是在談論什麼？
2016 年，一本名叫《Site Reliability Engineering - How Google Runs Production Systems》出版，谷歌的工程師在書中描繪了故障生命週期的五個階段：故障預防、故障發現、故障定位、故障恢復、故障改進。而對 IT 系統故障的發現和定位，正是可觀測問題的另一種詮釋，某種程度上也最接近可觀測問題本質的定義。
在此基礎上，我們可以將可觀測問題大致分為四類：
分散式鏈路追蹤技術：可觀測的基石
APM：Application Performance Monitoring ，應用效能監控
NPM：Network Performance Monitoring ，網路效能監控
RUM：Real User Monitoring，真實使用者監控
其中，分散式鏈路追蹤技術的核心思想是：在使用者一次請求服務的調 過程中，無論請求被分發到多少個子系統，子系統又呼叫了多少其他子系統，我們都要把系統資訊和系統間呼叫關係都追蹤記錄下來，最終把資料集中起來做視覺化展示。（引用自《怎麼理解分散式鏈路追蹤技術》，作者：蔣志偉，該文章會在專題的後續更新中放出）
APM 主要是為了對企業核心業務系統進行效能的故障定位和處理，幫助最佳化效能，提高業務系統的可靠性和使用者體驗，更多偏向產品維度，其底層雖依賴分散式鏈路追蹤技術，但不能直接用來解決分散式鏈路追蹤的問題 —— 這是此前很多工程師容易混淆的問題。（《在生產環境如何選擇靠譜的 APM 系統》，作者：蔣志偉，該文章會在專題的後續更新中放出）
NPM ，顧名思義，其關鍵在於實現全網流量的視覺化，對資料包、網路介面、流資料進行監控和分析。
RUM 的關鍵在於端到端反應使用者的真實體驗，捕捉使用者和頁面的每一個互動並分析其效能，是種高度實用主義的監控設計。
同時，可觀測存在三個主要的資料來源：
指標（metrics）
鏈路（trace）
日誌（log）
其中指標告訴我們是否有故障，鏈路告訴我們故障在哪裡，日誌則告訴我們故障的原因。
這三類可觀測問題加上三種監控型別，共同構成了可觀測問題的主要內容。
不同企業如何建設可觀測體系
不過對於一個企業來說，想構建可觀測體系，並不意味著要直接復刻上述所有目標維度。不同的企業型別，以及不同的行業背景，都有不同的側重點和建設方式。我們可以簡單將建設方式分為三種情況：
自研；
採用開源作品；
購買 SaaS 服務；
再來看看，如何應用其中 1 - 3 條方式完成企業的可觀測體系建設。
首先，從團隊規模來說，可分為幾種不同的情況。
第一類：企業是網際網路大廠，整體業務併發量非常大，穩定性要求很高。那麼開源產品基本很難滿足需求，只能依賴自研。因為達到一定規模的併發量與可靠性要求，在業內永遠是少數派，開源產品很難遵循這樣的演進路線。
第二類：中型企業，位於行業腰部，沒有特別高的效能要求，同時有一定的自研能力。該類企業在可觀測體系的建設上可以有三種思路：
如果目前技術棧內全部是主流框架、元件和程式語言，可以嘗試直接採用開源產品，或是基於開源產品做定製化改造。當然，要注意反哺社群，有出有進；
如果包含一部分非主流框架或程式語言，比如 。net ，可以嘗試單獨購買第三方 SaaS 服務；
如果包含一部分非主流框架或程式語言，且對自研能力非常有信心，可以圍繞這部分進行自研；
第三類：創業公司。創業公司的業務、方向都可能出現較大變化，資料體系也不一定非常健全，所以創業公司可以暫緩建設可觀測體系。
第四類：非 IT 技術驅動的傳統企業，如律師事務所、報社等，只要能保證服務高可用（相對於當下業務的忍耐度），可以不購買或自研建設可觀測體系。可觀測體系是為了解決 IT 故障，不是為了顯示技術團隊很牛。如果需要的話，可以直接購買第三方服務。
企業在不同生命週期的方案不同，因為所處行業不同，對可觀測體系的需求也會有較大差異。
蔣志偉為 InfoQ 記者舉了個例子：“比如說，電商行業可能對鏈路和日誌監控的聯動要求很高，但物聯網系統可能很多不需要鏈路監控。銀行系統業務迭代不頻繁，看重故障系統化改進， 更關心壓測系統。”
因行業背景而產生巨大差異的案例還有很多，像 IoT 因為行業特性，也基本沒有鏈路追蹤訴求。凡此種種，難以盡述，更為行之有效的辦法，是找一找該行業內的標杆企業，觀察一下他們可觀測體系是如何建設的。
國內外可觀測行業與技術發展現狀
行業和技術的發展情況，則是我們應當關注的，最後、最重要的一個維度。
首先是行業層面。目前國內的行業發展和創新，仍然有些“矽谷追隨者”的感覺，Datadog 的市值翻倍，給了大家信心，這讓國內可觀測產品的孵化速度正在加快。
在美國，Datadog 是該領域絕對的“當紅炸子雞”。蔣志偉對 InfoQ 記者說：
“Datadog 的獲客成本非常低，銷售佔公司人員比例很少，大部分都是研發——他們的市場擴充套件，依賴的就是口碑和社群。Datadog 的 Slack 群聊中，居然有五萬多名商業客戶，這些客戶每天都在丟擲自己的需求和問題。而 Datadog 也以驚人的速度更新版本，滿足這些客戶的訴求。雙向打磨下來，這些客戶其實已經無法離開 Datadog —— 只有 Datadog 才能滿足他們的需求。這是開源軟體相對難以實現的商業閉環。”
阿爾法公社一篇 2020 年的採訪顯示：Datadog 上市後的年利潤增長率達到了 82%，Rule of 40（SaaS 行業關鍵指標：增長率+利潤率不低於 40%）高達 93%，淨收入留存率 > 145%，三者皆是行業領先水平，是 SaaS 行業絕對的“頭部玩家”。
事實上，Datadog 的成功只是 APM 行業在美高速發展的一個象徵。如 DataTrace、Splunk 等企業不但透過高客單價保證了營收，也合力使 APM SaaS 產品覆蓋了超過 50% 的美國市場。
相比較之下，國內的可觀測產品還處於發展期，但也有 Skywalking 這樣的開源作品，以及阿里雲 ARMS、Prometheus 這樣的商業產品，提供了比較好的使用體驗。
但 ARMS 也暴露出一個可觀測的關鍵技術障礙 —— 資料孤島問題。如果要在企業內建設完善的可觀測體系，很可能會形成鏈路監控、日誌監控、指標監控等多套不同的監控系統，要打通是相當困難的。不同的業務線間，日誌規則不互通，要完全互通也很困難。系統一旦過多，相關維護以及故障排除的時間成本就會大幅增加。
針對資料孤島問題，目前行業內的一大趨勢是：擁抱 OpenTelemetry。OpenTelemetry 是由一組 API 和庫構成的標準，由 OpenTracing 和 OpenCensus 專案的合併而來，服務於可觀測技術的底層資料採集，最早由微軟和 Google 發起，當下已經成為美國可觀測行業研發的事實標準 —— 微軟、Google、Datadog、Splunk 等企業全部採用 OpenTelemetry 完成底層的資料採集，而 OpenTelemetry 的主要貢獻者也來自這些公司。
OpenTelemetry 的特點在於制定統一的協議資料格式，並提供底層資料採集器。蔣志偉提到，OpenTelemetry 的資料採集器，目標是相容所有的語言、所有的系統。
而與 OpenTelemetry 打配合的各大廠，要負責提供相容該採集器的外掛系統，是資料能夠同步到這些企業的平臺。
這使得 OpenTelemetry 既不會因動了“資料的蛋糕”，引起生態抵制，也極大儲存了精力，得以專注於資料採集器，努力去相容“所有的語言、所有的系統”。可以說，OpenTelemetry 試圖從開源資料採集器的層面，解決可觀測資料孤島的問題，並且取得了開創性的成果和進展，值得特別關注。
關於 OpenTelemetry 發展的下一階段，蔣志偉認為，AIOps 可能是一個重點。可觀測的最終目的在於解決故障，如果能透過 AI 的手段，更高效的、自動化的排除故障，無疑又會開闢一個非常有想象力的技術應用領域。
參考連結：
https：//finance。sina。com。cn/tech/2020-10-24/doc-iiznctkc7346044。shtml