?? 前言

????hello！ 各位鐵汁們大家好啊，今天給大家推薦的的是機(jī)械工業(yè)出版社的 《可觀測性工程》這本書！
????隨著可觀測性理念的深入人心，可觀測性平臺已經(jīng)開始進(jìn)入了落地階段，它的先進(jìn)性已經(jīng)毋庸置疑；而另外一只靴子：它如何以一個統(tǒng)一融合的平臺在企業(yè)中生根發(fā)芽
????下面就讓本博主給大家介紹介紹實(shí)現(xiàn)可觀測性平臺的技術(shù)要點(diǎn)是什么？也是本書的內(nèi)容核心一起來看看吧！
???? 歡迎鐵汁們 ?? 點(diǎn)贊 ?? 收藏 ?留言 ??！

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

1.兼容全域信號量

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

2.所謂全域信號量有哪些？

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

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

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

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

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

• eBPF：擴(kuò)展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ùn)行時(shí)的性能特征，幫助優(yōu)化應(yīng)用程序。

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

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

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

「可觀測性管理平臺」應(yīng)當(dāng)以兼容并蓄全方位的信號量為初始設(shè)計(jì)目標(biāo)。這意味著：在觀測數(shù)據(jù)的采集、上傳、存儲、展示以及關(guān)聯(lián)分析的整個過程中，各類數(shù)據(jù)都需要被正確處理，能更合理、有效地進(jìn)行跨類型的數(shù)據(jù)關(guān)聯(lián)；在數(shù)據(jù)下鉆的過程中，可以自由地在各種時(shí)間線之間跳轉(zhuǎn)和探索。當(dāng)然，監(jiān)控已知的「未知」是一項(xiàng)基本的管理需求，你應(yīng)當(dāng)能使用某一種信號量即可實(shí)現(xiàn)。而可觀測性更多的是要討論：在「未知」?fàn)顟B(tài)間進(jìn)行變化的管理；這就需要「可觀測性平臺」能處理多層級、高依賴、多云環(huán)境、分布式系統(tǒng)下的高「復(fù)雜度」，信號量的全面準(zhǔn)備和按需取用往往也只是一個必要條件。目前市場上已經(jīng)有許多運(yùn)維管理平臺都自稱為「可觀測性」管理平臺。但他們中的大多數(shù)是從某個特定監(jiān)控類型開始，并逐漸擴(kuò)展覆蓋其他更多信號類型。通常，只有能夠涵蓋3種以上信號類型的平臺，才可能具有出色的實(shí)用效果；對于那些已經(jīng)是有3至5年歷史的「可觀測性」產(chǎn)品而言，他們不太可能在短期內(nèi)實(shí)現(xiàn)華麗的轉(zhuǎn)身，也不可能會從頭重構(gòu)一遍自己的產(chǎn)品。

3.統(tǒng)一采集和上傳工具

在物理機(jī)大行其道的時(shí)代中，對于一臺主機(jī)（虛擬機(jī)或者物理機(jī)）而言，由于它很可能承擔(dān)著多重角色。而且根據(jù)不同團(tuán)隊(duì)的管理需求，在其操作系統(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ù)器等等），用戶可以按需要進(jìn)行配置，而不需要部署多個采集代理程序。然而，BMC公司會逐漸收購很多新產(chǎn)品，后來的產(chǎn)品有動態(tài)性能基線管理、自動化配置管理等等。從工具廠商的角度看，他們無法進(jìn)行快速的產(chǎn)品整合，很難維持單一采集代理的局面。在甲方企業(yè)的環(huán)境中，不同部門會根據(jù)自己的需求采購不同的管理工具，部門間的差異導(dǎo)致了工具的重復(fù)建設(shè)，數(shù)據(jù)的重復(fù)采集，而且數(shù)據(jù)并不會很輕易的在部門間共享。這樣不僅帶來了采集工具在同一個主機(jī)上的疊加部署，還會導(dǎo)致：獨(dú)立運(yùn)行著大量具有重復(fù)數(shù)據(jù)的孤島運(yùn)維數(shù)據(jù)數(shù)據(jù)庫。這種局面進(jìn)一步導(dǎo)致了其他問題，例如：同一個主機(jī)的同一個故障會在各種工具中都觸發(fā)多條告警事件；事件風(fēng)暴來臨了。這種混沌的局面，給AIOps的工具帶來了生存的空間，即使可以產(chǎn)生一些事件收斂和壓縮的收益，但這里存在著一個很明顯的“治標(biāo)不治本”的錯誤。

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

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

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

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

觀測云的 DataKit 是一款多功能的采集代理程序，它具備解決上述問題的設(shè)計(jì)，它已經(jīng)在兼容和對接更廣泛的技術(shù)生態(tài)系統(tǒng)。任何采集代理程序在采集或者對接到了目標(biāo)數(shù)據(jù)之后，它其實(shí)還需要處理一系列的細(xì)節(jié)，否則仍然無法實(shí)現(xiàn)「源頭治理」，無法避免「garbage in gargage out」的窘境。首先，DataKit 在組織封裝數(shù)據(jù)時(shí)，所有字段的定義都遵從著一個觀測云定義的數(shù)據(jù)字典（等同于Elastic ECS）；其次，上報(bào)數(shù)據(jù)包在封包前，還能做數(shù)據(jù)的Pipline處理，實(shí)現(xiàn)了數(shù)據(jù)字段的丟棄、質(zhì)量控制、治理和脫敏等問題。最后，DataKit的采集還可實(shí)現(xiàn)對接開源&閉源生態(tài)系統(tǒng)，例如接收DataDog的APM探針數(shù)據(jù)，對接OpenTelemetry的數(shù)據(jù)等等。它還能實(shí)現(xiàn)觀測數(shù)據(jù)在網(wǎng)際、網(wǎng)絡(luò)間的轉(zhuǎn)發(fā)等。

4.統(tǒng)一的存儲后臺

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

• Elasticsearch：在Elastic的ECS的加持之下，貌似它是一個很恰當(dāng)?shù)囊粠齑嫠械姆桨福疤崾悄阈枰躧old住性價(jià)比。

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

• 列數(shù)據(jù)庫：以ClickHouse為代表的實(shí)時(shí)數(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ā)維護(hù)一個一對多的查詢界面。這里我們暫且不論述：你會如何實(shí)現(xiàn)可觀測性數(shù)據(jù)的跨庫數(shù)據(jù)關(guān)聯(lián)分析。問題：是否存在一種多模態(tài)的統(tǒng)一數(shù)據(jù)庫，將多種類型的信號量數(shù)據(jù)融入一個統(tǒng)一的數(shù)據(jù)倉庫中？實(shí)際上，目前的可觀測性SaaS提供商們，已經(jīng)給他們的用戶提供了這樣一種統(tǒng)一融合的數(shù)據(jù)后端，起碼從查詢探索可觀測性數(shù)據(jù)的使用體感的角度上，確實(shí)是已經(jīng)做到了。而觀測云也正在推出這樣一款解決以上統(tǒng)一融合多態(tài)并存管理需求的數(shù)據(jù)庫。觀測云用戶很快將在SaaS服務(wù)中，在私有部署的產(chǎn)品上使用到這種技術(shù)。

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

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

總結(jié)

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

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

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

##購買鏈接
??京東的鏈接： https://u.jd.com/nb2cA1B

直播預(yù)告

直播時(shí)間

9 月 20 日（星期三）

19:00 - 20:30

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

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

參與方式

1?? 參與方式：關(guān)注博主、點(diǎn)贊、收藏、評論區(qū)評論，任意評論（每人最多評論三次）
2?? 獲獎方式：程序員隨機(jī)抽取 2 位幸運(yùn)粉絲，每位小伙伴將獲得此書！
3?? 活動截止時(shí)間：2023-09-24 20:00:00 | 由博主動態(tài)公布抽獎結(jié)果

?? 注：活動結(jié)束后，會私信中獎粉絲的，各位注意查看私信哦！

?? 文章末尾掃碼加入粉絲群，不定期發(fā)放粉絲福利，各種專業(yè)書籍免費(fèi)贈送！

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

到了這里，關(guān)于【咕咕送書第一期】 | SER運(yùn)維：實(shí)現(xiàn)可觀測性平臺的技術(shù)要點(diǎn)是什么？的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！