本發(fā)明涉及網(wǎng)絡(luò)管理(以下簡稱為網(wǎng)管)系統(tǒng)技術(shù)。
背景技術(shù):
網(wǎng)管系統(tǒng)包含多個業(yè)務(wù)領(lǐng)域,告警在網(wǎng)管中的地位也是舉足輕重,只有通過告警才能幫助維護人員對網(wǎng)絡(luò)設(shè)備的問題進行快速定位和維護,否則只有等待用戶的抱怨和投訴。
從告警消息的接收到網(wǎng)管告警呈現(xiàn),是一個非常復(fù)雜的流程,因為設(shè)備側(cè)只會將人無法識別的告警內(nèi)容進行發(fā)送,網(wǎng)管側(cè)需要去識別這些由數(shù)字和字母組成的字符串到底代表了什么告警內(nèi)容,最終呈現(xiàn)給工作人員。
現(xiàn)有技術(shù)中,程序開發(fā)者需要對每種告警消息都要寫一套處理流程進行處理,對開發(fā)者而言,這是一個痛苦的過程。
從設(shè)備發(fā)送告警消息到網(wǎng)管側(cè)呈現(xiàn),需要解決mib節(jié)點識別、mib節(jié)點攜帶值內(nèi)容分析、基于解析內(nèi)容編寫能夠友好識別的內(nèi)容、流量控制、快速呈現(xiàn)等,整個流程缺一不可,任何過程的中斷都會導(dǎo)致告警上報失敗,所以基于每條告警需要人工編寫流程會導(dǎo)致開發(fā)成本非常高,維護非常艱難,問題非常多。
生產(chǎn)環(huán)境如果遇到告警在解析過程中出現(xiàn)問題,需要獲取告警解析失敗原因,然后讓開發(fā)人員重新編譯,打包,測試后,再次部署到生產(chǎn)環(huán)境,這是一個非常艱難的過程。
整體來說,告警解析流程是一套復(fù)雜的流程,需要一套新的框架來處理,能夠降低開發(fā)成本、提高開發(fā)效率,減少開發(fā)問題數(shù)量,提高告警解析穩(wěn)定性。
技術(shù)實現(xiàn)要素:
本發(fā)明所要解決的技術(shù)問題是:針對上述存在的問題,提供一種基于XML技術(shù)的MIB告警解析方法。
本發(fā)明提供的基于XML技術(shù)的MIB告警解析方法,其特征在于,包括:
步驟1:接收網(wǎng)絡(luò)設(shè)備發(fā)出的告警消息,通過解析協(xié)議將消息解析為協(xié)議對象;建立標準對象模型,根據(jù)告警消息的協(xié)議對象的字段內(nèi)容完善標準對象模型得到該告警消息的標準對象,并為該標準對象分配唯一的標識號;標準對象至少包含協(xié)議對象中的部分字段;標準對象中至少包含網(wǎng)絡(luò)設(shè)備所屬廠商、設(shè)備標識及告警節(jié)點這些字段;
步驟2:查找標準對象中是否包含預(yù)設(shè)的字段,如果沒有則認為該標準對象對應(yīng)的告警消息為無效告警,便不再處理該告警消息;否則進行步驟3;
步驟3:根據(jù)標準對象中的告警節(jié)點字段內(nèi)容確定該告警消息的網(wǎng)管側(cè)告警類型,并將標準對象的唯一標識號與網(wǎng)管側(cè)告警類型對應(yīng)起來;
步驟4:根據(jù)標準對象中的設(shè)備標識字段內(nèi)容在資產(chǎn)模塊中查詢并得到該告警消息對應(yīng)設(shè)備的設(shè)備類型,再從標準對象中獲取該告警消息的告警參數(shù),并填寫已經(jīng)配置好的網(wǎng)管側(cè)告警內(nèi)容框架中得到一條網(wǎng)管側(cè)告警;
其中資產(chǎn)模塊記載了網(wǎng)絡(luò)設(shè)備的設(shè)備標識與設(shè)備類型的對應(yīng)關(guān)系;網(wǎng)管側(cè)告警內(nèi)容框架包含網(wǎng)絡(luò)設(shè)備所屬廠商、設(shè)備類型、設(shè)備標識、告警類型、告警參數(shù)以及告警內(nèi)容描述這些字段。
進一步,步驟1中根據(jù)告警接收XML配置文件中配置了標準對象模型包含的字段。
進一步,步驟2中所述預(yù)設(shè)的字段配置于告警過濾XML配置文件中。
進一步,告警適配XML配置文件配置了網(wǎng)管側(cè)告警類型的名稱、網(wǎng)管側(cè)告警類型的編碼以及步驟3中標準對象的唯一標識號與網(wǎng)管側(cè)告警類型的名稱、編碼的對應(yīng)方式。
進一步,步驟4中的網(wǎng)管側(cè)告警內(nèi)容框架由告警識別XML配置文件配置。
本發(fā)明還提供了一種基于XML技術(shù)的MIB告警解析系統(tǒng),包括告警解析框架、告警接收XML配置文件、告警過濾XML配置文件、告警適配XML配置文件以及告警識別XML配置文件。
告警解析框架進一步包括:
告警接收模塊,用于接收網(wǎng)絡(luò)設(shè)備發(fā)出的告警消息,通過解析協(xié)議將消息解析為協(xié)議對象;建立標準對象模型,根據(jù)告警消息的協(xié)議對象的字段內(nèi)容完善標準對象模型得到該告警消息的標準對象,并為該標準對象分配唯一的標識號;標準對象至少包含協(xié)議對象中的部分字段;標準對象中至少包含網(wǎng)絡(luò)設(shè)備所屬廠商、設(shè)備標識及告警節(jié)點這些字段。
告警濾除模塊,用于查找標準對象中是否包含預(yù)設(shè)的字段,如果沒有則認為該標準對象對應(yīng)的告警消息為無效告警,便不再處理該告警消息。
告警適配模塊,用于處理非無效告警:根據(jù)標準對象中的告警節(jié)點字段內(nèi)容確定該告警消息的網(wǎng)管側(cè)告警類型,并將標準對象的唯一標識號與網(wǎng)管側(cè)告警類型對應(yīng)起來。
告警識別模塊,用于根據(jù)標準對象中的設(shè)備標識字段內(nèi)容在資產(chǎn)模塊中查詢并得到該告警消息對應(yīng)設(shè)備的設(shè)備類型,再從標準對象中獲取該告警消息的告警參數(shù),并填寫已經(jīng)配置好的網(wǎng)管側(cè)告警內(nèi)容框架中得到一條網(wǎng)管側(cè)告警;
其中資產(chǎn)模塊記載了網(wǎng)絡(luò)設(shè)備的設(shè)備標識與設(shè)備類型的對應(yīng)關(guān)系;網(wǎng)管側(cè)告警內(nèi)容框架包含網(wǎng)絡(luò)設(shè)備所屬廠商、設(shè)備類型、設(shè)備標識、告警類型、告警參數(shù)以及告警內(nèi)容描述這些字段。
告警接收XML配置文件描述了標準對象模型包含的字段;
告警過濾XML配置文件描述了所述預(yù)設(shè)的字段;
告警適配XML配置文件描述了網(wǎng)管側(cè)告警類型的名稱、網(wǎng)管側(cè)告警類型的編碼以及標準對象的唯一標識號與網(wǎng)管側(cè)告警類型的名稱、編碼的對應(yīng)方式。
告警識別XML配置文件描述了網(wǎng)管側(cè)告警內(nèi)容框架。
進一步,所述告警解析框架還包括異常處理模塊,異常處理模塊用于在解析過程中遇到異常情況后將所述異常情況記錄到異常日志中,并將異常日志提供給應(yīng)用層供管理人員查看。
進一步,所述告警解析框架還包括解析性能控制模塊,解析性能控制模塊用于使用JAXB技術(shù)提高解析XML配置文件的性能。
進一步,所述告警解析框架還包括流量控制模塊,流量控制模塊用于使用隊列緩沖和多線程技術(shù)對多條告警消息進行并行處理。
進一步,所述告警解析框架還包括未知告警處理模塊,未知告警處理模塊用于在接收到?jīng)]有配置信息的告警消息或者網(wǎng)管側(cè)沒有記錄的該告警消息設(shè)備時將此類告警消息存入未知告警庫中。
綜上所述,由于采用了上述技術(shù)方案,本發(fā)明的有益效果是:
本發(fā)明開發(fā)了告警解析框架,實現(xiàn)了從設(shè)備告警消息接收到網(wǎng)關(guān)側(cè)呈現(xiàn)的全過程,采用XML文件的形式對告警接收、告警過濾、告警適配及告警識別過程中的解析規(guī)則、參數(shù)映射關(guān)系等進行配置,使得告警解析過程更加通用,不必為每條消息分別編寫處理流程,當有新的設(shè)備進入網(wǎng)絡(luò)時,開發(fā)人員只需要對XML配置文件進行修改與配置即可,無需改寫框架處理流程,降低了程序開發(fā)復(fù)雜性及成本,提高了程序開發(fā)效率。
附圖說明
本發(fā)明將通過例子并參照附圖的方式說明,其中:
圖1是本發(fā)明告警解析框架圖。
圖2為SNMPV1告警格式。
圖3為SNMPV2告警格式。
具體實施方式
本說明書中公開的所有特征,或公開的所有方法或過程中的步驟,除了互相排斥的特征和/或步驟以外,均可以以任何方式組合。
本說明書中公開的任一特征,除非特別敘述,均可被其他等效或具有類似目的的替代特征加以替換。即,除非特別敘述,每個特征只是一系列等效或類似特征中的一個例子而已。
本發(fā)明提供的基于XML技術(shù)的MIB告警解析軟件系統(tǒng),包括告警解析框架、告警接收XML配置文件、告警過濾XML配置文件、告警適配XML配置文件以及告警識別XML配置文件。
參見圖1,本實施例中告警解析框架又包括告警接收模塊、告警濾除模塊、告警適配模塊及告警識別模塊,其中:
告警接收模塊,用于接收網(wǎng)絡(luò)設(shè)備發(fā)出的告警消息,通過SNMP協(xié)議將告警消息解析為SNMP協(xié)議相關(guān)的對象。不同的網(wǎng)絡(luò)設(shè)備解析得到的SNMP協(xié)議對象采用的報文格式可能不同,即解析后得到的對象可能是SNMPV1的告警格式或者SNMPV2告警格式,圖2展示了SNMPV1告警格式,圖3展示了SNMPV2告警格式。
為了便于處理,需要對這兩種SNMP協(xié)議對象進行統(tǒng)一,因此需要建立標準對象模型,我們將標準對象模型在告警接收XML配置文件中進行描述,標準對象模型至少應(yīng)包含協(xié)議對象中的部分字段。本實施例中的標準對象中至少包含網(wǎng)絡(luò)設(shè)備所屬廠商、設(shè)備標識(如設(shè)備IP地址、MAC地址等)及告警節(jié)點這些字段。對于有些設(shè)備,經(jīng)過解析后得到的告警節(jié)點內(nèi)容直接描述了告警內(nèi)容,如高溫告警等,而有些設(shè)備的告警消息經(jīng)過解析后得到的告警節(jié)點(即MIB節(jié)點)還需要進一步使用該設(shè)備廠商規(guī)定的規(guī)則,如告警節(jié)點內(nèi)容為整型或者將二進制,則需要根據(jù)廠商MIB節(jié)點提供的規(guī)則進行解析,進一步解析才能獲知網(wǎng)管側(cè)需要的告警內(nèi)容,如文本信息。
告警接收模塊根據(jù)解析告警消息得到的對象的字段內(nèi)容完善標準對象模型中的字段內(nèi)容得到該告警消息的標準對象,并為該標準對象分配唯一的標識號UEI。
告警濾除模塊,用于查找標準對象中是否包含預(yù)設(shè)的字段,如果沒有則認為該標準對象對應(yīng)的告警消息為無效告警,便不再處理該告警消息。告警濾除XML配置文件描述了所述預(yù)設(shè)的字段,本實施例中的預(yù)設(shè)字段包含“企業(yè)(廠商)名稱”。我們認為不含有“企業(yè)名稱”這一字段的標準對象并不是一個有效的告警消息解析。通過修改告警過濾XML配置文件可以動態(tài)增加或者排除某些告警信息。
告警適配模塊,用于處理有效告警:根據(jù)標準對象中的告警節(jié)點字段內(nèi)容確定該告警消息的網(wǎng)管側(cè)告警類型,并將標準對象的唯一標識號與網(wǎng)管側(cè)告警類型對應(yīng)起來。告警適配XML配置文件描述了網(wǎng)管側(cè)告警類型的名稱、網(wǎng)管側(cè)告警類型的編碼以及標準對象的唯一標識號與網(wǎng)管側(cè)告警類型的名稱、編碼的對應(yīng)方式。本實施例中標準對象的唯一標識號UEI對應(yīng)一個網(wǎng)管側(cè)告警類型名稱及一個編碼。網(wǎng)管側(cè)告警類型是為了網(wǎng)管側(cè)呈現(xiàn),便于管理人員理解。告警適配XML配置文件主要是要解決不同廠商的設(shè)備對于網(wǎng)管側(cè)同一條告警有著不同的MIB節(jié)點以及此MIB節(jié)點攜帶的告警內(nèi)容信息不同,需要通過適配做歸一化處理。網(wǎng)管側(cè)告警已經(jīng)定義了許多標準告警類型(本實施例中的類型包括Event\Recover\Fault三種),不同廠商的告警可以通過上面提到的UEI標識去識別同一條告警,這樣網(wǎng)管側(cè)無需感知不同廠商設(shè)備造成的告警不一樣的問題,并能快速接入新設(shè)備的告警。
告警識別模塊,用于根據(jù)標準對象中的設(shè)備標識字段內(nèi)容在資產(chǎn)模塊中查詢并得到該告警消息對應(yīng)設(shè)備的設(shè)備類型,再從標準對象中獲取該告警消息的告警參數(shù),并填寫已經(jīng)配置好的網(wǎng)管側(cè)告警內(nèi)容框架中得到一條網(wǎng)管側(cè)告警。
其中資產(chǎn)模塊記載了網(wǎng)絡(luò)設(shè)備的設(shè)備標識(如IP地址、MAC地址)與設(shè)備類型(CPE設(shè)備、ONU設(shè)備、交換機、光機等)的對應(yīng)關(guān)系。網(wǎng)管側(cè)告警內(nèi)容框架包含網(wǎng)絡(luò)設(shè)備所屬廠商、設(shè)備類型、設(shè)備標識、告警類型、告警參數(shù)(如高溫告警)以及告警內(nèi)容描述(如對于Recover告警類型會進一步描述該設(shè)備恢復(fù)的原因)這些字段。
告警識別XML配置文件描述了網(wǎng)管側(cè)告警內(nèi)容框架。
為了當告警解析框架運行出現(xiàn)異常時能讓開發(fā)人員盡快找到問題根源,告警解析框架還包括異常處理模塊,異常處理模塊用于在解析過程中遇到異常情況后將所述異常情況記錄到異常日志中,并將異常日志提供給應(yīng)用層供管理人員查看告警失敗的原因。
所述告警解析框架還包括解析性能控制模塊,本發(fā)明中所有的告警解析規(guī)則都使用了XML文件進行解析,對新接入告警是非常方便的,只需要簡單配置XML文件就可以讓網(wǎng)管側(cè)能夠收到告警,性能上面的話,從業(yè)界使用來看,XML解析的性能不是很高,它是一棵DOM樹,需要大量內(nèi)存來解析,但是可以基于JAXB技術(shù)進行動態(tài)映射到模型上面,這樣可以大大提高解析XML配置文件的性能。
所述告警解析框架還包括流量控制模塊,流量控制模塊用于使用隊列緩沖及多線程技術(shù)對多條告警消息進行并行處理。當大量設(shè)備發(fā)出告警消息時,告警解析框架必須進行流量控制,本實施例是使用隊列緩沖以及線程池技術(shù)快速將大量告警進行解析,隊列可以將告警消息緩存到網(wǎng)管側(cè)的虛擬機內(nèi)存中,使用線程池可以最大程度利用線程技術(shù)讓多條告警消息進行解析,若緩沖隊列滿了則可以考慮丟棄最老的告警去接收新告警。
所述告警解析框架還包括未知告警處理模塊,未知告警處理模塊用于在接收到?jīng)]有配置信息的告警消息或者網(wǎng)管側(cè)沒有記錄的該告警消息設(shè)備時將此類告警消息存入未知告警庫中。在配置新廠商的設(shè)備告警時,可能部分告警會出現(xiàn)沒有配置情況下,此時當這類告警上報后,無法在XML的告警配置文件中尋找的此類告警的配置信息,那么此告警會設(shè)置一個200001這樣的告警碼,這樣網(wǎng)管側(cè)就知道此告警為未解析的新告警,并讓其入庫,并在網(wǎng)管側(cè)的未知告警模塊呈現(xiàn);另外一種情況是設(shè)備側(cè)告警消息能夠解析,但是網(wǎng)管側(cè)無此告警的設(shè)備,例如資源模塊中沒有記錄該設(shè)備,這樣導(dǎo)致告警的設(shè)備類型等重要的資產(chǎn)信息無法獲取,進而導(dǎo)致無法獲得此告警對應(yīng)的網(wǎng)管側(cè)告警,我們也讓這類告警入庫,在網(wǎng)管側(cè)的未知告警中呈現(xiàn)。
下面結(jié)合實際運用進一步闡述本發(fā)明。
假設(shè)告警解析框架接收到了一個網(wǎng)絡(luò)設(shè)備的告警消息。
首先,通過SNMP協(xié)議將消息解析,得到SNMPV1報文(當然,也可能得到的是SNMPV2報文)。根據(jù)告警消息的報文的字段內(nèi)容完善標準對象模型得到該告警消息的標準對象,并為該標準對象分配唯一的UEI。
然后,查找標準對象中是否包含預(yù)設(shè)的字段“企業(yè)名稱”,如果沒有則認為該標準對象對應(yīng)的告警消息為無效告警,便不再處理該告警消息;否則進行后續(xù)處理。
根據(jù)標準對象中的告警節(jié)點字段內(nèi)容確定該告警消息的網(wǎng)管側(cè)告警類型,如Recover類型,并將標準對象的UEI與網(wǎng)管側(cè)告警類型對應(yīng)起來。
根據(jù)標準對象中的設(shè)備標識字段內(nèi)容,如MAC地址,在資產(chǎn)模塊中查詢并得到該告警消息對應(yīng)設(shè)備的設(shè)備類型為交換機,再從標準對象中獲取該告警消息的告警參數(shù)為高溫報警,并填寫已經(jīng)配置好的網(wǎng)管側(cè)告警內(nèi)容框架中得到一條網(wǎng)管側(cè)告警,即告警內(nèi)容為“MAC地址為00-25-64-T6-3D-40的XX廠商的交換機發(fā)出Recover告警,具體為溫度過高,告警描述為溫度過高出現(xiàn)告警,溫度恢復(fù)后告警取消”。至此,我們便從設(shè)備側(cè)的一條由字符組成的告警消息得到了一條便于識別的網(wǎng)管側(cè)告警。
本發(fā)明并不局限于前述的具體實施方式。本發(fā)明擴展到任何在本說明書中披露的新特征或任何新的組合,以及披露的任一新的方法或過程的步驟或任何新的組合。