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