作者： Colin Jao 饒康立 – VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化、分散式安全防護技術與新應用遞送方案的介紹與推廣。

想像一下一個日常可能發生的情境。重要的對外業務服務，客服那邊往後傳遞了狀況，用戶抱怨現在為什麼連線變得超慢的，可以馬上解決嗎。碰到這樣的狀況，我們很快地看了一下維運方案的 Dashboard，好像各個構件都運作正常沒有告警。那接下來怎麼辦？

 

  • 應用會變慢，一定是網路 Team的狀況

 

  • 應用會變慢，一定是虛擬化造成的

 

  • 應用會變慢，顯然是資料庫交易能力不足

 

  • 一定是儲存 IO 有問題

 

  • 肯定是LB處理效能不足

 

然後大家就指來指去…當然，要解決上述的問題，有很多方案可以導入。由網路到系統及儲存的Dashboard與告警機制、應用效能監控方案 (Application Performance Monitor)、網路監控方案等等。但如同前篇討論，應用遞送方案位於核心業務的前方，經手各項重要交易，本身就能看到相當多資訊。下圖是前篇我們就貼出的 Avi 交易日誌範例，接下來我們要特別討論以紅框包起來的交易 End-to-End Timing 部分，以及裡面的各部分時間定義。

在上圖內，整筆交易的 End-to-End Timing 是最後 Total Time 所顯示的 81 ms，這代表此交易的總用戶體驗時間。但在整個時間內，Avi 又可切分為下列的時間段細項：

 

  • Client RTT (Client Round-Trip Time)：由用戶端的瀏覽器/行動設備到負載平衡器間的網路延遲時間。這段時間是資訊團隊無法去控制的，延遲時間長可能表示用戶從遙遠的美國連線回台灣，或是用戶本身的Internet線路壅塞…等等。這邊的時間很容易估算，比如說透過TCP連線前面的three-way handshake就能估算出由用戶端到服務引擎間的網路時間。

 

  • Server RTT (Server Round-Trip Time)：由負載平衡器到後端Pool內伺服器的網路延遲時間。這邊已經在客戶可以管控的環境內，如果過大當然應該進行處理。Server RTT是由負載平衡器到Server間的TCP三向交握連線來估算出，一般來說應該很低。如果出現不合理的長延遲時間，大概會是下列幾個原因：

 

  • 負載平衡器（Avi的服務引擎）與後端伺服器放置在不同地點，兩地間的網路延遲時間長。比如說服務引擎放在公有雲上，但是應用伺服器是在企業自己機房內

 

  • 企業本身的資料中心網路 / 伺服器網卡出現問題或擁塞，造成連線回應過慢

 

  • 後端伺服器可能是遭到惡意攻擊或效能過低，TCP Stack壅塞（簡而言之，被打爆了），因此新的TCP連線要求處理時間變長

 

  • App Response：應用回應的延遲時間，這是一個估算值。應用回應的原因很多，可能是後端設備IO不好、資料庫處理能力差、App Server效能有問題等等都有可能。Avi服務引擎所在的位置無法判斷是哪一段有狀況，但可以看到的是當用戶發出HTTP Method的要求時（比如說GET、POST、PUT），服務引擎過了多久才收到後端Server的回應。此時把這個時間扣除Server RTT的網路時間以及資料傳輸的需求時間 (Data Transfer)，就是App Response Time

 

  • Data Transfer：應用資料本身的傳輸時間。Avi是以服務引擎收到HTTP回應資料的第一個Byte到最後一個Byte，加上Server RTT的二分之一來估算。

 

回到前面的討論。那麼當用戶抱怨應用效能不好時，Avi的日誌分析可以提供什麼協助？我們可以看到各個交易所花費的總時間，而更重要的，找到問題的發生點是在網路上，或是在系統上。如果是Client RTT過高，大家能做的事情不多，回報客戶抱歉，你在的地點實在太遠。當然後續應該討論是不是要導入CDN或是把應用藉由Global Load Balancing放在全球不同地點這樣的。如果Server RTT過高，網路Team應該檢查Data Center Networking這段是否有壅塞，Server Team應該確認是否有過大TCP DDoS攻擊，或是 LB / Server間的放置地點太遠。

 

而很常見的是App Response Time過高，此時大家就應該往後找問題了。這邊我要強調，Avi的方案並不是APM (Application Performance Monitor)。Avi的服務引擎只看到應用回應時間過長，但不會知道這個問題點是在Web / AP / DB哪個構件上，或是不是儲存IO有問題。可是大家在不需要購買昂貴的APM方案，在應用上植入插件 / Agent的狀況下，光採用Avi的原生功能，就至少可以判斷問題在網路或應用端。我想這是非常有價值的。

 

有個重點：Avi日誌內的時間分析，和Avi可以看懂L7應用的表頭與資訊有關。如果目前應用就只是基礎L4的TCP / UDP，不要求Avi採用L7引擎，可以看到的東西就不多了。下圖是前篇也有出現的標準L4日誌，我們可以看到前後兩段TCP連線的RTT，但Total Time (143 ms) 這段是因為大資料傳輸，還是後端伺服器回應等待時間過長，就分不出來了。

下一篇我們繼續討論Avi日誌分析內的搜尋以及其他相關功能。