本檔案介紹高可用性網路的基本概念和程式。它包括網路基線化和閾值化的關鍵成功因素,以幫助評估成功率。它還提供有關基線和閾值流程以及遵循思科高可用性服務(HAS)團隊確定的最佳實踐指南的實施的重要詳細資訊。
本文檔將逐步引導您完成基線化過程。某些當前的網路管理系統(NMS)產品可幫助實現此過程的自動化,但是,無論您使用自動工具還是手動工具,基線建立過程都保持不變。如果使用這些NMS產品,則必須調整唯一網路環境的預設閾值設定。必須有一個智慧地選擇這些閾值的流程,以便這些閾值是有意義和正確的。
基線是一個過程,用於定期研究網路以確保網路的工作情況符合設計意圖。它不只是一份報告詳述網路在特定時間點的運行狀況。通過遵循基線流程,您可以獲得以下資訊:
獲得有關硬體和軟體運行狀況的寶貴資訊
確定網路資源的當前利用率
對網路警報閾值做出準確決策
確定當前的網路問題
預測未來問題
下圖說明了檢視基線的另一種方式。
紅線,即網路中斷點,是網路中斷點,它取決於對硬體和軟體運行方式的瞭解。綠線,即網路負載,是隨著新應用的新增及其他此類因素在網路上的負載的自然增長。
基線的用途是確定:
您的網路處於綠色線上
網路負載增長有多快
希望預測兩者何時會交叉
通過定期執行基線,您可以找出當前狀態,並外推何時發生故障,然後提前為故障做好準備。這還有助於您更明智地決定何時、何地以及如何將預算資金用於網路升級。
基線流程可幫助您確定網路中的關鍵資源限制問題並對其進行正確規劃。這些問題可描述為控制平面資源或資料平面資源。控制平面資源對於裝置內的特定平台和模組來說是唯一的,並且可能受到許多問題的影響,包括:
資料利用率
啟用的功能
網路設計
控制平面資源包括以下引數:
CPU利用率
記憶體利用率
緩衝區利用率
資料平面資源僅受流量型別和數量的影響,包括鏈路利用率和背板利用率。通過為關鍵區域設定資源利用率基準,可以避免嚴重的效能問題,甚至避免網路崩潰。
隨著語音和影片等延遲敏感型應用的引入,基線處理現在比以往任何時候都更加重要。傳統的傳輸控制通訊協定/網際網路通訊協定(TCP/IP)應用程式是寬恕的,且允許一定的延遲量。語音和影片基於使用者資料包協定(UDP),不允許重新傳輸或網路擁塞。
由於應用的新組合,基線化可幫助您瞭解控制平面和資料平面資源利用率問題,並主動規劃更改和升級,以確保持續成功。
資料網路已存在多年。直到最近,保持網路運行一直是一個相當可原諒的過程,其中存在一些出錯的空間。隨著IP語音(VoIP)等延遲敏感型應用日益被接受,網路運行工作變得越來越困難,要求更高的準確性。為了更加精確,並為網路管理員提供管理網路的堅實基礎,必須瞭解網路的運行方式。為此,必須經歷一個稱為基線的過程。
基線的目標是:
確定網路裝置的當前狀態
將該狀態與標準效能准則進行比較
設定閾值,以便在狀態超過這些准則時發出警報
由於有大量資料以及分析資料所花費的時間,您必須首先限制基線的範圍,以便更輕鬆地瞭解該過程。最合乎邏輯、有時也是最有益的地方,是網路的核心。網路的此部分通常最小,且要求最穩定。
為簡單起見,本文說明如何將一個非常重要的簡單網路管理協定管理資訊庫(SNMP MIB)作為基準:cpmCPUTotal5min。cpmCPUTotal5min是思科路由器的中央處理器(CPU)的五分鐘衰減平均值,並且是控制平面效能指示器。基線將在Cisco 7000系列路由器上執行。
學習該過程後,可以將其應用於大多數Cisco裝置都可用的廣闊SNMP資料庫中的任何資料,例如:
整合服務數位網路(ISDN)使用情況
非同步傳輸模式(ATM)基地台遺失
可用系統記憶體
以下流程圖顯示了核心基線流程的基本步驟。雖然您可以利用產品和工具來執行其中的某些步驟,但它們在靈活性和易用性方面往往存在差距。即使您計畫使用網路管理系統(NMS)工具執行基線化,這仍是一個很好的練習,有助於您研究這一過程並瞭解網路實際的工作原理。此過程可能還會消除一些NMS工具工作方式中的某些神秘之處,因為大多數工具基本上都執行相同的事情。
編譯硬體、軟體和配置清單非常重要,原因有幾個。首先,在某些情況下,Cisco SNMP MIB特定於您正在運行的Cisco IOS版本。有些MIB對象被替換為新對象,或者有時被完全刪除。收集資料後進行硬體清點非常重要,因為在初始基線之後需要設定的閾值通常基於思科裝置上的CPU型別、記憶體量等。配置清單對於確保您瞭解當前配置也很重要:您可能希望在基線後更改裝置配置以調整緩衝區,等等。
對思科網路來說,這部分基線的最有效方法是使用CiscoWorks2000 Resource Manager Essentials(Essentials)。 如果在網路中正確安裝了此軟體,則Essentials資料庫中應包含所有裝置的當前清單。您只需檢視清單,看看是否存在任何問題。
下表是從Essentials匯出並在Microsoft Excel中編輯的Cisco Router Class軟體清單報告的示例。從該清單中,請注意,您必須使用12.0x和12.1x Cisco IOS版本中找到的SNMP MIB資料和對象識別符號(OID)。
裝置名稱 | 路由器型別 | 版本 | 軟體版本 |
---|---|---|---|
field-2500a.embu-mlab.cisco.com | Cisco 2511 | M | 12.1(1) |
qdm-7200.embu-mlab.cisco.com | Cisco 7204 | B | 12.1(1)E |
voip-3640.embu-mlab.cisco.com | Cisco 3640 | 0x00 | 12.0(3c) |
wan-1700a.embu-mlab.cisco.com | Cisco 1720 | 0x101 | 12.1(4) |
wan-2500a.embu-mlab.cisco.com | Cisco 2514 | L | 12.0(1) |
wan-3600a.embu-mlab.cisco.com | Cisco 3640 | 0x00 | 12.1(3) |
wan-7200a.embu-mlab.cisco.com | Cisco 7204 | B | 12.1(1)E |
172.16.71.80 | Cisco 7204 | B | 12.0(5T) |
如果網路中未安裝Essentials,則可以從UNIX工作站使用UNIX命令列工具snmpwalk來查詢IOS版本。如下例所示。如果您不確定此命令如何工作,請在UNIX提示符下鍵入man snmpwalk以獲取詳細資訊。當您開始選擇要基線的MIB OID時,IOS版本非常重要,因為MIB對象與IOS相關。另請注意,通過瞭解路由器型別,您以後可以決定應該為CPU、緩衝區等設定哪些閾值。
nsahpov6% snmpwalk -v1 -c private 172.16.71.80 system system.sysDescr.0 : DISPLAY STRING- (ascii): Cisco Internetwork Operating System Software IOS (tm) 7200 Software (C7200-JS-M), Version 12.0(5)T, RELEASE SOFTWARE (fc1) Copyright (c) 1986-2001 by cisco Systems, Inc. Compiled Fri 23-Jul-2001 23:02 by kpma system.sysObjectID.0 : OBJECT IDENTIFIER: .iso.org.dod.internet.private.enterprises.cisco.ciscoProducts.cisco7204
現在您已經擁有要輪詢基準的裝置清單,您可以開始選擇要輪詢的特定OID。如果您提前確認您想要的資料確實存在,這可以消除很多疑慮。cpmCPUTotal5min MIB對象位於CISCO-PROCESS-MIB中。
要查詢要輪詢的OID,需要思科CCO網站上提供的轉換表。若要從Web瀏覽器訪問此網站,請轉到Cisco MIBs頁面,然後按一下OIDs連結。
要從FTP伺服器訪問此網站,請鍵入ftp://ftp.cisco.com/pub/mibs/oid/。您可以從此站點下載已解碼並按OID編號排序的特定MIB。
以下示例是從CISCO-PROCESS-MIB.oid表中提取的。此範例顯示cpmCPUTotal5min MIB的OID為。1.3.6.1.4.1.9.9.109.1.1.1.5。
注意:不要忘記新增「」。 到OID的開頭,否則嘗試輪詢它時會出現錯誤。您還需要將「。1」新增到OID末尾以例項化它。這將告知裝置您要查詢的OID例項。在某些情況下,OID有多個特定型別的資料例項,例如路由器有多個CPU時。
ftp://ftp.cisco.com/pub/mibs/oid/CISCO-PROCESS-MIB.oid ### THIS FILE WAS GENERATED BY MIB2SCHEMA "org" "1.3" "dod" "1.3.6" "internet" "1.3.6.1" "directory" "1.3.6.1.1" "mgmt" "1.3.6.1.2" "experimental" "1.3.6.1.3" "private" "1.3.6.1.4" "enterprises" "1.3.6.1.4.1" "cisco" "1.3.6.1.4.1.9" "ciscoMgmt" "1.3.6.1.4.1.9.9" "ciscoProcessMIB" "1.3.6.1.4.1.9.9.109" "ciscoProcessMIBObjects" "1.3.6.1.4.1.9.9.109.1" "ciscoProcessMIBNotifications" "1.3.6.1.4.1.9.9.109.2" "ciscoProcessMIBConformance" "1.3.6.1.4.1.9.9.109.3" "cpmCPU" "1.3.6.1.4.1.9.9.109.1.1" "cpmProcess" "1.3.6.1.4.1.9.9.109.1.2" "cpmCPUTotalTable" "1.3.6.1.4.1.9.9.109.1.1.1" "cpmCPUTotalEntry" "1.3.6.1.4.1.9.9.109.1.1.1.1" "cpmCPUTotalIndex" "1.3.6.1.4.1.9.9.109.1.1.1.1.1" "cpmCPUTotalPhysicalIndex" "1.3.6.1.4.1.9.9.109.1.1.1.1.2" "cpmCPUTotal5sec" "1.3.6.1.4.1.9.9.109.1.1.1.1.3" "cpmCPUTotal1min" "1.3.6.1.4.1.9.9.109.1.1.1.1.4" "cpmCPUTotal5min" "1.3.6.1.4.1.9.9.109.1.1.1.1.5"
有兩種常用方法可以輪詢MIB OID,以確保其可用且正常運行。最好在開始批次資料收集之前完成此操作,以便不會浪費時間輪詢不在其中但結果為空資料庫的內容。一種方法是使用來自NMS平台(例如HP OpenView Network Node Manager(NNM)或CiscoWorks Windows)的MIB步行器,並輸入要檢查的OID。
以下是HP OpenView SNMP MIB walker的一個示例。
輪詢MIB OID的另一種簡單方法是使用UNIX命令snmpwalk,如以下示例所示。
nsahpov6% cd /opt/OV/bin nsahpov6% snmpwalk -v1 -c private 172.16.71.80 .1.3.6.1.4.1.9.9.109.1.1.1.1.5.1 cisco.ciscoMgmt.ciscoProcessMIB.ciscoProcessMIBObjects.cpmCPU.cpmCPUTotalTable.cpmCPUTotalEntry.cpmCPUTotal5min.1 : Gauge32: 0
在這兩個示例中,MIB都返回了一個值0,這意味著在該輪詢週期中,CPU的平均利用率是0%。如果難以讓裝置響應正確的資料,請嘗試ping裝置並通過Telnet訪問裝置。如果仍然存在問題,請檢查SNMP配置和SNMP社群字串。您可能需要找到備用MIB或其他IOS版本才能實現此功能。
有多種方法可以輪詢MIB對象並記錄輸出。現成產品、共用軟體產品、指令碼和供應商工具均可用。所有前端工具都使用SNMP get過程來獲取資訊。主要區別在於配置的靈活性以及在資料庫中記錄資料的方式。再次檢視處理器MIB以瞭解這些不同方法的運作方式。
既然您知道路由器中支援OID,則需要決定輪詢它的頻率以及如何記錄。Cisco建議每隔五分鐘輪詢CPU MIB。更低的間隔會增加網路或裝置上的負載,而且,由於MIB值無論如何都是5分鐘的平均值,因此輪詢它比平均值更頻繁是沒有用的。通常也建議基線輪詢至少有兩個星期,以便您可以分析網路上的至少兩個每週業務週期。
以下螢幕顯示如何使用HP OpenView Network Node Manager版本6.1新增MIB對象。在主螢幕中選擇選項>資料收集與閾值。
然後選擇「編輯」>「新增」>「MIB對象」。
在選單中,新增OID字串,然後按一下Apply。現在,您已經將MIB對象輸入到HP OpenView平台,以便對其進行輪詢。
接下來,您必須讓HP OpenView知道要輪詢此OID的路由器。
從「資料收集」選單中選擇「編輯」>「新增」>「MIB收集」。
在Source欄位中,輸入要輪詢路由器的網域命名系統(DNS)名稱或IP位址。
從設定收集模式清單中選擇儲存,無閾值。
將「輪詢間隔」設置為5m,每隔5分鐘。
按一下「Apply」。
您必須選擇檔案>儲存才能使更改生效。
要驗證集合是否設定正確,請突出顯示路由器的集合摘要行,然後選擇Actions > Test SNMP。這將檢查社群字串是否正確,並將輪詢所有OID例項。
按一下Close,讓集合運行一週。在每週週期結束時,提取資料進行分析。
如果將資料轉儲到ASCII檔案並將其匯入電子表格工具(如Microsoft Excel),則更容易分析資料。要使用HP OpenView NNM執行此操作,您可以使用命令列工具snmpColDump。配置的每個集合都寫入到/var/opt/OV/share/databases/snmpCollect/目錄中的檔案。
使用以下命令將資料提取到名為testfile的ASCII檔案中:
snmpColDump /var/opt/OV/share/databases/snmpCollect/cpmCPUTotal5min.1 > testfile
注意:cpmCPUTotal5min.1是HP OpenView NNM在OID輪詢開始時建立的資料庫檔案。
生成的測試檔案類似於以下示例。
03/01/2001 14:09:10 nsa-gw.cisco.com 1 03/01/2001 14:14:10 nsa-gw.cisco.com 1 03/01/2001 14:19:10 nsa-gw.cisco.com 1 03/01/2001 14:24:10 nsa-gw.cisco.com 1 03/01/2001 14:29:10 nsa-gw.cisco.com 1 03/01/2001 14:34:10 nsa-gw.cisco.com 1 03/01/2001 14:39:10 nsa-gw.cisco.com 1 03/01/2001 14:44:10 nsa-gw.cisco.com 1 03/01/2001 14:49:10 nsa-gw.cisco.com 1 03/01/2001 14:54:10 nsa-gw.cisco.com 1 03/01/2001 14:59:10 nsa-gw.cisco.com 1 03/………
在UNIX工作站上輸出測試檔案後,您可以使用檔案傳輸協定(FTP)將其傳輸到PC。
您還可以使用自己的指令碼收集資料。為此,請每五分鐘對CPU OID執行snmpget,並將結果轉儲到.csv檔案中。
現在你有了一些資料,你可以開始分析它。此基線階段確定您可以使用的準確效能或故障衡量指標閾值設定,並且在啟用閾值監視時不會觸發太多警報。最簡單的方法之一是將資料匯入電子表格(如Microsoft Excel)並繪製散點圖。通過此方法,您可以非常輕鬆地檢視特定裝置在監控某個特定閾值時建立異常警報的次數。不執行基線操作而開啟閾值是不可取的,因為這樣可能會從超過所選閾值的裝置建立警報風暴。
要將測試檔案匯入Excel電子表格,請開啟Excel並選擇「檔案」>「開啟」並選擇資料檔案。
然後,Excel應用程式會提示您匯入檔案。
完成後,匯入的檔案應類似於以下螢幕。
使用散點圖可以更輕鬆地直觀顯示各種閾值設定在網路上的工作方式。
要建立散點圖,請突出顯示匯入檔案中的C列,然後按一下「圖表嚮導」圖示。然後按照圖表嚮導中的步驟來構建散點圖。
在圖表嚮導第1步中,如下圖所示,選擇標準類型頁籤,然後選擇XY(散點圖)圖表型別。然後點選下一步。
在圖表嚮導第2步中,如下圖所示,選擇資料範圍頁籤,然後選擇資料範圍和列選項。按「Next」(下一步)。
在圖表嚮導第3步中,如下圖所示,輸入圖表標題以及X軸和Y軸值,然後按一下下一步。
在「圖表嚮導」第4步中,選擇是要將散點圖置於新頁面上還是作為現有頁面中的對象。
按一下完成將圖表放置在所需的位置。
「如果?」 分析
現在,您可以使用散點圖進行分析。但是,在繼續操作之前,您需要提出以下問題:
供應商(在本例中供應商為Cisco)建議將哪一項作為此MIB變數的閾值?
一般來說,思科建議核心路由器的CPU平均利用率不要超過60%。之所以選擇60%,是因為路由器在遇到問題或網路出現故障時需要一些開銷。思科估計核心路由器需要大約40%的CPU開銷,以防路由協定必須重新計算或重新收斂。這些百分比視您使用的協定以及網路的拓撲和穩定性而定。
如果使用60%作為閾值設定呢?
如果您在散點圖水準方向畫一條線(60),您會發現所有資料點都不會超過60%的CPU利用率。因此,在網路管理系統(NMS)站點上設定的閾值60不會在輪詢期間觸發閾值警報。此路由器可以接受百分比60。但是,請注意散點圖中的某些資料點接近60。最好知道路由器何時接近60%的閾值,這樣您就可以提前知道CPU接近60%,並且制定在達到該閾值時應該如何執行的計畫。
如果我把閾值設為50%會怎樣?
估計此路由器在此輪詢週期中四次達到50%的利用率,並且每次都會生成閾值警報。當您檢視路由器組時,檢視不同的閾值設定將執行什麼操作時,此過程就變得更為重要。例如,「如果我將整個核心網路的閾值設定為50%會怎樣?」 要知道,只選擇一個數字是非常困難的。
您可以用來簡化此操作的策略之一是「就緒」、「設定」、「開始」閾值方法。該方法連續使用三個閾值數。
就緒 — 您設定的閾值,作為未來可能需要注意的裝置的預測指標
Set — 用作早期指示符的閾值,用於提醒您開始計畫修復、重新配置或升級
Go — 您和/或供應商認為是故障情況的閾值,需要執行某些操作才能修復;在本例中為60%
下表顯示了「就緒」、「設定」、「開始」策略的策略。
閾值 | 動作 | 結果 |
---|---|---|
45% | 進一步調查 | 行動計畫選項清單 |
50% | 制定行動計畫 | 行動計畫步驟清單 |
60% | 實施行動計畫 | 路由器不再超過閾值。返回到就緒模式 |
「就緒」、「設定」、「開始」方法會更改前面討論的原始基線圖表。下圖顯示了更改後的基線圖表。如果可以識別圖表上的其他交點,那麼現在您比以前有更多的時間進行計畫和反應。
請注意,在此過程中,注意重點是網路中的異常,而不是其他裝置。我們假定,只要裝置低於閾值,它們就可以正常工作。
如果您從一開始就考慮這些步驟,您將做好維護網路正常運行的充分準備。執行此類計畫對預算計畫也非常有用。如果您知道您的前5個go路由器、中間set路由器以及底部ready路由器是什麼,您可以根據路由器的型別以及您的行動計畫選項輕鬆規劃升級所需的預算。相同的策略可用於廣域網(WAN)鏈路或任何其他MIB OID。
這是基線流程中較為簡單的部分之一。確定哪些裝置超過go閾值後,您應制定行動計畫,使這些裝置恢復到threshold以下。
您可以從思科技術支援中心(TAC)建立案例,或聯絡您的系統工程師取得可用選項。你不應該想當然地認為,讓事情回到正常水準需要花錢。通過更改配置以確保所有進程以最有效的方式運行,可以解決某些CPU問題。例如,由於封包經過路由器的路徑,某些存取控制清單(ACL)可能會使路由器CPU執行速度非常快。在某些情況下,可以實施NetFlow交換來更改資料包交換路徑並減少ACL對CPU的影響。無論存在什麼問題,都有必要在此步驟中將所有路由器恢復至閾值之下,以便您以後可以實施閾值,而不會在NMS工作站上泛洪過多閾值警報的風險。
此步驟涉及使用將在生產網路中使用的工具在實驗室中測試閾值。有兩種常用方法來監視閾值。您必須確定哪種方法最適合您的網路。
使用SNMP平台或其他SNMP監控工具進行輪詢和比較的方法
此方法使用更多的網路頻寬來輪詢流量,並佔用您的SNMP平台上的處理週期。
在路由器中使用遠端監控(RMON)警報和事件配置,以便只有在超過閾值時才會傳送警報
此方法減少了網路頻寬使用量,但也增加了路由器上的記憶體和CPU使用量。
要使用HP OpenView NNM設定SNMP方法,請選擇選項>資料收集與閾值(與設定初始輪詢時相同)。但這一次,請在收集選單中選擇「儲存」、「檢查閾值」而不是「儲存」、「無閾值」。設定閾值後,您可以透過傳送多個ping和/或多次SNMP躍點來提高路由器上的CPU使用率。如果不能強制CPU達到觸發閾值的高度,您可能必須降低閾值。在任何情況下,您都應確保閾值機制正常工作。
使用此方法的侷限性之一是不能同時實現多個閾值。您需要三個SNMP平台來設定三個不同的同時閾值。Concord Network Health 和Trinagy TREND (如Concord Network Health和Trinagy TREND)等工具可為同一OID例項允許多個閾值。
如果您的系統一次只能處理一個閾值,則可以考慮串列方式的「就緒」、「設定」、「開始」策略。即,在連續達到ready閾值時,開始進行調查,並將閾值提升到該裝置的設定級別。當持續達到設定級別時,開始制定您的行動計畫並將該裝置的閾值提升到Go級別。然後,當持續達到開始閾值時,實施您的行動計畫。這應該與三同時閾值法一樣有效。更改SNMP平台閾值設定只需要稍多花一點時間。
使用RMON警報和事件配置,可以使路由器監控自己的多個閾值。當路由器檢測到超出閾值條件時,會向SNMP平台傳送SNMP陷阱。您的路由器配置中必須設定SNMP陷阱接收器才能轉發陷阱。警報和事件之間存在關聯。警報會檢查給定閾值的OID。如果達到閾值,警報進程將觸發事件進程,該進程可以傳送SNMP陷阱消息、建立RMON日誌條目或同時傳送這兩者。有關此命令的更多詳細資訊,請參閱RMON警報和事件配置命令。
以下路由器配置命令使路由器每300秒監控一次cpmCPUTotal5min。如果CPU超過60%,它將觸發事件1;當CPU回落到40%時,將觸發事件2。在這兩種情況下,都會使用社群專用字串將SNMP陷阱消息傳送到NMS工作站。
要使用Ready、Set、Go方法,請使用以下所有配置語句。
rmon event 1 trap private description "cpu hit60%" owner jharp rmon event 2 trap private description "cpu recovered" owner jharp rmon alarm 10 cpmCPUTotalTable.1.5.1 300 absolute rising 60 1 falling 40 2 owner jharp rmon event 3 trap private description "cpu hit50%" owner jharp rmon event 4 trap private description "cpu recovered" owner jharp rmon alarm 20 cpmCPUTotalTable.1.5.1 300 absolute rising 50 3 falling 40 4 owner jharp rmon event 5 trap private description "cpu hit 45%" owner jharp rmon event 6 trap private description "cpu recovered" owner jharp rmon alarm 30 cpmCPUTotalTable.1.5.1 300 absolute rising 45 5 falling 40 6 owner jharp
以下示例顯示由上述語句配置的show rmon alarm命令的輸出。
zack#sh rmon alarm Alarm 10 is active, owned by jharp Monitors cpmCPUTotalTable.1.5.1 every 300 second(s) Taking absolute samples, last value was 0 Rising threshold is 60, assigned to event 1 Falling threshold is 40, assigned to event 2 On startup enable rising or falling alarm Alarm 20 is active, owned by jharp Monitors cpmCPUTotalTable.1.5.1 every 300 second(s) Taking absolute samples, last value was 0 Rising threshold is 50, assigned to event 3 Falling threshold is 40, assigned to event 4 On startup enable rising or falling alarm Alarm 30 is active, owned by jharp Monitors cpmCPUTotalTable.1.5.1 every 300 second(s) Taking absolute samples, last value was 0 Rising threshold is 45, assigned to event 5 Falling threshold is 40, assigned to event 6 On startup enable rising or falling alarm
以下示例顯示show rmon event命令的輸出。
zack#sh rmon event Event 1 is active, owned by jharp Description is cpu hit60% Event firing causes trap to community private, last fired 00:00:00 Event 2 is active, owned by jharp Description is cpu recovered Event firing causes trap to community private, last fired 02:40:29 Event 3 is active, owned by jharp Description is cpu hit50% Event firing causes trap to community private, last fired 00:00:00 Event 4 is active, owned by jharp Description is cpu recovered Event firing causes trap to community private, last fired 00:00:00 Event 5 is active, owned by jharp Description is cpu hit 45% Event firing causes trap to community private, last fired 00:00:00 Event 6 is active, owned by jharp Description is cpu recovered Event firing causes trap to community private, last fired 02:45:47
您可能需要嘗試這兩種方法,以瞭解哪種方法最適合您的環境。您甚至可能會發現方法結合使用效果很好。無論如何,測試應該在實驗室環境中進行,以確保一切正常。在實驗室中測試後,您只需在一小組路由器上進行有限的部署,即可測試向運營中心傳送警報的過程。
在這種情況下,您必須降低閾值來測試該進程:建議不要嘗試在生產路由器上人工提高CPU。您還應確保當警報進入運營中心的NMS工作站時,有一個上報策略,以確保在裝置超出閾值時通知您。這些配置已在使用Cisco IOS版本12.1(7)的實驗室中進行了測試。 如果您遇到任何問題,應諮詢思科工程人員或系統工程師,瞭解您的IOS版本中是否有錯誤。
在實驗室和有限部署中全面測試閾值監控後,您就可以跨核心網路實施閾值了。現在,您可以系統性地檢查此基線過程,瞭解網路上的其他重要MIB變數,例如緩衝區、可用記憶體、循環冗餘檢查(CRC)錯誤、AMT單元丟失等。
如果使用RMON警報和事件配置,則現在可以停止從NMS站進行輪詢。這將減少NMS伺服器上的負載並減少網路上的輪詢資料量。通過對重要網路運行狀況指示器系統地執行此過程,您可以輕鬆達到網路裝置使用RMON警報和事件監控自己的程度。
學習該過程後,可能需要調查其他MIB以作基線和監控。以下小節提供了一些可能會對您有幫助的OID和說明的簡短清單。
記憶體特性在確定路由器的運行狀況方面非常有用。正常的路由器幾乎總是應該有可用的緩衝區空間來工作。如果路由器開始耗盡緩衝區空間,CPU將不得不更加努力地建立新的緩衝區,並嘗試為傳入和傳出資料包查詢緩衝區。有關緩衝區的深入討論不在本檔案的範圍之內。但是,一般情況下,正常路由器的緩衝區丟失應該很少(如果有),並且不應出現任何緩衝區故障或記憶體為零的情況。
對象 | 說明 | OID |
---|---|---|
ciscoMemoryPoolFree | 受管裝置上當前未使用的記憶體池位元組數 | 1.3.6.1.4.1.9.9.48.1.1.1.6 |
ciscoMemoryPoolLargestFree | 記憶體池中當前未使用的最大連續位元組數 | 1.3.6.1.4.1.9.9.48.1.1.1.7 |
bufferElMiss | 緩衝區元素未命中數 | 1.3.6.1.4.1.9.2.1.12 |
bufferFail | 緩衝區分配失敗的次數 | 1.3.6.1.4.1.9.2.1.46 |
bufferNoMem | 由於無可用記憶體而導致的緩衝區建立失敗數 | 1.3.6.1.4.1.9.2.1.47 |
對象 | 說明 | OID |
---|---|---|
cpmCPUTotal5min | 過去五分鐘內的總體CPU忙碌百分比。此對象將avgBusy5對象從OLD-CISCO-SYSTEM-MIB中降級 | 1.3.6.1.4.1.9.9.109.1.1.1.5 |
cpmCPUTotal5sec | 過去五秒期間的整體CPU忙碌百分比。此對象從OLD-CISCO-SYSTEM-MIB中取代busyPer對象 | 1.3.6.1.4.1.9.9.109.1.1.1.3 |
系統流量 | 上一個輪詢間隔的頻寬利用率百分比 | 1.3.6.1.4.1.9.5.1.1.8 |
sysTrafficPeak | 自最後一次清除連線埠計數器或系統啟動以來的峰值流量計值 | 1.3.6.1.4.1.9.5.1.1.19 |
sysTrafficPeaktime | 自峰值流量計量器值出現以來的時間(以百分之一秒為單位) | 1.3.6.1.4.1.9.5.1.1.20 |
portTopNUilization | 系統中埠的利用率 | 1.3.6.1.4.1.9.5.1.20.2.1.4 |
portTopNBufferOverFlow | 系統中埠的緩衝區溢位數 | 1.3.6.1.4.1.9.5.1.20.2.1.10 |
對象 | 說明 | OID |
---|---|---|
locIfInputQueueDrops | 由於輸入隊列已滿而丟棄的資料包數 | 1.3.6.1.4.1.9.2.2.1.1.26 |
locIfOutputQueueDrops | 由於輸出隊列已滿而丟棄的資料包數 | 1.3.6.1.4.1.9.2.2.1.1.27 |
locIfInCRC | 具有循環冗餘校驗和錯誤的輸入資料包數 | 1.3.6.1.4.1.9.2.2.1.1.12 |
可以使用以下語法配置RMON警報:
rmon alarm number variable interval {delta | absolute} rising-threshold value [event-number] falling-threshold value [event-number] [owner string]
元素 | 說明 |
---|---|
number | 警報編號,與RMON MIB中alarmTable中的alarmIndex相同。 |
變數 | 要監控的MIB對象,轉換為RMON MIB的alarmTable中使用的alarmVariable。 |
間隔 | 警報監視MIB變數的時間(以秒為單位),該變數與RMON MIB的alarmTable中使用的alarmInterval相同。 |
增量 | 測試MIB變數之間的更改,這些變數影響RMON MIB的alarmTable中的alarmSampleType。 |
絕對 | 直接測試每個MIB變數,這會影響RMON MIB的alarmTable中的alarmSampleType。 |
上升閾值 | 觸發警報的值。 |
event-number | (可選)當上升或下降閾值超過其限制時要觸發的事件編號。此值與RMON MIB的alarmTable中的alarmRisingEventIndex或alarmFallingEventIndex相同。 |
下降閾值 | 警報重置時的值。 |
所有者字串 | (可選)指定警報的所有者,該所有者與RMON MIB的alarmTable中的alarmOwner相同。 |
可以使用以下語法配置RMON事件:
rmon event number [log] [trap community] [description string] [owner string]
元素 | 說明 |
---|---|
number | 分配的事件編號,與RMON MIB中eventTable中的eventIndex相同。 |
log | (可選)在觸發事件時生成RMON日誌條目,並將RMON MIB中的eventType設定為log或log-and-trap。 |
陷阱社群 | (可選)用於此陷阱的SNMP社群字串。將此行的RMON MIB中的eventType設定配置為snmp-trap或log-and-trap。此值與RMON MIB中eventTable中的eventCommunityValue相同。 |
說明字串 | (可選)指定事件的說明,該說明與RMON MIB的eventTable中的事件說明相同。 |
所有者字串 | (可選)此事件的所有者,與RMON MIB的eventTable中的eventOwner相同。 |
有關RMON警報和事件實施的詳細資訊,請閱讀網路管理系統最佳實踐白皮書的RMON警報和事件實施部分。
修訂 | 發佈日期 | 意見 |
---|---|---|
1.0 |
03-Oct-2005 |
初始版本 |