摘要:高校數(shù)字化校園的運(yùn)維面臨部門間協(xié)作不足及監(jiān)控系統(tǒng)碎片化的挑戰(zhàn),導(dǎo)致運(yùn)維經(jīng)驗(yàn)和知識難以跨部門共享,且各獨(dú)立監(jiān)控系統(tǒng)僅提供孤立的靜態(tài)監(jiān)測數(shù)據(jù),缺乏有效整合與深入分析,從而影響了故障排查的效率與準(zhǔn)確性。針對以上情況,文章設(shè)計(jì)了一個基于知識圖譜的數(shù)字化校園運(yùn)維系統(tǒng)。該系統(tǒng)通過匯總以往的故障處置案例,挖掘并構(gòu)建故障間的內(nèi)在聯(lián)系,形成故障知識圖譜。同時,系統(tǒng)通過流量分析以及自動化測試技術(shù),實(shí)現(xiàn)自動化采集應(yīng)用系統(tǒng)的交互拓?fù)浣Y(jié)構(gòu)以及不同節(jié)點(diǎn)對故障的反饋情況。系統(tǒng)測試結(jié)果表明,該系統(tǒng)能夠正確推理出包含網(wǎng)絡(luò)安全設(shè)備、反向代理以及數(shù)據(jù)庫問題導(dǎo)致的故障。
關(guān)鍵詞:數(shù)字化校園運(yùn)維;知識圖譜;流量分析;故障推理
中圖分類號:TP311.1 "文獻(xiàn)標(biāo)志碼:A
0 引言
隨著高等教育信息化的不斷深化,高等院校在網(wǎng)絡(luò)基礎(chǔ)設(shè)施、數(shù)據(jù)中心硬件平臺、應(yīng)用系統(tǒng)及數(shù)據(jù)管理等多個方面取得了顯著成就,有效支撐了新時代背景下的教育、科研與校園生活需求[1]。然而,歷經(jīng)近十年的信息化建設(shè),系統(tǒng)間交互的復(fù)雜性日益增加,特別是在網(wǎng)絡(luò)架構(gòu)中引入軟件定義網(wǎng)絡(luò)(Software Defined Networking,SDN)[2]技術(shù)和多元化安全設(shè)備后,網(wǎng)絡(luò)流量的動態(tài)調(diào)度特性給故障診斷帶來了新難題。此外,虛擬化技術(shù)與云平臺的廣泛應(yīng)用,導(dǎo)致在高度抽象的集群環(huán)境中追蹤系統(tǒng)故障根源成為一項(xiàng)挑戰(zhàn)。
當(dāng)前,服務(wù)于數(shù)字化校園運(yùn)維的工具主要圍繞特定目標(biāo)展開,可分為3類:網(wǎng)絡(luò)硬件維護(hù)工具、數(shù)據(jù)中心硬件監(jiān)控工具及應(yīng)用系統(tǒng)運(yùn)維工具。網(wǎng)絡(luò)硬件維護(hù)工具雖然具備深度探測能力,但是受限于品牌兼容性與信息訪問權(quán)限;數(shù)據(jù)中心硬件監(jiān)控工具依賴簡單網(wǎng)絡(luò)管理協(xié)議(Simple Network Management Protocol,SNMP)與云平臺接口,常因預(yù)警閾值設(shè)定不當(dāng)引發(fā)誤報(bào);應(yīng)用系統(tǒng)運(yùn)維工具分為侵入式與非侵入式2類,前者通過代碼級嵌入實(shí)現(xiàn)精細(xì)監(jiān)控,但可能引入額外不穩(wěn)定因素,后者雖然不影響目標(biāo)系統(tǒng),但在實(shí)時性和故障深度分析方面存在局限。這些工具各自聚焦于特定技術(shù)領(lǐng)域,雖然能夠提供局部信息,但難以形成全局視圖,增加了運(yùn)維人員整合信息、綜合判斷的負(fù)擔(dān)。此外,高等院校還存在運(yùn)維工作細(xì)分化、部門間協(xié)作不足、過度依賴個體經(jīng)驗(yàn)、缺乏有效的知識傳承與管理工具等問題。
針對上述挑戰(zhàn),本文提出并開發(fā)了一種基于知識圖譜的數(shù)字化校園運(yùn)維系統(tǒng)。該系統(tǒng)創(chuàng)新性地將日常運(yùn)維知識與故障排除經(jīng)驗(yàn)圖譜化,結(jié)合自動化數(shù)據(jù)采集技術(shù),在故障發(fā)生時全面捕獲各系統(tǒng)狀態(tài),利用知識圖譜推理分析,分析故障的根本原因,為管理人員提供高效、準(zhǔn)確的故障定位指導(dǎo)。
1 需求分析
設(shè)計(jì)與開發(fā)一個基于知識圖譜的數(shù)字化校園運(yùn)維系統(tǒng),須要能夠自動發(fā)現(xiàn)各應(yīng)用之間的錯綜復(fù)雜的關(guān)聯(lián)性,運(yùn)用知識圖譜技術(shù)整合歷史故障案例、診斷環(huán)節(jié)及因果邏輯,實(shí)現(xiàn)信息的標(biāo)準(zhǔn)化表述;能夠依托預(yù)設(shè)規(guī)則,主動監(jiān)測核心系統(tǒng)運(yùn)行狀態(tài),及時預(yù)警潛在故障;還應(yīng)具備采集周圍環(huán)境數(shù)據(jù)的能力,借此與系統(tǒng)內(nèi)的豐富知識資源進(jìn)行對比分析,通過推理判斷故障根源,用直觀的可視化圖形進(jìn)行展示,為管理人員提供直觀的結(jié)果參考。
2 系統(tǒng)設(shè)計(jì)
本文設(shè)計(jì)了一個基于Web訪問的數(shù)字化校園運(yùn)維系統(tǒng),包含應(yīng)用拓?fù)涮綔y模塊、故障信息采集模塊、知識圖譜管理模塊、故障推理模塊以及可視化模塊。系統(tǒng)架構(gòu)如圖1所示。
2.1 應(yīng)用拓?fù)涮綔y模塊
構(gòu)建一個描繪系統(tǒng)間動態(tài)交互關(guān)系的信息交互圖對理解并理清軟件系統(tǒng)之間錯綜復(fù)雜關(guān)聯(lián)顯得尤為重要。應(yīng)用拓?fù)涮綔y模塊采用了流量監(jiān)測技術(shù),在交換機(jī)上實(shí)施流量鏡像策略。這一策略能夠直接從網(wǎng)絡(luò)傳輸層面捕獲并分析不同應(yīng)用系統(tǒng)間的數(shù)據(jù)交互情況,進(jìn)而繪制出應(yīng)用系統(tǒng)交互拓?fù)鋱D。
2.2 故障信息采集模塊
故障信息采集模塊融合了主動與被動2種信息采集策略。在被動采集方面,通過預(yù)置的規(guī)則篩選業(yè)務(wù)系統(tǒng)主要的用戶請求報(bào)文和應(yīng)答報(bào)文。主動采集策略則通過部署多維度的探針,向指定目標(biāo)系統(tǒng)發(fā)送特制的、帶標(biāo)識的網(wǎng)絡(luò)數(shù)據(jù)包或模擬真實(shí)場景的請求。隨后,系統(tǒng)詳盡記錄下這些測試包在各個監(jiān)測節(jié)點(diǎn)的通過情況,以此來進(jìn)一步驗(yàn)證系統(tǒng)的連通性和響應(yīng)能力。
2.3 故障知識圖譜管理模塊
知識圖譜能夠?qū)㈠e綜復(fù)雜的數(shù)據(jù)經(jīng)過加工、處理,轉(zhuǎn)化成直觀的“實(shí)體-關(guān)系-實(shí)體”三元組模型,促進(jìn)了知識的高效聚合與利用[3]。通過知識圖譜,系統(tǒng)能夠進(jìn)行故障推理,加速問題的解決。
知識圖譜管理模塊不僅允許手動微調(diào)應(yīng)用系統(tǒng)間的交互網(wǎng)絡(luò)圖,確保了拓?fù)浣Y(jié)構(gòu)的準(zhǔn)確性,還能夠與數(shù)據(jù)中心網(wǎng)絡(luò)拓?fù)溥M(jìn)行關(guān)聯(lián),形成完整的包含網(wǎng)絡(luò)設(shè)備、安全設(shè)備等的拓?fù)浣Y(jié)構(gòu),進(jìn)行故障信息生命周期的管理。
2.4 故障推理模塊
故障推理模塊能夠?qū)⑿率占膶?shí)時數(shù)據(jù)與知識圖譜中知識進(jìn)行對比分析,通過這一過程診斷故障的原始觸發(fā)點(diǎn)。在知識對比中,本系統(tǒng)采用余弦相似度算法,如式(1)所示,其中向量A代表知識圖譜內(nèi)的知識,向量B對應(yīng)于當(dāng)前查詢的故障情形。系統(tǒng)能夠按相似度從高至低的順序向用戶遞進(jìn)式推薦最有可能的故障原因。
similarity(A,B)=AB‖A‖‖B‖=∑ni=1AiBi∑ni=1A2i×∑ni=1B2i(1)
故障推理過程如圖2所示。由圖可知,在知識圖譜中存在1條典型故障記錄A(知識1),涉及5個系統(tǒng)(S1—S5),當(dāng)遭遇故障情形Qx時,系統(tǒng)搜集到Qx的上下文關(guān)聯(lián)系統(tǒng)信息為B(Qx,S2—S5)。通過計(jì)算記錄B與故障記錄A之間的余弦相似度,系統(tǒng)能夠量化兩者間的匹配程度,進(jìn)而推導(dǎo)引發(fā)Qx故障的原因可能是S5節(jié)點(diǎn)故障。
2.5 可視化模塊
簡潔明了的可視化展示對于用戶迅速掌握故障結(jié)論、明確問題根本原因至關(guān)重要。根據(jù)應(yīng)用交互拓?fù)鋱D、故障數(shù)據(jù)以及故障推理結(jié)果,借助高度圖形化的界面,清晰呈現(xiàn)信息流動路徑、正常響應(yīng)與異常節(jié)點(diǎn),并突出顯示通過推理判定的故障起源。
3 系統(tǒng)實(shí)現(xiàn)
本系統(tǒng)采用前后端分離技術(shù)棧實(shí)現(xiàn),前端使用Vue[4]框架,后端采用Python語言實(shí)現(xiàn),選擇開源的Suricata[5]作為流量分析引擎,采用Neo4j[6]作為知識圖譜分析、存儲數(shù)據(jù)庫,采用Selenium[7]自動化測試工具搭配PhantomJS[8]無頭瀏覽器,實(shí)現(xiàn)了用戶行為的模擬與自動化測試,基于VMware虛擬化平臺進(jìn)行流量鏡像分析,系統(tǒng)部署運(yùn)行于Ubuntu操作系統(tǒng)之上。
3.1 Suricata網(wǎng)絡(luò)監(jiān)控引擎
Suricata是一個高性能的網(wǎng)絡(luò)安全監(jiān)控引擎,本系統(tǒng)將Suricata部署在各個網(wǎng)絡(luò)監(jiān)測點(diǎn)上,不僅能夠搜集并分析不同節(jié)點(diǎn)的進(jìn)出流量,還具備動態(tài)調(diào)整分析策略的能力,根據(jù)不同故障情景使用相應(yīng)的分析規(guī)則。
為了精準(zhǔn)描繪不同應(yīng)用或服務(wù)器間的交互情況,本文對傳輸控制協(xié)議(Transmission Control Protocol,TCP)3次握手過程中ACK確認(rèn)包進(jìn)行捕獲,以此為基礎(chǔ)構(gòu)建了應(yīng)用間請求交互的模型,結(jié)合Suricata引擎,本系統(tǒng)編寫如下的規(guī)則,能夠有效地捕獲并記錄應(yīng)用間的通信交互事件:
alert tcp any any -gt;any any (msg: \"Established Connection Detected\";ack:1;tcp.flags:S; sid:100000;)
為了檢測應(yīng)用A(192.168.0.2)能否正常訪問應(yīng)用B(192.168.0.3:80)所提供的HTTP服務(wù)接口,設(shè)計(jì)如下規(guī)則:
alert http 192.168.0.2 any -gt;192.168.0.3 80 (msg: \"HTTP Response Success\"; content: \"200\"; http.stat_code; sid:100001;)
為了檢測應(yīng)用A(192.168.0.2)能否正常訪問B(192.168.0.3)所提供的數(shù)據(jù)庫服務(wù),設(shè)計(jì)如下規(guī)則:
alert tcp any any -gt; 192.168.0.3[1433,3306,1521] (msg:\"SQL Observed\"; flow: to_server, established; content:\"SELECTINSERTUPDATEDELETE\"; nocase; sid:1000002;)
3.2 Neo4j圖數(shù)據(jù)庫
Neo4j是一個高性能的非關(guān)系型(NoSQL)數(shù)據(jù)庫,也可以被看作是一個高性能的圖引擎,該引擎具有成熟數(shù)據(jù)庫的所有特性。
為了查詢與應(yīng)用A(192.168.0.2)直接或間接相連的所有其他應(yīng)用及其服務(wù)鏈路,限定服務(wù)鏈的最大深度不超過5層,本系統(tǒng)利用Cypher查詢語言執(zhí)行以下查詢指令:
match path=(start:App{ip:’192.168.0.2’})-[*1..5]-gt;(end:App) return path
3.3 基于分布式虛擬交換機(jī)的流量鏡像
通過端口鏡像,本文可將分布式端口流量鏡像到其他分布式端口或特定物理交換機(jī)端口。端口鏡像不僅助力于日常的數(shù)據(jù)流通分析,還在識別并解決網(wǎng)絡(luò)層面的潛在問題上發(fā)揮不可或缺的作用。
3.4 Selenium以及PhantomJS自動化測試工具
Selenium是最受歡迎的開源Web應(yīng)用程序自動化測試工具之一。通過Selenium,開發(fā)者可以編寫自動化測試腳本,用于自動執(zhí)行各種任務(wù)。與此搭配的PhantomJS是一個基于WebKit的無界面瀏覽器,可以解析和執(zhí)行網(wǎng)頁中的JavaScript代碼,支持各種Web標(biāo)準(zhǔn)。
3.5 圖形可視化組件relation-graph
relation-graph是一款基于Vue.js框架的高效關(guān)系圖組件,通過綁定數(shù)據(jù)來動態(tài)生成關(guān)系圖,極大地簡化了開發(fā)過程。這個關(guān)系圖譜組件可以非常方便地展示應(yīng)用交互拓?fù)?、故障知識圖譜等知識。
4 系統(tǒng)測試
本文選取南京理工大學(xué)的數(shù)據(jù)中心作為實(shí)踐案例,該中心的核心應(yīng)用系統(tǒng)均已遷移至虛擬化環(huán)境。在此基礎(chǔ)上,本文利用虛擬化平臺上的分布式交換機(jī)實(shí)施端口鏡像策略,捕獲了校園內(nèi)部各應(yīng)用系統(tǒng)間錯綜復(fù)雜的交互信息流。為了進(jìn)一步完善數(shù)據(jù)采集的全面性,研究團(tuán)隊(duì)在SDN交換機(jī)上增設(shè)了流量鏡像機(jī)制,專門針對網(wǎng)絡(luò)安全設(shè)備(例如Web應(yīng)用防火墻)的出入流量及關(guān)鍵網(wǎng)絡(luò)組件(例如Web反向代理服務(wù)器)進(jìn)行監(jiān)控與分析。
通過上述部署測試,系統(tǒng)能夠準(zhǔn)確辨識并分類諸如網(wǎng)絡(luò)安全設(shè)備失效、反向代理服務(wù)中斷及數(shù)據(jù)庫系統(tǒng)異常等多種常見運(yùn)維問題,有效增強(qiáng)了管理人員的運(yùn)維能力,提升了信息化服務(wù)水平。
5 結(jié)語
構(gòu)建一個健全的高校數(shù)字化校園運(yùn)維體系,是深化教育信息化進(jìn)程、增強(qiáng)師生數(shù)字體驗(yàn)的關(guān)鍵所在。其中,先進(jìn)的數(shù)字化運(yùn)維工具發(fā)揮至關(guān)重要的作用。本文構(gòu)建了一個基于知識圖譜的數(shù)字化校園運(yùn)維系統(tǒng),集故障知識圖譜、應(yīng)用交互拓?fù)渥詣犹綔y、故障信息采集以及故障推理于一體,將復(fù)雜的故障信息一目了然地呈現(xiàn),極大地提升了故障診斷與處理的效率。該系統(tǒng)不僅實(shí)現(xiàn)了技術(shù)資源的高效整合,還打破了部門壁壘,促進(jìn)了跨領(lǐng)域合作。
參考文獻(xiàn)
[1]陳榮.2024高校如何走好教育數(shù)字化新賽道?[J].中國教育網(wǎng)絡(luò),2024(1):15-18.
[2]鄭友偉,朱曉東,劉磊,等.一種面向SDN的傳統(tǒng)網(wǎng)絡(luò)功能集成方法設(shè)計(jì)與實(shí)現(xiàn)[J].電子設(shè)計(jì)工程,2024(8):23-26,31.
[3]李艷茹,周子力,倪???,等.基于知識圖譜的學(xué)科知識構(gòu)建[J].計(jì)算機(jī)時代,2021(4):65-68.
[4]王淑娥.基于Vue和HTML5的響應(yīng)式Web設(shè)計(jì)在信息技術(shù)領(lǐng)域的應(yīng)用[J].信息記錄材料,2024(5):121-123.
[5]汪志航.基于Suricata的網(wǎng)絡(luò)安全分析檢測系統(tǒng)設(shè)計(jì)[J].信息與電腦(理論版),2023(14):136-138.
[6]史政一,呂君可,黃弘.基于Neo4j的城市地下管道信息知識圖譜構(gòu)建研究[J].中國安全生產(chǎn)科學(xué)技術(shù),2024(6):5-10.
[7]馬立鑫,劉海燕,張兵權(quán).基于Selenium和Pytest的Web自動化測試框架應(yīng)用[J].電腦知識與技術(shù),2023(34):52-54.
[8]李佳欣,潘偉.PhantomJS在Web自動化測試中的應(yīng)用[J].計(jì)算機(jī)光盤軟件與應(yīng)用,2013(18):76-77,80.
(編輯 王永超編輯)
Design of digital campus operation and maintenance system based on knowledge graph
WU" Jiashun
(Division of Informationization Construction and Management,Nanjing University of Science and Technology,
Nanjing 210094, China)
Abstract: The operation and maintenance situation of digital campus in universities face challenges of insufficient inter-departmental collaboration and fragmented monitoring and control system, leading to difficulty in sharing operation and maintenance experience and knowledge across departments. Each independent monitoring and control system only provides isolated static monitoring data, lacking effective integration and in-depth analysis, thereby impacting the efficiency and accuracy of fault diagnosis. To address these, a digital campus operation and maintenance system based on knowledge graph is proposed. This system aggregates past fault handling cases, explores and constructs intrinsic relationships between faults, and forms a fault knowledge graph. Meanwhile, the system utilizes traffic analysis and automated testing techniques to automatically collect the interactive topology structure of application systems and feedback situations on faults from different nodes. The test results show that the system can correctly infer the common faults caused by the network security equipment, reverse proxy and database problem.
Key words: digital campus operation and maintenance; knowledge graph; traffic analysis; fault inference