AA-NPM方案測試報告

1、AA-NPM方案測試報告行業(yè)背景和需求公司介紹Riverbed NPM/APM的方法論AA-NPM測試報告探針流量、應(yīng)用流量、TOP流量的監(jiān)控和分析 。每個應(yīng)用詳盡KPI指標(biāo)的監(jiān)控和分析。故障排查應(yīng)用模塊里各個智能分析模型的使用。Web應(yīng)用的分析。掌上生活業(yè)務(wù)流監(jiān)控和預(yù)警。議題行業(yè)背景和需求3IT部門常常遇到的狀況“唉,今天系統(tǒng)又是好慢！IT的人都在干嘛！”End User 最終用戶整體應(yīng)用性能應(yīng)用部門“是網(wǎng)絡(luò)問題應(yīng)用的Log都很正常沒有任何Exceptions我們已經(jīng)壓力測試過了!主機(jī)系統(tǒng)部門“與我無關(guān),可能是網(wǎng)絡(luò)CPU 是正常的內(nèi)存使用率也很低Disk I/O 一切正常網(wǎng)絡(luò)部門“網(wǎng)絡(luò)沒問題

2、”網(wǎng)絡(luò)流量不大Ping 時延都正常Traceroute 也沒問題DBA“沒有什么異?，F(xiàn)象”交易數(shù)比平常多一點(diǎn)， 不過看起來也是正常的IT部門處理用戶的投訴問題從哪下手? 叫每個部門硬找出問題?問題時有時無，飄忽不定怎么辦?企業(yè)網(wǎng)里普遍存在的問題的IT組織因為業(yè)務(wù)應(yīng)用性能降低受到影響的時間中IT組織是從終端用戶那里得知應(yīng)用問題的75%70%的性能問題需要長達(dá)一個月以上才能被解決或者永遠(yuǎn)不會被解決31%500ms 500ms延遲會引起頁面訪問量降低20%交易機(jī)構(gòu)1ms的損失可能高達(dá)400萬美元1ms 100ms 100ms頁面加載時間導(dǎo)致銷售量減少1%交易延時給用戶帶來的損失銀行業(yè)重要信息系統(tǒng)突發(fā)

3、事件應(yīng)急管理規(guī)范NPM/APM的方法論端到端交易應(yīng)用的完整性能監(jiān)控(NPM+APM).NET Worker ProcessIIS Native PipelineTCP/IP 協(xié)議棧Web服務(wù)器客戶端瀏覽器廣域網(wǎng)WAS JVMApacheTCP/IP StackWAS Thread PoolApp服務(wù)器局域網(wǎng)起始處理排隊代碼執(zhí)行網(wǎng)絡(luò)、帶寬、延遲處理排隊處理排隊代碼執(zhí)行遠(yuǎn)程調(diào)用Web服務(wù)，數(shù)據(jù)庫網(wǎng)絡(luò)傳輸性能指標(biāo)代碼執(zhí)行代碼執(zhí)行網(wǎng)絡(luò)傳輸性能指標(biāo)網(wǎng)絡(luò)傳輸EUE代碼執(zhí)行網(wǎng)絡(luò)、帶寬、延遲代碼執(zhí)行結(jié)束網(wǎng)頁渲染時間服務(wù)響應(yīng)網(wǎng)絡(luò)、帶寬、延遲、丟包服務(wù)請求網(wǎng)絡(luò)、帶寬、延遲、丟包主要的技術(shù)手段NPM的主要技術(shù)手段重

4、點(diǎn)區(qū)域（如數(shù)據(jù)中心）監(jiān)控，探針技術(shù)：通過抓取網(wǎng)絡(luò)數(shù)據(jù)包進(jìn)行分析。全網(wǎng)流量監(jiān)控，F(xiàn)low 技術(shù)： 采集網(wǎng)絡(luò)設(shè)備統(tǒng)計的NetFlow, sFlow, J-Flow, NetStream。APM的主要技術(shù)手段端到端（用戶端）監(jiān)控，Web頁面JavaScript腳本嵌入技術(shù)（針對Web類應(yīng)用）。端到端（服務(wù)器端）監(jiān)控， JVM/CLR Agent的代碼植入技術(shù)（針對JAVA/.Net應(yīng)用）。探針的工作原理匯總應(yīng)用流的KPI指標(biāo)，得到該應(yīng)用的KPI；并進(jìn)行智能預(yù)警通過鏡像或TAP抓取數(shù)據(jù)包，建立索引并保存數(shù)據(jù)自下而上應(yīng)用的KPIFlowsPackets快速定位故障故障定位精細(xì)原始的證據(jù)獲取故障數(shù)據(jù)包證據(jù)

5、 故障預(yù)警，揭示潛在問題早期預(yù)警分析自上而下11分析數(shù)據(jù)包里每個應(yīng)用流的KPI指標(biāo)：包括流量，網(wǎng)絡(luò)傳輸時間，服務(wù)器延時，重傳DATAACKREQUEST服務(wù)器響應(yīng)時間Round Trip Time (Outbound) *數(shù)據(jù)傳輸時間Time連接建立時間SYNSYN/ACKACKREQUESTDATAACKDATAACK服務(wù)器客戶端交互 1交互 2Round Trip Time (Inbound)Riverbed 詳盡的延時參數(shù)計算* 數(shù)據(jù)傳輸時間 = Payload 傳輸時間 + 重傳導(dǎo)致的延時*Round Trip Time 的計算針對每個 DATA/ACK對。用戶響應(yīng)時間ARXWeb響應(yīng)

6、時間WEB ServerAPPS ServerWEBAPPSDBDatabase ServerService Provider探針部署示意圖APP響應(yīng)時間DB響應(yīng)時間端到端監(jiān)控的重要技術(shù)：Web頁面JavaScript腳本嵌入技術(shù)的工作原理euemon.jsResponse with JavaScript in Header euemon.js Request from client GET index.htmlEUE metrics to collector (Port 80/443)BMX Server (public facing)End Users BrowserWeb Server1

7、23123Webpage requested by user GET index.htmlJS served from CDN/BrowserMetrixJS sends results to collectorWeb頁面顯示耗時：38.9秒http:/ Analysis端到端監(jiān)控的重要技術(shù)：Web頁面JavaScript腳本嵌入技術(shù)的工作原理APM Agent監(jiān)控有兩種技術(shù)手段“快照方式”“代碼插入技術(shù)”（2001年就有標(biāo)準(zhǔn)接口）技術(shù)原理：每隔一定時間對應(yīng)用的運(yùn)行進(jìn)行“快照”掃描；查找問題。缺點(diǎn)：系統(tǒng)開銷大，只能“采樣”監(jiān)控（間隔掃描）;不能串聯(lián)多個節(jié)點(diǎn)的交易。廠商： AppDynamics

8、，NewRelic技術(shù)原理：對應(yīng)用植入簡易代碼，猶如安裝了GPS應(yīng)用交易實(shí)時全程監(jiān)控。優(yōu)點(diǎn)：系統(tǒng)開銷小，每筆交易的全程監(jiān)控，多節(jié)點(diǎn)關(guān)聯(lián)分析。支持大數(shù)據(jù)分析。廠商： Riverbed, Dynatrace.端到端交易應(yīng)用的完整性能監(jiān)控(NPM+APM).NET Worker ProcessIIS Native PipelineTCP/IP 協(xié)議棧Web服務(wù)器客戶端瀏覽器廣域網(wǎng)WAS JVMApacheTCP/IP StackWAS Thread PoolApp服務(wù)器局域網(wǎng)起始處理排隊代碼執(zhí)行網(wǎng)絡(luò)、帶寬、延遲處理排隊處理排隊代碼執(zhí)行遠(yuǎn)程調(diào)用Web服務(wù)，數(shù)據(jù)庫網(wǎng)絡(luò)傳輸性能指標(biāo)代碼執(zhí)行代碼執(zhí)行網(wǎng)絡(luò)傳輸

9、性能指標(biāo)網(wǎng)絡(luò)傳輸EUE代碼執(zhí)行網(wǎng)絡(luò)、帶寬、延遲代碼執(zhí)行結(jié)束網(wǎng)頁渲染時間服務(wù)響應(yīng)網(wǎng)絡(luò)、帶寬、延遲、丟包服務(wù)請求網(wǎng)絡(luò)、帶寬、延遲、丟包Riverbed Performance Management端到端的全程關(guān)聯(lián)監(jiān)控（APM和NPM的關(guān)聯(lián)）http:/ code abc0.3秒 code xyz應(yīng)用代碼(classes/methods)6.3秒 code def0.4秒 code ghi后端延時: 82%前端延時: 18% 20sec SELECT x FROM y 4sec INSERT a INTO bSQL 語句網(wǎng)絡(luò) 134 重傳 1.3 請求MBs 17 連接重置 1.2 響應(yīng)MBs6.8

10、秒 圖片, .js, .css0.4秒 頁面渲染時間客戶端URL: http:/ 王大錘終端用戶性能: 40.9sec數(shù)據(jù)中心全局業(yè)務(wù)視圖 數(shù)據(jù)中心重要業(yè)務(wù)監(jiān)控 數(shù)據(jù)中心單個應(yīng)用業(yè)務(wù)流監(jiān)控aa-NPM測試報告Who用戶都是誰？內(nèi)部用戶還是外部客戶？What在操作什么業(yè)務(wù)？ 使用什么終端訪問？When什么時候操作了業(yè)務(wù)？Where在什么地方訪問業(yè)務(wù)？How帶寬使用狀況如何？HTTP響應(yīng)是成功還是失敗嗎？失敗了是服務(wù)器錯誤（HTTP 500），還是客戶端錯誤（HTTP 400）？用戶體驗是快還是慢？如果慢，是服務(wù)器的問題，還是網(wǎng)絡(luò)的問題？如果是服務(wù)器的問題，瓶頸在哪一跳的應(yīng)用服務(wù)器上？當(dāng)我們談應(yīng)用

11、性能，我們希望了解什么？探針流量、應(yīng)用流量、TOP流量的監(jiān)控和分析探針接口及每個應(yīng)用協(xié)議流量和其他KPI的監(jiān)控通過Inbound 和outbound IP地址的定義，單個探針接口就可監(jiān)控進(jìn)出兩個方向的流量信息。上圖顯示:工作日15:00-16:00 期間流量會有突發(fā)，導(dǎo)致應(yīng)用服務(wù)器響應(yīng)時間增大。圖中突發(fā)流量達(dá)到200Mbps，但電信和聯(lián)通總帶寬為400Mbps；所以電信和聯(lián)通的接口帶寬不是瓶頸?？焖俨檎夷硞€時段的流量信息 包括TOP主機(jī)，TOP通訊對，TOP應(yīng)用，TOP 網(wǎng)段每個應(yīng)用詳盡KPI指標(biāo)的監(jiān)控和分析該時段，整體HTTP業(yè)務(wù)用戶響應(yīng)時間為586毫秒，其中數(shù)據(jù)凈荷傳輸197毫秒，TCP建

12、鏈時間186毫秒，重傳時延136毫秒，服務(wù)器時延65毫秒。 外網(wǎng)客戶端的平均網(wǎng)絡(luò)延時98毫秒，服務(wù)器網(wǎng)絡(luò)延時0.49毫秒。因此：整體來看用戶體驗良好；時延主要來自Internet時延、TCP建鏈時間、重傳延時、以及數(shù)據(jù)傳輸。2015-4-12 8:30-10:00 服務(wù)器響應(yīng)時間異常，可以輕松被ARX監(jiān)控系統(tǒng)捕獲。掌上生活網(wǎng)絡(luò)出口整體HTTP KPI的監(jiān)控分析每個應(yīng)用協(xié)議的KPI指標(biāo)監(jiān)控該時段；ClientFace-WebMlife-BeforeF5業(yè)務(wù)用戶響應(yīng)時間為683毫秒，其中數(shù)據(jù)凈荷傳輸387毫秒，重傳時延266毫秒，服務(wù)器時延29毫秒。 外網(wǎng)的客戶端的平均網(wǎng)絡(luò)延時123毫秒, 內(nèi)網(wǎng)服

13、務(wù)器網(wǎng)絡(luò)延時0.21毫秒因此：Internet時延和丟包、以及數(shù)據(jù)傳輸是時延的主因。提供豐富的應(yīng)用KPI指標(biāo)，幫助用戶查找問題。無需用戶定義自動發(fā)現(xiàn)應(yīng)用并監(jiān)控；KPI指標(biāo)與已定義的應(yīng)用一樣豐富。故障排查應(yīng)用模塊里各個智能分析模型的使用網(wǎng)絡(luò)延時分析模型 快速查找到某時段每個IP業(yè)務(wù)組里網(wǎng)絡(luò)延時最長的應(yīng)用、主機(jī)以及相關(guān)通訊對。上圖顯示2014-12-12 17:00-17:30時間段，招行信用卡中心聯(lián)通地址的對外服務(wù)器HTTP業(yè)務(wù)里，網(wǎng)絡(luò)延時最慢的客戶端IP，都是公網(wǎng)IP，來自天津聯(lián)通和四川廣安移動。哪些IP業(yè)務(wù)組里出現(xiàn)問題？哪些業(yè)務(wù)應(yīng)用里出現(xiàn)問題？應(yīng)用服務(wù)器的IP是什么？哪些客戶端與該服務(wù)器通訊

14、時出問題？網(wǎng)絡(luò)丟包分析模型 快速查找到某時段每個IP業(yè)務(wù)組里丟包最嚴(yán)重的應(yīng)用、主機(jī)以及相關(guān)通訊對。顯示2014-12-12 17:00-17:30時間段，招行信用卡中心聯(lián)通地址的對外服務(wù)器HTTP業(yè)務(wù)里，網(wǎng)絡(luò)丟包率最大的客戶端IP，都是公網(wǎng)IP，主要來自天津聯(lián)通和四川廣安移動。哪些IP業(yè)務(wù)組里出現(xiàn)問題？哪些業(yè)務(wù)應(yīng)用里出現(xiàn)問題？應(yīng)用服務(wù)器的IP是什么？哪些客戶端與該服務(wù)器通訊時出問題？服務(wù)器響應(yīng)慢分析模型 快速查找到某時段每個IP業(yè)務(wù)組里服務(wù)器最慢的應(yīng)用、主機(jī)以及相關(guān)通訊對。顯示2014-12-12 17:00-17:30時間段，招行信用卡中心電信地址的對外服務(wù)器Repayment-web業(yè)務(wù)，

15、服務(wù)器響應(yīng)延時為259毫秒，與服務(wù)器Top10交互的客戶端IP地址見右下角視圖。哪些IP業(yè)務(wù)組里出現(xiàn)問題？哪些業(yè)務(wù)應(yīng)用里出現(xiàn)問題？應(yīng)用服務(wù)器的IP是什么？哪些客戶端與該服務(wù)器通訊時出問題？蠕蟲攻擊分析模型 快速查找到某時段每個IP業(yè)務(wù)組里存在類似蠕蟲攻擊的應(yīng)用、發(fā)起攻擊的主機(jī)。顯示2014-12-12 17:00-17:30時間段，招行信用卡中心192.168.X.X網(wǎng)段HTTP業(yè)務(wù)，存在的類似蠕蟲攻擊導(dǎo)致的連接失敗數(shù)的服務(wù)器IP，以及發(fā)起該攻擊的客戶端IP.哪些IP業(yè)務(wù)組里出現(xiàn)問題？哪些業(yè)務(wù)應(yīng)用里出現(xiàn)問題？應(yīng)用服務(wù)器的IP是什么？哪些客戶端與該服務(wù)器通訊時出問題？應(yīng)用質(zhì)量前后分析模型 快速查

16、看某時段每個IP業(yè)務(wù)組里某個應(yīng)用（割接或調(diào)整）前后KPI指標(biāo)對比。上圖顯示招行信用卡中心聯(lián)通地址的對外服務(wù)器HTTP業(yè)務(wù)，在不同時間段（可以是割接或調(diào)整前后時間段），復(fù)合響應(yīng)時間參數(shù)的比較。比較哪些IP業(yè)務(wù)組？查看哪些業(yè)務(wù)應(yīng)用？割接或調(diào)整前的KPI割接或調(diào)整后的KPIWeb應(yīng)用的分析Web業(yè)務(wù)在不同區(qū)域的KPI頁面響應(yīng)時間？服務(wù)器響應(yīng)時間？網(wǎng)絡(luò)傳輸延時？慢頁面的次數(shù)？頁面訪問次數(shù)？Web業(yè)務(wù)名稱？用戶來自哪里？什么時間？電信掌上生活聯(lián)通掌上生活業(yè)務(wù)KPI 監(jiān)控分析頁面響應(yīng)時間？哪些用戶訪問慢？慢頁面的URL及它們的頁面響應(yīng)時間曲線？每分鐘有多少次頁面訪問？什么時間？HTTP成功響應(yīng)多少次？HT

17、TP客戶端錯誤響應(yīng)失敗多少次？HTTP服務(wù)器錯誤響應(yīng)失敗多少次？HTTP重定向多少次？HTTP繼續(xù)響應(yīng)多少次？如果響應(yīng)慢，是服務(wù)器的原因，還是網(wǎng)絡(luò)因素導(dǎo)致？電信掌上生活業(yè)務(wù)KPI 監(jiān)控分析頁面響應(yīng)時間？哪些用戶訪問慢？慢頁面的URL及它們的頁面響應(yīng)時間曲線？每分鐘有多少次頁面訪問？什么時間？HTTP成功響應(yīng)多少次？HTTP客戶端錯誤響應(yīng)失敗多少次？HTTP服務(wù)器錯誤響應(yīng)失敗多少次？HTTP重定向多少次？HTTP繼續(xù)響應(yīng)多少次？如果響應(yīng)慢，是服務(wù)器的原因，還是網(wǎng)絡(luò)因素導(dǎo)致？電信掌上生活業(yè)務(wù)在不同區(qū)域的KPI頁面響應(yīng)時間？服務(wù)器響應(yīng)時間？網(wǎng)絡(luò)傳輸延時？慢頁面的次數(shù)？頁面訪問次數(shù)？來自哪些國家？用戶

18、來自哪里？什么時間？電信掌上生活業(yè)務(wù)在不同區(qū)域的KPI頁面響應(yīng)時間？服務(wù)器響應(yīng)時間？網(wǎng)絡(luò)傳輸延時？慢頁面的次數(shù)？頁面訪問次數(shù)？用戶來自哪些??？什么時間？來自哪些國家？選中省的頁面響應(yīng)時間和頁面訪問數(shù)？電信掌上生活業(yè)務(wù)在不同區(qū)域的KPI頁面響應(yīng)時間？服務(wù)器響應(yīng)時間？網(wǎng)絡(luò)傳輸延時？慢頁面的次數(shù)？頁面訪問次數(shù)？該省用戶頁面響應(yīng)時間的曲線圖？什么時間？來自哪些??？電信掌上生活業(yè)務(wù)用戶終端分析頁面響應(yīng)時間？服務(wù)器響應(yīng)時間？網(wǎng)絡(luò)傳輸延時？慢頁面次數(shù)？頁面訪問次數(shù)？用戶使用哪些終端？什么時間？移動支付業(yè)務(wù)的故障排查 延時來自服務(wù)器頁面響應(yīng)時間？服務(wù)器響應(yīng)時間？網(wǎng)絡(luò)傳輸延時？慢頁面次數(shù)？頁面訪問次數(shù)？Web業(yè)

19、務(wù)名稱？用戶來自哪里？什么時間？移動支付業(yè)務(wù)的故障排查 請求主要來自北京頁面響應(yīng)時間？服務(wù)器響應(yīng)時間？網(wǎng)絡(luò)傳輸延時？慢頁面次數(shù)？頁面訪問次數(shù)？來自哪些國家？用戶來自哪里？什么時間？選中省或直轄市的頁面響應(yīng)時間和頁面訪問數(shù)？移動支付業(yè)務(wù)的故障排查 請求集中來自北京頁面響應(yīng)時間？服務(wù)器響應(yīng)時間？網(wǎng)絡(luò)傳輸延時？慢頁面次數(shù)？頁面訪問次數(shù)？來自哪些省和直轄市？什么時間？該省或直轄市用戶頁面響應(yīng)時間的曲線圖？移動支付業(yè)務(wù)的故障排查 導(dǎo)致慢的頁面元素哪些頁面元素導(dǎo)致響應(yīng)緩慢，它們的具體URL是什么？無需用戶定義，自動發(fā)現(xiàn)應(yīng)用的URL并監(jiān)控 包括訪問的頁面數(shù)、慢頁面的數(shù)，慢頁面百分比、頁面訪問平均時間和HTT

20、P錯誤數(shù).Mlife的ClientFace-Web業(yè)務(wù)；大體包含四個頁面族，其中出現(xiàn)慢頁面訪問比例最高的一般是http:/ 在此查看慢頁面，可以發(fā)現(xiàn)大部分頁面慢并非服務(wù)器響應(yīng)慢，而是消耗在網(wǎng)絡(luò)傳輸上?？梢园l(fā)現(xiàn)在2012-12-12 16:00-16:30時間里；有如上頁面訪問很慢；其中選中的第一個URL頁面問題最突出，有13085次用戶訪問都超過5秒，下面是每個用戶的訪問情況。從數(shù)據(jù)來看，用戶訪問慢的原因不是服務(wù)器，而是用戶訪問的數(shù)據(jù)量比較大，需要拆分到很多個IP數(shù)據(jù)包里在互聯(lián)網(wǎng)上傳輸導(dǎo)致，因此時間都消耗在網(wǎng)絡(luò)傳輸上。因此可以建議應(yīng)用部門對于這些網(wǎng)頁進(jìn)行優(yōu)化，減少數(shù)據(jù)量，來緩解這些頁面訪問慢的

21、問題。掌上生活業(yè)務(wù)流監(jiān)控和預(yù)警掌上生活業(yè)務(wù)流監(jiān)控和預(yù)警智能監(jiān)控和預(yù)警每一跳業(yè)務(wù)應(yīng)用該應(yīng)用出了什么問題？ 是重置和重傳導(dǎo)致告警掌上生活業(yè)務(wù)流監(jiān)控和預(yù)警 具體告警信息超過基線產(chǎn)生告警重傳的問題出現(xiàn)問題的時間服務(wù)器IP地址客戶端IP地址掌上生活業(yè)務(wù)流監(jiān)控和預(yù)警 具體告警信息超過基線產(chǎn)生告警TCP重置的問題出現(xiàn)問題的時間服務(wù)器IP地址客戶端IP地址公司介紹Riverbed 科技公司2006 年 IPO 后，營業(yè)額年均增長年營業(yè)額 2013年：公司成立時間2002 成立于：舊金山名員工2600+EnergyRetailBankingManufacturingHealthcareAECTechnology

22、InsuranceLegal企業(yè)客戶22,000+78個辦公室 個國家/地區(qū)39 106%$1B (NASD: RVBD)Riverbed 是行業(yè)中的領(lǐng)軍企業(yè)Source: Gartner (April 2013) Joe Skorupa, Mark Fabbi, Bjarne MunchRiverbed is again a leader in the Gartner Magic Quadrant for WAN Optimization Controllers. After 6 years in a row as a leader, Riverbed stands alone in the

23、 leaders quadrant. “The rate and pace of change in enterprise IT has grown exponentially over the last few years,” said Eric Wolford, president products group at Riverbed. “New IT architectures and shifts in business structure such as cloud computing, virtualization, software defined data centers, m

24、obility and the consumerization of IT create opportunities for the business and new challenges for the CIO. Many of our customers are finding that WAN optimization is at the heart of enabling these new approaches without sacrificing performance. With our breadth and depth of optimizations and form factors, our customers rely on Riverbed as a strategic partner for ensuring application performance.”This Magic Quadrant graphic was published by Gartner, Inc. as part of a larger research note and should be evaluated in the context of the entire report. The Gartner report is availa