上節咱們對SharePoint的Web服務所依賴的IIS進行了監視,本節咱們繼續深刻對IIS所託管的.NET應用程序性能進行監視,即Application Performance Monitoring,簡稱APM監視。前端
經過APM監視,咱們能夠從服務器端和客戶端兩方面的角度來監視IIS所託管的.NET應用程序,以得到有關應用程序性能和可用性的詳細信息。好比了解問題出現的頻率、出現問題時服務器的表現,以及當請求響應慢或引起異常時相關的事件鏈等。經過這些信息,能夠幫助軟件開發人員或數據庫管理員分析和確認應用程序的問題所在,從而幫助找出事件的根本緣由。數據庫
接下來咱們來配置對於SharePoint的APM監視。服務器
1. 導入管理包分佈式
APM的管理包可在SCOM的安裝目錄下的ManagementPacks文件夾中找到。ide
由於.NET應用程序是IIS所託管的,因此上節導入的IIS管理包也同時必要。性能
導入本身系統相對應的管理包,我這裏選擇的是IIS8,固然也能夠都選擇。測試
導入完成後,能夠在管理包項中確認APM IIS8管理包spa
稍等幾分鐘就能夠在IIS監視的Application Pool State中確認到SharePoint的應用池狀態。3d
2. 建立APM監視orm
咱們到創做—>管理包模板中,添加監視嚮導
選擇.NET應用程序性能監視
定義名稱和目標管理包
如今咱們選擇SharePoint的Web應用程序
定義環境:這個能夠根據實際狀況選擇,最後會體如今監視名稱上。
目標組:咱們選擇以前定義的SharePoint前端組,表示這裏成員是測試環境的服務器。
在服務器端配置中,能夠啓用客戶端監視。
可是要注意:SharePoint不支持客戶端APM監視,若是強行啓用SharePoint的APM監視,則可能會致使不可預計的應用程序行爲和故障,好比CPU過載問題等。
因此這裏不勾選客戶端監視
點擊高級設置,能夠對敏感度閾值,監視器閾值等進行詳細設置。
這裏閾值仍是使用默認的15000毫秒,即15秒。
最後在摘要中,咱們發現一個警告,須要在目標的服務器上重啓IIS。
建立完畢後能夠在APM監視項中發現咱們剛纔建立的監視
3. 重啓IIS
咱們能夠直接到前端服務器上去重啓IIS
或者也能夠到計算機監視中,點開警告德的運行情況管理器
在解決方法中,進入運行重啓IIS的運行任務
運行後成功重啓目標計算機的IIS
4. APM監視
如今進入應用程序監視,稍等片刻後,就會出現咱們以前建立的SharePoint APM監視。
進入全部性能數據,能夠查看各個前端的性能數據。好比我這裏選擇了2個前端的平均請求時間,從性能上來講,這個數據很不理想。
如今進入活動警報,發現已經有一些性能異常的警報了,都是網頁的相應時間超出性能閾值引發的警報,包括有關其來源、規則、建立日期以及致使發出警報的監視設置的信息。
5. APM警報分析
接下來咱們來簡單分析下這些APM警報
點開警報屬性,能夠查看警報描述。
點擊描述中的連接,能夠打開Application Diagnostics,查看詳細信息。
Application Diagnostics是SCOM的新監視功能。
好比,在事件屬性項中,能夠查看性能指標、調用堆棧和集合註釋等性能信息。
進入資源組視圖,能夠分析致使問題的緣由,定位問題的地點,查看問題發生是的具體的行爲等等。
好比這裏,分析發現WCF : Microsoft.Office.Server.UserProfiles.IProfilePropertyService.GetProfileProperties (). Client side行爲花了20,741毫秒,嚴重的影響性能。
即在客戶端處在取得用戶的帳戶屬性時,超時。問題緣由一下就找出來了。
結合實際,由於這個警報是第一次進入SharePoint首頁時發出的,系統在獲得初始數據時花了很多時間,還屬於正常,能夠原諒。
在相關事件項中,能夠查看和此事件相關的事件。相關事件是大約與正在調查的事件在同一時間發生的事件,能夠告訴咱們大約與正在調查的事件在同一時間發生的其餘事件,幫助調查事件緣由。
在分佈式鏈項中,能夠查看此事件與事件鏈中的其餘事件之間的關係。要肯定問題或事件的根本緣由,能夠單擊鏈中的最後一個事件,這是突破性能閾值的最後一個事件。
由於我這事件鏈中只有一項,因此也就是這項致使閾值超出警報。
在性能計數器項中,顯示了事件發生以前15分鐘的系統狀況。這提供了事件以前的基準度量,利用此度量,能夠查看事件以前的系統狀態,以便知道系統是否影響了應用程序的性能。
怎麼樣,APM監視的功能仍是很強大的吧?利用好APM監視,能夠極大的幫助咱們分析應用程序性能問題的根本緣由,提升咱們解決問題的效率。