如何利用開源軟件設(shè)計數(shù)據(jù)監(jiān)控架構(gòu),獲取應(yīng)用數(shù)據(jù)的縱向視圖,支撐性能分析?

數(shù)據(jù)中心運維管理當(dāng)中,往往系統(tǒng)管理員、存儲管理員各有各的運維數(shù)據(jù)視圖。無論是分析故障還是搞性能優(yōu)化都不能以某個維度的線索數(shù)據(jù)將各個視圖串聯(lián)起來,不僅效率低下,而且非常被動。

本文來自微信公眾號“twt企業(yè)IT社區(qū)”。

數(shù)據(jù)中心運維管理當(dāng)中,往往系統(tǒng)管理員、存儲管理員各有各的運維數(shù)據(jù)視圖。無論是分析故障還是搞性能優(yōu)化都不能以某個維度的線索數(shù)據(jù)將各個視圖串聯(lián)起來,不僅效率低下,而且非常被動。本議題在于探討用開源工具將各個視圖整合的意義以及思路。

【欄目主編】趙海某金融系統(tǒng)高級主管:本議題由咪咕視頻軟件架構(gòu)師李杰及我本人發(fā)表針對議題下關(guān)鍵點的主張,幾位專家的主張在方正人壽技術(shù)經(jīng)理李小平、民生銀行數(shù)據(jù)庫架構(gòu)師孔再華及我本人等多位專家的復(fù)議后,形成了一定的共識,希望可以對同行有一定的參考。

李杰 咪咕視頻軟件架構(gòu)師:

實現(xiàn)統(tǒng)一的可觀測性需要一個集中的平臺,能夠整合不同來源的數(shù)據(jù),并提供一致的視圖和工具,以便開發(fā)和運營團隊更好地進行分析和決策。許多公司正在采用跨平臺的可觀測性解決方案,提高可觀測性水平和效率。

隨著分布式系統(tǒng)架構(gòu)變得越來越復(fù)雜,跟蹤和解決多云環(huán)境中的問題變得更具挑戰(zhàn)性。當(dāng)應(yīng)用程序或服務(wù)的數(shù)量在龐大的多云環(huán)境中達到某個臨界點時,我們將難以追蹤它們的位置和性能。因此,持續(xù)監(jiān)測海量高速數(shù)據(jù)流,以便及時識別生產(chǎn)中已知和未知的問題變得至關(guān)重要。這就是可觀測性和監(jiān)控的作用所在。對于IT、運營、QA和SRE團隊來說,可觀測性提供了一個有用的解決方案,可以全面了解多樣化和復(fù)雜系統(tǒng)的每個組件。

同時,隨著Kubernetes容器云編排平臺的推動,軟件系統(tǒng)正在經(jīng)歷一場革命性的變革,朝著復(fù)雜的云原生、開源和基于微服務(wù)的結(jié)構(gòu)發(fā)展。軟件系統(tǒng)已經(jīng)成為組織的核心組成部分。隨著組織的發(fā)展,軟件系統(tǒng)也變得更加復(fù)雜。在分布式系統(tǒng)中,多個組件同時發(fā)揮作用,因此監(jiān)控系統(tǒng)變得更加困難。監(jiān)控系統(tǒng)的任務(wù)包括查看系統(tǒng)的健康狀況、識別應(yīng)用程序問題、跟蹤請求的端到端流程等。不同的組件可能使用不同類型的監(jiān)控工具和警報機制來監(jiān)測、發(fā)現(xiàn)、識別和調(diào)試問題。

因此,基于實際的業(yè)務(wù)場景,如何能夠設(shè)計一款全方位一體化的全鏈路監(jiān)控架構(gòu),獲取應(yīng)用數(shù)據(jù)的縱向視圖,并且支撐性能分析便顯得尤為重要。

下一代的可觀測性平臺體系的規(guī)劃及建設(shè),需要滿足如下核心原則,具體如下:

一、統(tǒng)一的可觀測性

實現(xiàn)統(tǒng)一的可觀測性是首要問題。傳統(tǒng)公司通常聲稱擁有統(tǒng)一的可觀測平臺,但實際上只是提供了多個選項卡來訪問指標(biāo)、日志、跟蹤等數(shù)據(jù),無法真正解決問題。開發(fā)和運營團隊需要一個能夠在單個時間線上查看所有數(shù)據(jù)的中心化平臺。只有這樣,他們才能追蹤相關(guān)性,確定問題的根本原因,并快速解決問題。因此,實現(xiàn)統(tǒng)一的可觀測性需要一個集中的平臺,能夠整合不同來源的數(shù)據(jù),并提供一致的視圖和工具,以便開發(fā)和運營團隊更好地進行分析和決策。許多公司正在采用跨平臺的可觀測性解決方案,提高可觀測性水平和效率。

二、與供應(yīng)商無關(guān)(OTel)

許多公司尋求不依賴于單一供應(yīng)商的解決方案,以避免被限制在特定技術(shù)?;蚬?yīng)商的生態(tài)系統(tǒng)中。為此,許多科技公司正在為開放遙測(OTel)做出貢獻,并將其作為數(shù)據(jù)收集代理的首選工具。OTel具有互操作性、靈活性和改進的性能監(jiān)控等諸多優(yōu)勢。使用OTel,公司可以更輕松地集成不同的工具和服務(wù),并在不同的平臺上收集和分析數(shù)據(jù),無需擔(dān)心供應(yīng)商鎖定或技術(shù)限制。因此,OTel在實現(xiàn)供應(yīng)商無關(guān)的可觀測性方面起著重要作用,并將在未來繼續(xù)發(fā)揮重要角色。

三、預(yù)測型可觀測性

在人工智能時代,自動化和無人化已經(jīng)成為技術(shù)發(fā)展的趨勢。這使得系統(tǒng)能夠完成人類無法完成的任務(wù),例如通過機器學(xué)習(xí)在錯誤發(fā)生之前預(yù)測錯誤。然而,目前的可觀測性解決方案并沒有充分利用人工智能技術(shù),這需要更多創(chuàng)新。通過在可觀測性平臺中添加人工智能層,企業(yè)可以在問題發(fā)生之前預(yù)測問題,并在用戶或客戶知曉問題之前解決問題。這將有助于提高服務(wù)和產(chǎn)品質(zhì)量,并增強企業(yè)的聲譽和競爭力。因此,未來的可觀測性解決方案需要更多地集成人工智能技術(shù),以實現(xiàn)預(yù)測性可觀測性。這將需要更多的數(shù)據(jù)和算法支持,以建立準(zhǔn)確的模型和預(yù)測系統(tǒng),并為企業(yè)提供更好的決策支持和業(yè)務(wù)洞察。

四、成本最優(yōu)化模式

成本優(yōu)化是可觀測性領(lǐng)域面臨的關(guān)鍵挑戰(zhàn)。盡管云存儲成本不斷降低,但大多數(shù)可觀測性公司并沒有相應(yīng)地降低價格,導(dǎo)致客戶承擔(dān)高昂的成本,并且缺乏其他選擇??捎^測性公司應(yīng)避免向用戶收取不必要的存儲費用,僅收集和存儲有用的數(shù)據(jù),并刪除其余的數(shù)據(jù)。這將有助于降低存儲和處理數(shù)據(jù)的成本,并提高可觀測性的效率和性能。為實現(xiàn)成本優(yōu)化,可觀測性平臺需要采用智能數(shù)據(jù)采集和存儲策略,優(yōu)化數(shù)據(jù)的收集、保留和清理過程,以降低成本并提高資源利用率。

五、安全和隱私保護

在可觀測性平臺中,安全和隱私保護是至關(guān)重要的。公司需要確保采集的數(shù)據(jù)不會泄露敏感信息,并采取適當(dāng)?shù)陌踩胧﹣肀Wo數(shù)據(jù)免受未經(jīng)授權(quán)的訪問、篡改或泄露。此外,隱私法規(guī)也對數(shù)據(jù)的收集和使用提出了限制,公司需要遵守相關(guān)法規(guī)和標(biāo)準(zhǔn),保護用戶和客戶的隱私權(quán)。因此,可觀測性平臺需要具備強大的安全功能和隱私保護機制,以確保數(shù)據(jù)的安全性和合規(guī)性。

要實現(xiàn)可觀測性,最為核心的要素莫過于建立自己的可觀測性平臺模型,基于模型所定義,創(chuàng)建自己的工具、利用開源軟件或自定義開發(fā)可觀測性解決方案來創(chuàng)建可觀測系統(tǒng)。具體設(shè)計實現(xiàn)可參考如下圖所示。

640 (1).png

圖1全鏈路一體化可觀測性平臺參考架構(gòu)

通常情況下,設(shè)計一個能夠獲取應(yīng)用數(shù)據(jù)縱向視圖并支持性能分析的數(shù)據(jù)觀測架構(gòu)是一項復(fù)雜的任務(wù),涉及多個組件和技術(shù)。每個企業(yè)都有其獨特的業(yè)務(wù)特性和組織結(jié)構(gòu),因此可觀測性模型的建立方式各不相同。然而,采用基于OpenTelemetry和eBPF(Extended Berkeley Packet Filter)的全鏈路一體化可觀測性最佳實踐可以提供更強大的監(jiān)測和追蹤能力具體如下:

(1)集成OpenTelemetry和eBPF:首先,將OpenTelemetry和eBPF集成到我們的應(yīng)用和系統(tǒng)中。OpenTelemetry是一個開源的觀測框架,可以幫助我們在應(yīng)用代碼中嵌入追蹤和指標(biāo)采集邏輯。而eBPF作為一個功能強大的內(nèi)核技術(shù),可用于在系統(tǒng)級別進行觀測和監(jiān)測。通過將這兩個工具進行集成,我們可以實現(xiàn)全鏈路的可觀測性。

(2)定義關(guān)鍵指標(biāo)和追蹤點:根據(jù)業(yè)務(wù)需求和關(guān)注點,定義關(guān)鍵的性能指標(biāo)和追蹤點。這些指標(biāo)可以包括請求響應(yīng)時間、資源利用率、錯誤率等。借助OpenTelemetry和eBPF,我們可以在應(yīng)用代碼中定義自定義的追蹤點和指標(biāo)采集邏輯,并在系統(tǒng)級別通過eBPF收集關(guān)鍵數(shù)據(jù)。

(3)分布式追蹤和跨進程追蹤:利用OpenTelemetry的分布式追蹤功能,追蹤請求在系統(tǒng)中的流動路徑。使用OpenTelemetry的追蹤上下文傳遞機制,確保跨進程和跨服務(wù)的請求能夠被追蹤和監(jiān)測。通過結(jié)合eBPF的功能,可以在系統(tǒng)級別收集分布式追蹤數(shù)據(jù),提供更全面的觀測能力。

(4)使用eBPF進行系統(tǒng)觀測:利用eBPF技術(shù),可以在內(nèi)核級別收集系統(tǒng)的關(guān)鍵指標(biāo)和事件。使用eBPF可以監(jiān)測網(wǎng)絡(luò)流量、系統(tǒng)調(diào)用、文件系統(tǒng)訪問等。通過分析和監(jiān)測這些數(shù)據(jù),可以獲得對系統(tǒng)性能和行為的深入了解,幫助識別潛在的問題和優(yōu)化機會。

(5)采集和存儲數(shù)據(jù):使用OpenTelemetry和eBPF收集的指標(biāo)和追蹤數(shù)據(jù),可以發(fā)送到各種后端存儲和分析系統(tǒng)進行處理。例如,可以將數(shù)據(jù)發(fā)送到Prometheus、Grafana、Elasticsearch等工具進行實時監(jiān)測和可視化。同時,將數(shù)據(jù)存儲到長期存儲系統(tǒng),如InfluxDB、TimescaleDB或數(shù)據(jù)湖中,以便進行更長期的分析和回溯。

(6)可視化和警報:利用可視化工具和儀表盤,如Grafana,將收集的指標(biāo)和追蹤數(shù)據(jù)轉(zhuǎn)化為易于理解的圖表和圖形。創(chuàng)建自定義的儀表盤,以便實時監(jiān)測系統(tǒng)的狀態(tài)和趨勢。同時,設(shè)置警報規(guī)則和閾值,以便在系統(tǒng)性能下降或異常情況發(fā)生時及時通知相關(guān)團隊。

持續(xù)優(yōu)化和改進:全鏈路一體化的可觀測性是一個持續(xù)的過程,需要不斷優(yōu)化和改進。根據(jù)實際運行情況和用戶反饋,調(diào)整和改進指標(biāo)設(shè)定、追蹤點和數(shù)據(jù)收集策略,以更好地滿足業(yè)務(wù)需求和關(guān)注點。

需要注意的是,以上步驟僅提供了一個總體框架,具體實施可能因應(yīng)用程序的特性和需求而異。在設(shè)計數(shù)據(jù)觀測架構(gòu)時,還應(yīng)考慮數(shù)據(jù)保護和隱私等方面的問題,并遵守適用的法律法規(guī)。

未來的可觀測性將需要更加智能化和自動化。人工智能和機器學(xué)習(xí)等新技術(shù)將成為可觀測性的重要組成部分,幫助開發(fā)人員和運維人員更好地了解系統(tǒng)和應(yīng)用程序的運行狀態(tài),并自動化地識別和解決問題。同時,隨著云原生技術(shù)的發(fā)展,容器、微服務(wù)和無服務(wù)器架構(gòu)等新技術(shù)也將對可觀測性產(chǎn)生深遠(yuǎn)的影響。

未來的可觀測性還需要更加全面和綜合。除了傳統(tǒng)的日志管理、度量指標(biāo)和分布式跟蹤等技術(shù),還需要考慮事件管理、故障注入和安全監(jiān)控等方面的需求。這些技術(shù)將有助于建立更全面、更可靠的可觀測性系統(tǒng),幫助企業(yè)更好地管理和維護復(fù)雜的系統(tǒng)和基礎(chǔ)設(shè)施。

趙海 某保險集團高級主管:

打破傳統(tǒng)數(shù)據(jù)中心各IT條線的角色邊界,以業(yè)務(wù)和應(yīng)用要求為目標(biāo),以數(shù)據(jù)流線索為出發(fā)點,利用開源軟件及相關(guān)工具建立一套整合的系統(tǒng)監(jiān)控和性能分析視圖是數(shù)據(jù)中心運維模式革新的必然趨勢。

一、引言

醫(yī)院的醫(yī)生可能最難診斷的就是時有時無并且沒有明顯征兆的慢性病。同理,企業(yè)數(shù)據(jù)中心運維人員最頭疼的可能就是性能分析問題了。或許很多人會說性能診斷是高級工程師必備的課程,都會有相應(yīng)的工具和方法。沒錯,系統(tǒng)管理員會有成熟的性能分析工具和思路,比如對于IO性能問題,他們會用相應(yīng)的診斷工具去判斷IOPS、吞吐量、響應(yīng)時間等相關(guān)指標(biāo);數(shù)據(jù)庫管理員也會針對數(shù)據(jù)庫的性能問題去分析他們的AWR報告;存儲管理員會根據(jù)自身產(chǎn)品的后臺性能分析工具和指標(biāo)來判斷存儲的運行狀況??梢哉驹谄髽I(yè)的角度,其實關(guān)注的是業(yè)務(wù)和應(yīng)用層面的性能,一方面,IT層面的良好運行不一定代表上層系統(tǒng)就一定沒有問題。另外一方面,當(dāng)表現(xiàn)為上層性能問題的時候,我們是否可以準(zhǔn)確反推到IT的某一個環(huán)節(jié)呢?因此將傳統(tǒng)的相互割裂的性能分析方法有效形成完整的系統(tǒng)性解決方案就需要關(guān)聯(lián)縱向聯(lián)系。

二、性能分析需要的數(shù)據(jù)監(jiān)控視圖

企業(yè)數(shù)據(jù)中心要做一個完整的性能分析或者性能解決方案,那么都需要監(jiān)控哪些指標(biāo)?簡單來講,我們認(rèn)為數(shù)據(jù)從客戶端流向服務(wù)器端之后的每一個環(huán)節(jié)都應(yīng)該是需要監(jiān)控或者關(guān)注的監(jiān)控視圖。毋庸置疑,這里會涉及到數(shù)據(jù)中心網(wǎng)絡(luò)、服務(wù)器及操作系統(tǒng)、應(yīng)用及中間件、數(shù)據(jù)庫以及最終數(shù)據(jù)落盤的存儲設(shè)備。

1.網(wǎng)絡(luò)監(jiān)控視圖

傳統(tǒng)運維模式下,網(wǎng)絡(luò)工程師關(guān)注性能相關(guān)的場景主要為:

(1)網(wǎng)絡(luò)設(shè)備自身的運行指標(biāo),例如設(shè)備的資源使用情況、繁忙程度、數(shù)據(jù)吞吐能力等。

(2)負(fù)載均衡資源池運行指標(biāo),例如資源池分發(fā)是否正常,有沒有排隊或丟失的情況等。

(3)域名解析相關(guān)設(shè)備的運行指標(biāo),域名在哪一級解析出來,解析響應(yīng)機制及時間是否正常等。

(4)配合應(yīng)用及數(shù)據(jù)庫工程師進行網(wǎng)絡(luò)抓包分析,主要看數(shù)據(jù)包的流向以及滯留時間。

2.操作系統(tǒng)監(jiān)控視圖

傳統(tǒng)運維模式下,服務(wù)器與系統(tǒng)工程師應(yīng)該是一個角色。其關(guān)注的也主要是服務(wù)器及操作系統(tǒng)層面的性能分析場景。根據(jù)系統(tǒng)資源類型的不同,他們會分析系統(tǒng)內(nèi)網(wǎng)絡(luò)、CPU、內(nèi)存、IO等相關(guān)性能問題。不同資源會有不同的性能診斷工具(每一種操作系統(tǒng)都會有很多性能診斷工具,例如Linux的top、vmstat、iostat、sar)和思路。無論是哪一種類型的資源分析,最終會關(guān)注資源使用的效率是否正常,是否有排隊、阻塞,是否有與正常情況不符合的異?,F(xiàn)象。

3.數(shù)據(jù)庫監(jiān)控視圖

傳統(tǒng)運維模式下,數(shù)據(jù)庫工程師做性能分析最得力的工具莫過于數(shù)據(jù)庫本身輸出的一些性能報告了。例如Oracle的AWR報告,它是一個數(shù)據(jù)庫層面相對系統(tǒng)性的分析報告。它會從資源、事件、作業(yè)等幾個維度去統(tǒng)計詳細(xì)的各類指標(biāo),往往數(shù)據(jù)庫工程師會從資源的使用情況追溯到事件的異常,最終追溯到某幾個或某一個SQL,然后在對SQL的執(zhí)行過程以及數(shù)據(jù)庫當(dāng)中的邏輯對象來判斷應(yīng)用執(zhí)行層面的問題。

4.存儲監(jiān)控視圖

存儲監(jiān)控視圖一般都會集成到存儲產(chǎn)品本身的管理界面上。同樣的思路,存儲監(jiān)控也會從幾個維度去監(jiān)控自身存儲設(shè)備的性能狀況:

(1)資源維度的運行指標(biāo),例如控制器的繁忙程度以及利用率情況。

(2)網(wǎng)絡(luò)接口的運行指標(biāo),例如前后端接口的繁忙程度以及均衡程度,吞吐數(shù)據(jù)的能力。

(3)緩存類資源的運行指標(biāo),例如緩存利用率、命中率、換入換出、鎖等相關(guān)指標(biāo)。

(4)存儲卷的讀寫情況,包含邏輯卷以及物理卷的讀寫速度、排隊、堵塞等相關(guān)指標(biāo)。

三、性能分析當(dāng)中的瓶頸問題

按照前文描述,每個工程師都有自己的對于性能診斷分析的工具和方法,似乎很完整。

但是,仔細(xì)品味過后,是不是感覺各個IT層面角色的關(guān)注點都局限在于自身的層面,每一個層面內(nèi)部的分析都比較全面完整,從資源層面到作業(yè)層面都有相應(yīng)的工具和思路來判斷。但是相互之間的聯(lián)系就看不到多少了。系統(tǒng)運行商,網(wǎng)絡(luò)、系統(tǒng)、數(shù)據(jù)、存儲組成了支撐業(yè)務(wù)運行的整體系統(tǒng)。性能分析上,它們似乎都是相互獨立的模塊。

傳統(tǒng)運維場景下,一旦業(yè)務(wù)層面或者應(yīng)用層面感覺到了業(yè)務(wù)行為的慢或者其他性能問題。通常的模式都是把所有工程師叫到一起,各查各的領(lǐng)域。如果幸運的話,有精通各領(lǐng)域的技術(shù)專家最后根據(jù)各個層面發(fā)現(xiàn)的異常點再去做匯總和梳理分析,最終經(jīng)過反復(fù)排查和測試,可能會定位到問題所在。這種模式應(yīng)該叫做排查,多少顯得有些被動和效率不足,難以適應(yīng)今天要求效率的互聯(lián)網(wǎng)時代。

四、如何打通數(shù)據(jù)縱向聯(lián)結(jié)形成整體視圖

其實在談打通數(shù)據(jù)縱向聯(lián)結(jié)形成整體視圖之前,我們應(yīng)該明白為什么要這么做,這么做的目的是解決什么問題。前文我們說到了傳統(tǒng)性能分析當(dāng)中的困惑在于從業(yè)務(wù)或應(yīng)用層面發(fā)現(xiàn)的問題,只能通過排查、匯總、梳理的方式來解決。換一種思路,我們能不能像警察辦案一樣順著線索去追查呢?這就需要解決兩個問題:首先,什么是線索?其次,誰是刑偵工具?

1.線索

業(yè)務(wù)運行過程當(dāng)中,企業(yè)的要求有兩個:首先,業(yè)務(wù)連續(xù)性;其次,業(yè)務(wù)效率性。性能問題往往影響在業(yè)務(wù)的效率上,例如:本來應(yīng)該秒級完成的業(yè)務(wù)用了好多分鐘,本來應(yīng)該順利完成的業(yè)務(wù)動作一致停留在等待的狀態(tài)。作為企業(yè)的科技人員,首先要明確每一筆業(yè)務(wù)關(guān)聯(lián)的業(yè)務(wù)路徑和數(shù)據(jù)行為:

(1)業(yè)務(wù)路徑。所謂業(yè)務(wù)路徑就是這個業(yè)務(wù)行為表現(xiàn)出來的問題源頭在哪里?是如何傳導(dǎo)到服務(wù)端的?服務(wù)端的響應(yīng)是什么?例如我們擁有應(yīng)用監(jiān)控的話,可以監(jiān)控到服務(wù)端收到的每一個時刻點的每一個業(yè)務(wù)行為,并且可以監(jiān)控到最終的反饋。這樣就可以將問題定位在服務(wù)提供端之前還是之后。

(2)數(shù)據(jù)行為及業(yè)務(wù)關(guān)系視圖。所謂數(shù)據(jù)行為就是這個業(yè)務(wù)落到IT層面表現(xiàn)出來的行為到底是什么?是讀還是寫?是讀寫哪些數(shù)據(jù)?這個是我們追溯到IT層的基本前提。例如銀行的交易系統(tǒng),往往一個交易行為會涉及多個系統(tǒng)的讀寫,這個關(guān)系視圖如果不提前建設(shè)起來,那么后面的追溯就無的放矢,就算可以進行也很可能是盲目的或者是錯誤的。

有了以上的兩個前提條件,如果需要繼續(xù)往下追溯的話。線索是什么呢?我們認(rèn)為有以下幾個維度可以幫助我們將其縱向串聯(lián):

(1)數(shù)據(jù)標(biāo)識。所謂數(shù)據(jù)標(biāo)識在網(wǎng)絡(luò)和系統(tǒng)層面對接過程中可以通過報文頭標(biāo)識來捕捉追溯,在數(shù)據(jù)庫層面可以通過SQL文標(biāo)識來捕捉,在系統(tǒng)和存儲的對接過程中可以通過Block標(biāo)識來捕捉追溯。當(dāng)然具體細(xì)節(jié)還需要根據(jù)不同的設(shè)備來具體分析和設(shè)計。

(2)時間點。通常來講,業(yè)務(wù)的發(fā)起時間我們是可以確定的,那么它在IT層面縱向傳遞的時刻點我們也是可以追溯的。如果我們的運維監(jiān)控體系足夠健全,那么某一個時刻點或者某個時刻片段內(nèi),各個層面發(fā)生的變化同樣可以可以追溯并梳理出來的。

(3)IT層面的邏輯關(guān)聯(lián)性。所謂IT層面的邏輯關(guān)聯(lián)性是指我們?yōu)橹我粋€業(yè)務(wù)系統(tǒng)運行,底層的基礎(chǔ)架構(gòu)是如何搭建出來的,各種資源的映射關(guān)系是要提前建立出來的。比如數(shù)據(jù)庫當(dāng)中的某個數(shù)據(jù)文件映射到操作系統(tǒng)的邏輯物理磁盤分別是什么?操作系統(tǒng)當(dāng)中的物理磁盤映射到存儲當(dāng)中是哪個邏輯資源池,這個邏輯資源池的緩存機制是什么?組成的物理資源池又是什么?類似這樣的邏輯關(guān)系是需要提前梳理出來并建立起相應(yīng)的視圖。

2.工具

企業(yè)數(shù)據(jù)中心IT的各個層面都有自己的監(jiān)控工具,通常有兩種方式:一種是通過腳本方式抓日志,另外一種是通過綜合監(jiān)控平臺向各個層面以數(shù)據(jù)的方式展示出來。這里面有個問題,腳本的方式屬于事后分析,效率欠佳功能有限。通用產(chǎn)品同樣無法適應(yīng)企業(yè)環(huán)境的差異性,畢竟不同企業(yè)采購的設(shè)備以及IT架構(gòu)的組合方式都會有所差異。

這個時候,我們可以把目光瞄向開源監(jiān)控軟件。開源監(jiān)控軟件的優(yōu)勢在于以下兩點:

(1)開放性:開源軟件是企業(yè)IT人員可以根據(jù)自己需求進行獨立設(shè)計和配置的軟件。雖然會非常復(fù)雜非常耗費IT人力資源,但是可以完美與客戶的差異化需求結(jié)合。正如前文所示,我們要實現(xiàn)對企業(yè)IT層面監(jiān)控分析的縱向整合。首先,必須要將梳理出來的應(yīng)用關(guān)系視圖、IT基礎(chǔ)架構(gòu)關(guān)系視圖提前定義到性能分析平臺當(dāng)中。其次,必須要根據(jù)自身環(huán)境特點將網(wǎng)絡(luò)與系統(tǒng)層、系統(tǒng)與數(shù)據(jù)庫層、系統(tǒng)與存儲層之間的數(shù)據(jù)線索定義到性能分析流程當(dāng)中。這些設(shè)計只有開源軟件可以實現(xiàn)。

(2)靈活性:相對于通用產(chǎn)品,開源軟件的靈活性在于其可控可修改性。企業(yè)的環(huán)境在不斷變化,企業(yè)的要求在不斷變化。這必然要求開源軟件能提供的功能和方式要適應(yīng)變化。比如,當(dāng)企業(yè)的應(yīng)用或者IT關(guān)系視圖發(fā)生變化時,那么我們是否可以定義一種新的數(shù)據(jù)類型來支撐它呢?通用產(chǎn)品是做不到的。

(3)腳本語言的天然融合性:很多優(yōu)秀的運維工程師喜歡自己定義一些Shell、Python等腳本來實現(xiàn)一些日志收集、分析等工作。究其原因在于自己定義的腳本與自己熟悉的環(huán)境的天然契合性,而與這些腳本再有天然契合性的就屬開源軟件了。優(yōu)秀的腳本可以整合到開源框架中,成為實現(xiàn)整體視圖的配件。

五、結(jié)語

簡言之,企業(yè)在每一次面臨業(yè)務(wù)性能問題的時候,往往需要投入大量的人力和時間來解決。從效率上和模式上都相對被動。如果在事前多花一些人力和時間,利用開源框架建立一套自己的性能分析框架,那么后期在面臨此類問題的時候,就會顯得主動并且高效。

結(jié)束語

通過本議題的討論,我們首先從必要性、可行性方面對數(shù)據(jù)中心監(jiān)控以及性能分析視圖整合建設(shè)的思路進行了論證,接著又從AI等智能工具引入的維度探討了建設(shè)的方法和思路?;旧峡梢哉J(rèn)為通過開源工具、腳本并引入智能化的算法是可以幫助數(shù)據(jù)中心建立起一套主動的監(jiān)控及性能分析視圖的。

THEEND

最新評論(評論僅代表用戶觀點)

更多
暫無評論