本文來自微信公眾號“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ù)陌踩胧﹣肀Ｗo數(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)可參考如下圖所示。
圖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)控及性能分析視圖的。
