APNIC文摘—我們需要重新思考網路監測嗎?

本APNIC文摘原標題為Do we need to rethink network monitoring?,是由監測網路性能的科技公司ThousandEyes工程師Kemal Sanjta撰文。大部分電腦使用者,即使不是專業工程師等級,可能也至少聽過tracerout和ping。很多人會用ping指令檢查網路連線,或用traceroute檢查網路連線品質。一直以來,這2種指令差不多就夠用了。

隨著電腦網路越來越複雜,這2種指令的不足之處也逐漸顯現。例如traceroute可能會沒發現節點或回報錯誤連結,誤導除錯方向。Ping雖然很好用,但這個指令非常依賴網際網路控制訊息協定(Internet Control Message Protocol,ICMP),而近幾年來ICMP又常常被封鎖或管控。

有鑑於此,很多人也開始寫新的指令,希望解決這些問題;例如改善大部分傳統traceroute缺點的Paris Traceroute、大部分網路工程師檢查封包遺漏時愛用的MTR,還有可以檢測到網路位址轉譯(Network Address Translation,NAT)範圍以外問題的Dublin Traceroute等等。

以上都是發現網路問題後,用來找出問題點的做法。但最開始是誰發現問題,卻沒有一定。運氣不好的話可能等到使用者投訴才發現,但大部分的情況下,網路監測服務系統會先發現問題,並通報網管人員。

一直以來,網路監測服務系統都是利用如Syslog和簡易網路管理協定(Simple Network Management Protocol,SNMP)作為資訊來源。但最近隨著網路可靠度工程(Network Reliability Engineering,NRE)愈趨普遍,很多過去使用的指標和數據都被遮罩。大家只好開發蒐集資料的新方法,目前最常見的做法是跟目標裝置建立一個遠端對話(session),然後透過sesssion執行指令,再把結果存到後端以便分析。

但這個新做法也有它的問題,例如一台裝置能容許的遠端對話數量有其上限,用來蒐集資料的指令也很容易對CPU產生大量無用的消耗。實際上,無論新舊做法都會吃掉很多電腦資源,進而導致電腦無法執行選擇最佳路徑等關鍵的控制介面功能。

這也是為何本文作者建議大家應重新思考網路監測。他認為,現在所有網路監測解決方案都仍停留在被動蒐集資料的階段,而只要大家還停留在「事發後反應」、被動蒐集資料的一天,上述做法的缺點都很難改善。他建議,無論是負責網路、服務品質或其他專項的團隊,都應互助協作,以更整體、宏觀的視角去處理問題。也唯有如此,才能真正達到即時、穩定且不出錯的網路監測。

*台灣網路資訊中心(TWNIC)與亞太網路資訊中心(APNIC)合作,定期精選APNIC Blog文章翻譯摘要,提供中心部落格讀者了解目前亞太地區網路發展之最新趨勢。原文標題為Do we need to rethink network monitoring?

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *