本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?。
