〇、導(dǎo)讀

可觀測性已成為一個熱門話題，并廣受關(guān)注。隨著它的普及，“可觀測性”不幸被誤作“監(jiān)控”或“系統(tǒng)遙測”的同義詞?？捎^測性是軟件系統(tǒng)的一個特征。而且，只有當(dāng)團隊采用新的實踐進行持續(xù)開發(fā)時，才能在生產(chǎn)軟件系統(tǒng)中有效利用這一特征。因此，將可觀測性引入系統(tǒng)既是一個技術(shù)挑戰(zhàn)，也是一個文化挑戰(zhàn)。接下來讓我們一起來了解一下可觀測性平臺。

一、實現(xiàn)可觀測性平臺的技術(shù)要點是什么？

隨著可觀測性理念的深入人心，可觀測性平臺已經(jīng)開始進入了落地階段，它的先進性已經(jīng)毋庸置疑；而另外一只靴子：它如何以一個統(tǒng)一融合的平臺在企業(yè)中生根發(fā)芽？

可觀測性并不是空穴來風(fēng)，也非關(guān)鍵詞炒作。大家不妨回顧一下我們所熟知的運維管理的演化歷程，拋開運維管理中關(guān)于流程和人的那些繁文縟節(jié)。讓我們只關(guān)注于：基礎(chǔ)設(shè)施和應(yīng)用架構(gòu)的變遷，關(guān)注于這些層出不窮的技術(shù)工具側(cè)面。

二、兼容全域信號量

從遙測方式的角度看：任何類型的信號都有各自的用途和道理，武斷地選取其一作為可觀測性的代名詞是一種比較偏激的想法，在Debug生產(chǎn)環(huán)境的道路上，我們難以依靠單一方法。我們要根據(jù)不同應(yīng)用系統(tǒng)的特點和服務(wù)類型，選擇合理的SLI組合，用恰當(dāng)?shù)男盘柫縼砀采w目標(biāo)應(yīng)用系統(tǒng)，目標(biāo)是打造應(yīng)用系統(tǒng)本身的「可觀測性屬性」。這樣，你就必須要明智地選擇、添加或變化信號類型，要能做到按需求，對癥下藥。這里不是監(jiān)控數(shù)據(jù)源越多越好，盲目的全面覆蓋亦是事倍功半的做法；在應(yīng)對高維度、高基數(shù)的運維大數(shù)據(jù)的場景中，我們很容易走向存儲成本飆升的局面，無效雜音數(shù)據(jù)還能嚴(yán)重稀釋有價值的信息點。

三、所謂全域信號量有哪些？

• 日志Log：文本記錄系統(tǒng)和應(yīng)用的活動、事件和錯誤，提供詳細(xì)上下文。

• 指標(biāo)Metric：定量的性能度量，如CPU使用率、請求速率，幫助監(jiān)控系統(tǒng)狀態(tài)。

• 分布式追蹤Trace：跟蹤請求在分布式系統(tǒng)中的路徑和性能瓶頸。

• 流數(shù)據(jù)Stream：實時產(chǎn)生的數(shù)據(jù)，如用戶行為，用于即時監(jiān)測和分析。

• 用戶體驗數(shù)據(jù)RUM：記錄用戶在應(yīng)用中的交互、操作和反應(yīng)，評估體驗質(zhì)量。

• eBPF：擴展Berkeley Packet Filter，收集內(nèi)核級別的數(shù)據(jù)，用于分析和監(jiān)控。

• 網(wǎng)絡(luò)性能管理NPM：監(jiān)測網(wǎng)絡(luò)帶寬、延遲和連接狀況，優(yōu)化網(wǎng)絡(luò)性能。

• Profiling：分析代碼運行時的性能特征，幫助優(yōu)化應(yīng)用程序。

• 云服務(wù)Cloud：從云提供商獲取的監(jiān)測數(shù)據(jù)，跟蹤資源使用和性能。

• 撥測數(shù)據(jù)Uptime/synthetics：定期對系統(tǒng)進行外部測試，監(jiān)測系統(tǒng)在不同地點和條件下的可用性和性能。

• 未來新技術(shù)：未知類型數(shù)據(jù)。

「可觀測性管理平臺」應(yīng)當(dāng)以兼容并蓄全方位的信號量為初始設(shè)計目標(biāo)。這意味著：在觀測數(shù)據(jù)的采集、上傳、存儲、展示以及關(guān)聯(lián)分析的整個過程中，各類數(shù)據(jù)都需要被正確處理，能更合理、有效地進行跨類型的數(shù)據(jù)關(guān)聯(lián)；在數(shù)據(jù)下鉆的過程中，可以自由地在各種時間線之間跳轉(zhuǎn)和探索。

當(dāng)然，監(jiān)控已知的「未知」是一項基本的管理需求，你應(yīng)當(dāng)能使用某一種信號量即可實現(xiàn)。而可觀測性更多的是要討論：在「未知」?fàn)顟B(tài)間進行變化的管理；這就需要「可觀測性平臺」能處理多層級、高依賴、多云環(huán)境、分布式系統(tǒng)下的高「復(fù)雜度」，信號量的全面準(zhǔn)備和按需取用往往也只是一個必要條件。

目前市場上已經(jīng)有許多運維管理平臺都自稱為「可觀測性」管理平臺。但他們中的大多數(shù)是從某個特定監(jiān)控類型開始，并逐漸擴展覆蓋其他更多信號類型。通常，只有能夠涵蓋3種以上信號類型的平臺，才可能具有出色的實用效果；對于那些已經(jīng)是有3至5年歷史的「可觀測性」產(chǎn)品而言，他們不太可能在短期內(nèi)實現(xiàn)華麗的轉(zhuǎn)身，也不可能會從頭重構(gòu)一遍自己的產(chǎn)品。

四、統(tǒng)一采集和上傳工具

在物理機大行其道的時代中，對于一臺主機（虛擬機或者物理機）而言，由于它很可能承擔(dān)著多重角色。而且根據(jù)不同團隊的管理需求，在其操作系統(tǒng)中會安裝多種管理監(jiān)控代理程序Agent，例如：操作系統(tǒng)指標(biāo)、日志、數(shù)據(jù)庫、中間件、安全巡檢等等；這種疊羅漢的形式不僅給操作系統(tǒng)的資源帶來了嚴(yán)重的消耗，甚至還給服務(wù)器的管理帶來了大量的瑣事，例如：數(shù)據(jù)庫監(jiān)控Agent還需要創(chuàng)建專用的用戶賬號等。為了解決這個問題，很多公司希望使用盡可能少的單一采集代理的模式，例如：BMC公司的Patrol監(jiān)控產(chǎn)品，擁有多種采集模塊KM（數(shù)據(jù)庫、中間、web服務(wù)器等等），用戶可以按需要進行配置，而不需要部署多個采集代理程序。然而，BMC公司會逐漸收購很多新產(chǎn)品，后來的產(chǎn)品有動態(tài)性能基線管理、自動化配置管理等等。從工具廠商的角度看，他們無法進行快速的產(chǎn)品整合，很難維持單一采集代理的局面。

在甲方企業(yè)的環(huán)境中，不同部門會根據(jù)自己的需求采購不同的管理工具，部門間的差異導(dǎo)致了工具的重復(fù)建設(shè)，數(shù)據(jù)的重復(fù)采集，而且數(shù)據(jù)并不會很輕易的在部門間共享。這樣不僅帶來了采集工具在同一個主機上的疊加部署，還會導(dǎo)致：獨立運行著大量具有重復(fù)數(shù)據(jù)的孤島運維數(shù)據(jù)數(shù)據(jù)庫。這種局面進一步導(dǎo)致了其他問題，例如：同一個主機的同一個故障會在各種工具中都觸發(fā)多條告警事件；事件風(fēng)暴來臨了。這種混沌的局面，給AIOps的工具帶來了生存的空間，即使可以產(chǎn)生一些事件收斂和壓縮的收益，但這里存在著一個很明顯的“治標(biāo)不治本”的錯誤。

時光穿梭到了虛擬化&云原生時代，以上局面并沒有發(fā)生根本性的改變。反而帶來了套娃式深層依賴關(guān)系的困境。我們不會把web、中間件、數(shù)據(jù)庫、消息隊列等功能跑在一個POD中，但是將其各自獨立部署在可橫向擴容的子服務(wù)（容器服務(wù)）中后，這就帶來了管理對象的數(shù)量呈現(xiàn)指數(shù)級飆升的現(xiàn)狀。容器時代帶來了新鮮的監(jiān)控工具，包括：Prometheus、Grafana、FluntD、Graphite、cAdvisor、Loki、EFK等等。我們可以觀察到，新生的工具并不會完全改變：多種采集功能代理并存&疊加的局面。Elastic看到了部署多種相似代理程序的問題后，最近幾年很快的將之前的多種Beats程序（多次收購的項目）整合成到了一個統(tǒng)一代理Elastic Agent中，而這個程序目前還只是多個Beats程序的馬甲（包裝殼）程序。

多種采集工具集不僅在端點上會造成大量部署和配置的瑣事，而且，它們的后臺都對應(yīng)著各自的獨立的數(shù)據(jù)庫部署。同一個管理對象在不同的數(shù)據(jù)庫中的字段描述基本上都不同，這導(dǎo)致：工具集的使用者很難在各類數(shù)據(jù)庫中實現(xiàn)關(guān)聯(lián)分析，用人腦攜帶著排錯的上下文，在一堆控制臺之間跳轉(zhuǎn)是相當(dāng)消耗體力的工作，對齊時間線和監(jiān)控對象會很快耗盡人的認(rèn)知上限。

CMDB可能是一個解決方法，而CMDB的設(shè)計和建設(shè)的難度并不亞于構(gòu)建任何一個監(jiān)控系統(tǒng)項目本身，用CMDB解決這個問題的實現(xiàn)難度大，成本高。數(shù)據(jù)治理也會是一個常見做法，而在這些運維數(shù)據(jù)庫集合之間做ELT，做數(shù)據(jù)治理工作，最終實現(xiàn)異類運維信息的歸一化的解決方式，也只是一個順坡下驢的無奈之舉，相關(guān)實施人員在項目中必將飽嘗：將計就計的辛酸。

貌似最早由Elastic推出的統(tǒng)一數(shù)據(jù)模型（ECS）是一個讓數(shù)據(jù)走向標(biāo)準(zhǔn)化定義的可行之道。我們也看到了：OpenTelemetry項目很快就采納了Elastic ECS。CNCF在隨后也推出了相似的觀測數(shù)據(jù)定義模型。我相信CNCF一定是看到了，在它的技術(shù)藍圖中，可觀測性和分析分類中相似&同類工具的快速繁榮。而這些標(biāo)準(zhǔn)也只能讓我們望梅止渴，由于目前還沒有看到多數(shù)廠商、大量開源項目都快速跟隨實現(xiàn)和兼容落地的局面。

觀測云的 DataKit 是一款多功能的采集代理程序，它具備解決上述問題的設(shè)計，它已經(jīng)在兼容和對接更廣泛的技術(shù)生態(tài)系統(tǒng)。任何采集代理程序在采集或者對接到了目標(biāo)數(shù)據(jù)之后，它其實還需要處理一系列的細(xì)節(jié)，否則仍然無法實現(xiàn)「源頭治理」，無法避免「garbage in gargage out」的窘境。

首先，DataKit 在組織封裝數(shù)據(jù)時，所有字段的定義都遵從著一個觀測云定義的數(shù)據(jù)字典（等同于Elastic ECS）；
其次，上報數(shù)據(jù)包在封包前，還能做數(shù)據(jù)的Pipline處理，實現(xiàn)了數(shù)據(jù)字段的丟棄、質(zhì)量控制、治理和脫敏等問題。
最后，DataKit的采集還可實現(xiàn)對接開源&閉源生態(tài)系統(tǒng)，例如接收DataDog的APM探針數(shù)據(jù)，對接OpenTelemetry的數(shù)據(jù)等等。它還能實現(xiàn)觀測數(shù)據(jù)在網(wǎng)際、網(wǎng)絡(luò)間的轉(zhuǎn)發(fā)等。

五、統(tǒng)一的存儲后臺

在構(gòu)建可觀測性平臺的過程中，每種類型的信號量都理應(yīng)得到它最佳的容身之處：

• Elasticsearch：在Elastic的ECS的加持之下，貌似它是一個很恰當(dāng)?shù)囊粠齑嫠械姆桨?，但前提是你需要能hold住性價比。

• 時序數(shù)據(jù)庫：不一一列舉，適合指標(biāo)類時序數(shù)據(jù)。

• 列數(shù)據(jù)庫：以ClickHouse為代表的實時數(shù)據(jù)分析的列數(shù)據(jù)庫，可兼容多種信號。

• 關(guān)系型數(shù)據(jù)庫：WHY NOT。

從數(shù)據(jù)入庫的角度看，給每種信號量配置其最佳的數(shù)據(jù)庫類型，貌似是一個皆大歡喜的局面。這也不辜負(fù)，目前各種開源數(shù)據(jù)庫百花齊放的形勢。

略過上面已經(jīng)提到的數(shù)據(jù)孤島和治理問題不談。從查詢的角度看，用戶將不得不學(xué)會多種查詢語言，前方有n種SQL語法需要你學(xué)習(xí)，否則你不得不開發(fā)維護一個一對多的查詢界面。這里我們暫且不論述：你會如何實現(xiàn)可觀測性數(shù)據(jù)的跨庫數(shù)據(jù)關(guān)聯(lián)分析。

問題：是否存在一種多模態(tài)的統(tǒng)一數(shù)據(jù)庫，將多種類型的信號量數(shù)據(jù)融入一個統(tǒng)一的數(shù)據(jù)倉庫中？

實際上，目前的可觀測性SaaS提供商們，已經(jīng)給他們的用戶提供了這樣一種統(tǒng)一融合的數(shù)據(jù)后端，起碼從查詢探索可觀測性數(shù)據(jù)的使用體感的角度上，確實是已經(jīng)做到了。而觀測云也正在推出這樣一款解決以上統(tǒng)一融合多態(tài)并存管理需求的數(shù)據(jù)庫。觀測云用戶很快將在SaaS服務(wù)中，在私有部署的產(chǎn)品上使用到這種技術(shù)。

六、自由探索和綜合使用數(shù)據(jù)

可觀測性數(shù)據(jù)的價值體現(xiàn)在使用上，能自由的探索和綜合的使用各種數(shù)據(jù)，才能放大數(shù)據(jù)的價值。在考慮到可觀測性數(shù)據(jù)使用場景的時候，小編強烈建議大家運用「第一性原理」來進行思考，這樣才能避免對經(jīng)驗的依賴，排除對新可觀測性技術(shù)能平替所有舊技術(shù)的單純幻想，才能回到可觀測性技術(shù)的概念本源。

七、總結(jié)

本文從四個層面上對實現(xiàn)可觀測性平臺的技術(shù)要點，做出了一定深度和時間跨度上的探討。希望：在您的工作環(huán)境中，統(tǒng)一融合的可觀測性平臺可以很快的落地。穿上兩只靴子的你，可以脫離以前赤足上陣，光腳救火的困境。希望可觀測性平臺能夠幫助到軟件交付流水線中的所有人，運用可觀測性來補Ops的鍋，助SRE的威，壯Dev膽。

★推薦閱讀《可觀測性工程》

推薦理由：谷歌SRE核心專家、可觀測性社區(qū)領(lǐng)袖撰寫，國內(nèi)可觀測性領(lǐng)域獨角獸企業(yè)觀測云團隊傾情翻譯?？捎^測性技木落地買踐指南，有效解決云原生時代軟件系統(tǒng)運維難度大的痛點。推動IT系統(tǒng)實現(xiàn)高效交付、統(tǒng)一運維和持久優(yōu)化。

適讀人群 ：

• 軟件工程師、產(chǎn)品經(jīng)理、軟件交付和運維人員。
• SRE和DevOps。
• 所有從事軟件開發(fā)、運維、測試等領(lǐng)域的專業(yè)人士，以及對系統(tǒng)可觀測性感興趣的人士。

直播預(yù)告

直播主題

現(xiàn)代化軟件工程新趨勢論壇暨《可觀測性工程》新書發(fā)布會

直播時間

9 月 20 日（星期三）19:00 - 20:30

《Observability Engineering》 出版于 2021 年，在海外已廣受好評，是每一位想要了解可觀測性技術(shù)的工程師都必須拜讀的書。2023年 9 月 20 日 晚 19:00 ，機械工業(yè)出版社華章分社將聯(lián)合本書的中譯者「觀測云團隊」，在線上舉辦新書發(fā)布會，與圈內(nèi)嘉賓們共同探索可觀測性技術(shù)的新趨勢與新未來。

預(yù)約直播 視頻號：CSDN 預(yù)約直播提醒：《開講》-現(xiàn)代化軟件工程新趨勢 ?； CSDN官網(wǎng)直播間也將同步轉(zhuǎn)播！

文章來源地址http://www.zghlxwxcb.cn/news/detail-721520.html

到了這里，關(guān)于【技術(shù)運維】SRE求職必會 —— 可觀測性平臺&可觀測性工程(Observability Engineering)的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！