有些企業(yè)可能會(huì)發(fā)現(xiàn),現(xiàn)在只需要基礎(chǔ)功能,但未來(lái)可能想要添加更多復(fù)雜的工具,其他企業(yè)可能覺(jué)得在開(kāi)始最好就部署全功能的NPM,而大多數(shù)人介于這兩者之間。在這篇文章中,我們將探討為什么這些以性能為導(dǎo)向的網(wǎng)絡(luò)監(jiān)控系統(tǒng)很重要以及哪些功能最重要。
停機(jī)時(shí)間正變得越來(lái)越不可接受
推動(dòng)NPM發(fā)展的一個(gè)明顯趨勢(shì)是企業(yè)需要快速解決停機(jī)時(shí)間問(wèn)題。雖然理想解決方案是創(chuàng)建一個(gè)冗余網(wǎng)絡(luò),但在很多情況下,這并不可行。這主要是因?yàn)榧軜?gòu)本身的限制,無(wú)法提供物理冗余或者因?yàn)轭A(yù)算有限。當(dāng)企業(yè)無(wú)法實(shí)現(xiàn)自動(dòng)故障轉(zhuǎn)移時(shí),最好的方法是開(kāi)發(fā)和部署高級(jí)網(wǎng)絡(luò)監(jiān)控系統(tǒng)平臺(tái),在停機(jī)發(fā)生時(shí)提醒工作人員,或發(fā)現(xiàn)可能發(fā)生的停機(jī)故障。發(fā)現(xiàn)問(wèn)題越快,解決問(wèn)題就越快。
在某些情況下,這意味著要部署工具來(lái)監(jiān)控網(wǎng)絡(luò)設(shè)備和個(gè)別鏈接。而基于所收集日志消息的警報(bào)是另一種常見(jiàn)工具,在其他情況下,還需要一直監(jiān)控到應(yīng)用層?,F(xiàn)在,絕大多數(shù)網(wǎng)絡(luò)監(jiān)控系統(tǒng)可只監(jiān)控網(wǎng)絡(luò)功能,或者同時(shí)監(jiān)控和警告網(wǎng)絡(luò)及應(yīng)用問(wèn)題。此外,深度數(shù)據(jù)包檢測(cè)應(yīng)用可快速發(fā)現(xiàn)網(wǎng)絡(luò)關(guān)鍵點(diǎn)的性能問(wèn)題。
應(yīng)用對(duì)時(shí)間日益敏感
隨著實(shí)時(shí)協(xié)作應(yīng)用(例如語(yǔ)音和視頻)的顯著增加,以及分布式應(yīng)用架構(gòu)的增加,通過(guò)網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)對(duì)時(shí)間越來(lái)越敏感。這樣的話,企業(yè)必須發(fā)現(xiàn)、標(biāo)記以及優(yōu)先處理低延遲性應(yīng)用的數(shù)據(jù)流。目前執(zhí)行這些類型任務(wù)的主要工具是服務(wù)質(zhì)量(QoS),2層和3層網(wǎng)絡(luò)設(shè)備(例如路由器和交換機(jī))配置有QoS政策以及基于這些政策的隊(duì)列操作。
理想情況下,QoS會(huì)被正確地在網(wǎng)絡(luò)中進(jìn)行配置。但通常情況下,QoS并沒(méi)有配置好,或者在數(shù)據(jù)路徑某處配置不當(dāng)。這種錯(cuò)誤可能給時(shí)間敏感性的通信造成重大影響,同時(shí),手動(dòng)發(fā)現(xiàn)這些問(wèn)題通常需要登錄和驗(yàn)證數(shù)據(jù)路徑的每個(gè)QoS配置。在另一方面,很多網(wǎng)絡(luò)監(jiān)控系統(tǒng)都有QoS分析功能,它們使用NetFlow或sFlow來(lái)自動(dòng)發(fā)現(xiàn)無(wú)效或不正確配置的QoS政策。
網(wǎng)絡(luò)架構(gòu)復(fù)雜性不斷增加
數(shù)據(jù)中心虛擬化和網(wǎng)絡(luò)覆蓋通常會(huì)掩蓋潛在的網(wǎng)絡(luò)問(wèn)題。突然之間,管理員會(huì)發(fā)現(xiàn)他們需要同時(shí)處理物理基礎(chǔ)以及對(duì)應(yīng)的虛擬網(wǎng)絡(luò)來(lái)發(fā)現(xiàn)和解決性能問(wèn)題,而很多IT部門(mén)只有工具來(lái)監(jiān)控其中一個(gè)方面,即使他們可以監(jiān)控這兩者,也可能是使用完全獨(dú)立的工具。
很多現(xiàn)代NPM可以同時(shí)監(jiān)控物理和虛擬架構(gòu),并確定問(wèn)題發(fā)生在哪個(gè)網(wǎng)絡(luò)層面,這為管理員提供了對(duì)網(wǎng)絡(luò)的完整可視性。隨著企業(yè)添加更多虛擬化和覆蓋技術(shù),這逐漸成為日益重要的要求。
事件關(guān)聯(lián)和根本原因分析無(wú)效
我們都知道,查找和解決網(wǎng)絡(luò)及應(yīng)用問(wèn)題是一回事,確定問(wèn)題的根本原因又是另一回事。在非常龐大和復(fù)雜的網(wǎng)絡(luò)中,企業(yè)很可能部署解決方法或變通方法來(lái)解決眼前的問(wèn)題,但并沒(méi)有解決根本問(wèn)題。很多時(shí)候,這可能最終會(huì)導(dǎo)致企業(yè)為解決一個(gè)問(wèn)題而對(duì)網(wǎng)絡(luò)進(jìn)行重大且低效的變更,而實(shí)際根本問(wèn)題可能是因?yàn)樯蠈訂?wèn)題。
很多網(wǎng)絡(luò)監(jiān)控系統(tǒng)提供智能來(lái)收集和分析各種網(wǎng)絡(luò)及應(yīng)用事件。通過(guò)這樣做,企業(yè)可創(chuàng)建報(bào)告關(guān)聯(lián)到最初問(wèn)題的起點(diǎn)。如果正確配置和調(diào)試,這可幫助管理員關(guān)注問(wèn)題并確定相關(guān)信息,極大地減少根本問(wèn)題的調(diào)查工作。并且,由于現(xiàn)代NPM會(huì)收集應(yīng)用層的數(shù)據(jù),很多此前未被發(fā)現(xiàn)的根本問(wèn)題現(xiàn)在可能被發(fā)現(xiàn)并得到妥善修復(fù)。
尋找單窗口監(jiān)控和故障排除
SNMP監(jiān)控器、日志服務(wù)器、NetFlow收集器和數(shù)據(jù)包嗅探器“單打獨(dú)斗”的日子已經(jīng)一去不復(fù)返了,整合這么多有用的網(wǎng)絡(luò)和性能監(jiān)控工具到統(tǒng)一的系統(tǒng)中將是非常有吸引力的。我們現(xiàn)在可整合所有這些有用的功能到單個(gè)NPM產(chǎn)品中,更重要的是,通過(guò)單窗口視圖,我們還可以創(chuàng)建單一的數(shù)據(jù)存儲(chǔ)庫(kù),并通過(guò)強(qiáng)大的數(shù)據(jù)關(guān)聯(lián)方法來(lái)創(chuàng)建報(bào)告以及做出明智的決策。
分享到微信 ×
打開(kāi)微信,點(diǎn)擊底部的“發(fā)現(xiàn)”,
使用“掃一掃”即可將網(wǎng)頁(yè)分享至朋友圈。