部署一個應用交付控制器(ADC)的主要任務就是為了滿足用戶的需求：在95%的情況下，他們需要保證越來越多且越來越嚴格的應用服務水平(SLA)。為此，我們必須要考慮提高應用的可用性。我們不僅利用本地服務負載均衡來保證本地服務器的暢通，還用全局負載均衡(GSLB)結合災難恢復站點來縮短全球范圍的故障時間。另外，提升性能也尤為重要，一些技術手段可以合理安排由服務器下達給ADC的CPU密度級任務來降低負載，比如SSL、壓縮和智能緩存。

    但即使是在部署最好的ADC解決方案之后，我們仍須面對監控既定SLA的挑戰。檢測某個應用程序的不可用事件看似簡單：觀察其是否有反應，若無反應則發送一個錯誤消息。一些ADC在應用不可用時會發出提醒，但為時已晚。

    從另一個角度而言，應用減速很難被檢測到。因為用戶不會經常檢測應用程序，甚至不知道多長的無反應時間是不正常的，等注意到時已落后許久。帶來的結果往往是對業務執行的嚴重損害，甚至降低員工的生產效率，同時也會影響客戶的滿意度和忠誠度。

    為了填補應用減速的監控盲區，我們需要確定對哪個節點進行實時流量監控，對哪個節點制定自動執行監控任務，并且時刻準備執行。

    在接收到應用減速提醒，并認識維護用戶體驗的重要性后，最痛苦的事情莫過于尋找引起應用減速的癥結所在，而這需要更高級的解決方案。

    應用性能監測系統(APM)是一套精良可視化的工具，它幫助IT管理員們獲取程序的性能指數，并實時維護應用的SLA活躍度。它的重要性體現在可為潛在的問題或者是在問題出現的第一時間訂制積極的解決方案，因為問題存在之后的被動反應會造成嚴重的經濟損失。

    一般說來，制定APM方案可以從以下兩方面考慮：

    1.利用運行預置的腳本的綜合工具來瀏覽web應用程序并衡量其反應時長或可用性。

    2.在每個應用程序服務器里安裝專用軟件客戶端，收集每個用戶和服務器中處理事務的數據，并以此衡量性能。

    第一個選擇是廉價的，要求應用的集成度相對較低，只需為每個應用程序運行一個非入侵性的腳本。然而這種方法有很強的局限性：一方面，它只能獲取應用程序的狀態，且不是實時的；另一方面，它無法改寫數據來解決問題。對應用程序的實時狀況（包括實際應用交易及用戶體驗）覆蓋度明顯不足。

    第二個選擇提供高端的解決方案，它能夠以每個實際用戶或業務為單位細致拆解，進行精確的根源分析。它要求前期較高的成本投入，同時需要和服務器操作系統的深度整合也會給生產環境帶來一定的風險。

    想像一下，如果你有第三個選擇會怎樣。它提供的監控方案既便捷又經濟，同時更綜合了前兩個選擇的優勢，你的應用交付設備將由這樣的APM工具所支持，它具備如下特性：

    •可監控各服務的性能；

    •可監控用戶與數據中心之間的網絡性能；

    •可監控實際用戶體驗，如響應時間，錯誤類型等；

    •可識別多用戶，多業務，以及應用裝載之間的關系映射；

    •提供一個中心APM控制臺，可從多個數據中心的各項應用中收集數據，并將處理過的信息顯示出來；

    •可為某個業務或某一組業務設置監控策略，一旦超過既定SLA就能給你提醒；

    •可提供根源分析的所有相關信息；

    Radware的APM系統是業內領先的。其狀態收集功能被整合在ADC中，它可以從這個絕佳位置來監督所有服務和用戶。它還具備先進的報告引擎來生成和傳遞符合人們閱讀習慣的報告，在該系統全權監控下，一旦任何應用的SLA有誤差，就會發出警告。

    當IT管理員捧著扔過來的性能數據，被要求去查明是否存在問題、問題的癥結何在時，不會再手足無措。Radware的APM系統可將縱向挖掘的數據，與應用裝載狀態，數據中心、網絡和用戶之間的延時曲線等橫向數據相結合，有效分析并定位影響相關SLA的根源所在。

    因此，網絡管理員不會再聽到應用管理員的抱怨，說網絡有問題再次造成應用減速；而應用團隊也不會被告知說網絡是正常的，問題出在應用本身。Radware的APM系統提供透明的監控方案，讓雙方都可以輕易地發現在應用交付的哪個環節出現問題，哪個環節造成了延時，哪個環節的工作需要完善等，讓各應用的SLA和響應時間回歸正常。

    Radware的ADC解決方案用全新的且具有歷史意義的途徑來保證各項應用的SLA：它提供的工具既支持應用的可用性又滿足其加速需求，同時，一個被整合或嵌入的APM系統可以孵化出最佳的方案，可支持重要應用性能監控的可視化功能，從而成為應用性能持續優化的有力保障。