本文再寫一篇和具體業務邏輯幾乎無關的公共服務應用監控平臺。PowerDotNet自研的應用監控平臺系統，是服務治理的重要拼圖，和服務治理平臺配合使用效果更好。
監控開源產品非常豐富，站在巨人的肩膀上，PowerDotNet自研的監控平臺，除了基本的監控功能，還可以通過加一層代理，將應用接入開源監控軟件，降低應用和監控軟件的耦合。
在介紹系統和應用的時候，我們說過應用的一種分法是可以分爲帶界面的和不帶界面的，服務或者非服務等等等等，拆分方法不同，關注的應用形態也就不同。
帶界面的應用比較容易肉眼看到問題和異常狀況，雖然最終原因可能絕大多數都是服務端接口問題而不是帶界面應用自身的問題，這一點估計絕大多數客戶端、前端、移動端等終端開發者會表示贊同。
而不帶界面的應用服務，尤其是微服務集羣，由於多樣的外部依賴和版本、錯綜複雜的業務邏輯甚至短暫高併發的衝擊，很容易產生莫名其妙的“隱藏”問題，最終導致被延遲發現甚至直接忽略的業務異狀。
定位線上應用服務問題的方法，一種是通過強大的日誌平臺系統，這基本上是各種公司技術人員解決問題的直接方案，可是日誌系統應對的絕大多數問題都是在問題發生後了，相對而言比較被動。
另一種相對主動的解決方案，是通過靈活且相對實時的監控和預警，即應用監控平臺系統，可以在問題發生前就能迅速發現並定位預警，甚至可通過技術手段如守護進程自動修復異狀。
本文介紹的PowerDotNet的監控平臺系統，主要是針對基於服務平臺治理的後端應用的業務邏輯型監控，也就是直接針對應用的監控，但不包括應用的外部依賴如數據庫、緩存等的監控。
對於其他非應用服務的軟件產品監控，比如關係型數據庫、緩存、消息隊列以及ElasticSearch、ETCD、HBase等NewSQL產品，單獨開發監控程序成本較高，建議直接使用或二次開發開源的監控產品。
當年在某司我看到過一個應有盡有的大型監控系統，幾年前我自己也因爲業務需要嘗試着寫過點監控業務（猛擊這裏），雖然寫的不夠深入和全面，部署也不太容易，卻也解決了燃眉之急。
在實現PowerDotNet監控系統之前，先後參考調研了nagios、zabbix、opserver、open-falcon、ARMS、uptime-kuma、hertzbeat、prometheus和grafana等主流開源監控產品，也借鑑了某司的監控平臺系統。
對比這些監控軟件，尤其prometheus和grafana，作爲後起之秀確實全面強大靈活，所以在前面介紹基礎設施公共服務的時候我就感覺沒必要單獨再造輪子，但已寫好的又不忍丟棄，咩哈哈。
按照時間、服務器、系統、應用和具體API服務或頁面進行精準監控和分析是PowerDotNet的剛需，所以PowerDotNet的監控平臺系統開發出來也不是完全沒有用武之地，僅針對應用監控還是拿得出手的。
PowerDotNet的監控平臺系統Power.XMonitor主要包括如下四部分：
1、XMonitor.Client 監控客戶端接入SDK，支持Thrift和Http協議
2、XMonitor.Gateway 監控網關，客戶端推送至網關，網關將監控數據推送至服務端
3、XMonitor.Server 監控服務端，主要包括監控數據消息隊列生產者XMonitor.Producer、消費者XMonitor.Consumer和監控預警服務XMonitor.ForewarnAlert
4、XMonitor.AdminUI 監控管理後臺，主要用於預警配置，查看監控數據和日誌，以及監控儀表盤等。
Power.XMonitor最粗監控粒度是時間範圍，最細監控粒度則精確到某個具體API服務，可按需監控某段時間範圍內、某臺服務器，某個系統，某個應用，某個服務的監控數據，支持靈活的監控預警指標和規則配置，支持郵件、釘釘、短信、微信等通知通道。
和Power.XLogger日誌接入代理類似，應用監控接入代理業務邏輯和資源使用當然是越少越好，對於業務系統接入幾乎完全無感，最終做到簡單易用靈活可插拔，這也是我們開發Agent應遵守的準則之一。
下面詳細講講PowerDotNet內置的應用監控平臺系統Power.XMonitor。
環境準備
1、（必須）.Net Framework4.5+
2、（必須）MySQL或SqlServer或PostgreSQL或MariaDB或MongoDB或InfluxDB或ElasticSearch
3、（必須）PowerDotNet數據庫管理平臺，主要使用DBKey功能
4、（必須）PowerDotNet配置中心Power.ConfigCenter
5、（必須）PowerDotNet註冊中心Power.RegistryCenter
6、（必須）PowerDotNet緩存平臺Power.Cache
7、（必須）PowerDotNet消息平臺Power.Message
8、（可選）PowerDotNet數據同步平臺Power.DataX
一、數據採集
Power.XMonitor的數據採集主要分爲系統環境和業務邏輯指標參數兩部分。
系統環境指標部分主要包括CLR的線程數、打開的句柄數、CPU、內存、磁盤、實時Socket連接數等。
業務邏輯指標部分主要包括服務器IP和端口、被調用服務數、服務被調用總次數、服務調用異常總數、服務請求總流量、服務應答總流量、服務調用總耗時、服務調用最大耗時等。
對於一般業務系統而言，上面的監控數據採集基本能滿足常規需求，尤其是微服務API關注的常見業務參數都設計在裏面，對直接分析和排查問題很有幫助。
二、數據傳輸
Power.XMonitor支持將採集的數據以Thrift或者HTTP協議上報給監控平臺系統，上報服務默認以消息隊列（也可配置爲直接寫庫）的形式異步高速處理，防止上報成爲業務系統性能瓶頸。
上報協議支持在配置中心動態配置，默認爲最爲通用的HTTP協議，如果業務系統追求更高性能，可以配置爲Thrift協議。
Power.XMonitor主要配置參數包括：
接入應用只需在應用啓動時寫如下一行代碼，即可無其他侵入代碼實現監控功能。
//啓動監控 XMonitor.StartCollector();
對於使用PowerDotNet服務治理平臺提供的服務治理客戶端的服務，則無需寫任何代碼，因爲客戶端程序自動集成了XMonitor，應用只需在配置中心配置App.UseXMonitor、App.MonitorRate、App.MonitorProtocal和App.MonitorCenterUrl，一個PowerDotNet服務治理下的服務即可擁有XMonitor的監控功能。
對於非API服務的應用，比如Asp.Net MVC、WebForms等應用，也可以通過XMonitor.Client和ActionFilterAttribute配合自動產生監控數據，XMonitor.Client同時還提供了推送監控數據接口，業務系統完全可以按需埋點監控。
三、數據存儲
Power.XMonitor監控數據量主要由監控頻率、應用和服務器多少來決定。
根據經驗，實際產生的監控數據量雖然遠遠不如日誌系統，但相對數量還是不小的，查詢和統計也有不少的工作量。
Power.XMonitor默認監控頻率是30秒，存儲的數據支持按分鐘、小時和天分組統計存儲。沒有設計按秒存儲，一是因爲考慮到數據量較大，二是基於實際情況，監控也沒有必要必須精確到秒。
目前監控數據存儲支持MySQL、SqlServer、PostgreSQL和MariaDB四種關係型數據庫，也支持MongoDB和ElasticSearch存儲，還可以使用時序數據庫InfluxDB存儲。
有了數據庫管理平臺的DBKey功能，監控數據庫可按需選擇切換，非常輕鬆即可實現一鍵切換，XMonitor推薦使用MongoDB或ElasticSearch或MySQL。
考慮到中大型應用的監控數據量通常都比較龐大，所以我們設計監控系統的時候都需要考慮分片處理。
DBKey配置監控數據庫這種方式天然就適合數據分片存儲，在監控數據發展到一定數據量級以後，不需要運維和DBA介入，直接換個DBKey或者通過DataX數據同步平臺修改DBKey連接串就可以切換新的監控存儲介質，歷史監控數據如果需要，可以重新部署一份監控可視化站點專門查詢歷史監控數據。
對於監控基礎數據如預警規則、預警指標、告警配置等，可以直接通過數據同步平臺同步數據，做到分片切換用戶完全無感知。
四、數據可視化
1、監控面板
Power.XMonitor開發了幾個常用的業務監控儀表盤，支持將常見監控指標通過柱狀圖、餅圖和折線圖進行友好展示，可在頁面靈活配置刷新時間自動刷新獲取數據。
（1）、時間角度看API調用次數
如果監控時間範圍在同一天內，按照小時進行拆分彙總聚合顯示
如果時間查詢範圍不在同一天，則按天聚合顯示
（2）、從服務器角度看API調用次數
（3）、流量監控
（4）、API最大耗時
這個最大耗時對於性能問題排查非常有用，當然完全可以通過日誌系統進行定位，不過監控系統查詢更加直接。
（5）、服務器指標監控
還可以支持磁盤監控，磁盤統計數據已有，只是沒在界面上展示出來。
2、每天監控數據
以天爲單位進行彙總統計，監控數據在XMonitor.Consumer消費時在內存中運算而來。
3、每小時監控數據
和每天監控數據產生類似，以小時爲單位進行彙總統計，監控數據在XMonitor.Consumer消費時在內存中運算而來。
4、每分鐘監控數據
和每小時監控數據產生類似，以分鐘爲單位進行彙總統計，監控數據在XMonitor.Consumer消費時在內存中運算而來。
相對而言，每分鐘產生的監控數據就比較大了，一般來說，監控到小時和天就基本夠用了，如果你的應用不需要詳細監控到分鐘，完全可以不寫入這個數據。
5、服務消費者監控統計
監控面板基於服務生產者的監控統計非常常見，其實Power.XMonitor也支持基於服務消費者的監控統計，比如我們經常會統計哪些（接口消費者）應用調用了什麼（服務生產者）接口，消費者調用失敗的接口次數、消費者調用的最耗時接口等等。
五、監控告警
對於監控系統而言，及時準確多樣的預警提醒也非常重要，尤其是對於核心業務系統而言，儘早發現問題可以減少甚至避免不必要的損失。
監控告警模塊設計出了預警指標、告警配置和預警規則三個子模塊，靈活設置適配常見的預警功能。
1、預警指標
預警指標包括系統環境指標和業務邏輯指標，閾值類型支持百分比和數值，支持自定義閾值觸發表達式，可適配絕大多數情況下的監控業務場景。
2、告警配置
告警配置支持告警時間段設置，默認0至23小時，也就是全天都支持告警消息支持。
告警週期的意思是，針對某個監控項的監控，重複發送消息的間隔時間不能小於告警週期，這樣可以防止重複發送大量告警消息。
告警配置有緊急、嚴重和警告三種告警級別，通常都可以配置爲警告級別，非核心應用也可以按需配置爲緊急或嚴重級別。
3、預警規則
一個預警規則，可以綁定一個或多個預警指標；一個預警規則，可以綁定一個或多個告警配置。
預警指標和告警配置相互獨立，沒有直接關係，這樣設計的好處是最大程度複用預警指標和告警配置。
預警規則配置可以精確到某臺服務器，或者某個系統，或者某個應用，甚至直接精準到某個服務接口或者具體頁面，按需配置，支持監控的最大靈活性。
4、告警消息
Power.XMonitor默認通過消息平臺Power.Message進行消息提醒，支持郵件、釘釘、短信和微信的消息提醒，當然也預留接口可以按需使用其他自定義消息平臺進行提醒。
以觸發釘釘警告信息爲例，用戶接受到簡易直接的監控告警提醒信息如下：
如何進行合理設置告警頻率並減少誤報也非常考驗監控告警模塊的設計。
監控告警設置的告警週期通常設置爲2分鐘（120秒），核心業務可以調整小一些，這樣就可以減少大量重複不必要的告警消息。
Power.XMonitor的監控告警可根據服務器、系統、應用和API服務動態設置告警頻率，默認設置爲，相同服務器、系統、應用和API服務，最低1分鐘內不重複告警，降低發送消息的頻率，減少無效誤報可能。
默認最低1分鐘告警間隔，和監控頻率有關，Power.XMonitor的默認監控頻率是30秒，建議將間隔設置爲兩個或四個頻率週期，這樣幾乎不會丟失異狀，又不過分增加服務器壓力，這也是實踐得出的結論。
5、告警反饋
Power.XMonitor理論上對所有的告警信息都需要有告警反饋處理，否則告警信息一直紅色提示爲“未處理”。
標記爲已處理的告警信息，建議進行故障分類管理，這樣非常有利於開發和運維人員快速定位並解決問題。
六、監控黑白名單
根據實際經驗，因爲業務應用開發水平的差異，對於應用接入方，我們要做到監控可按需啓停處理，否則某些“劣質”、“腐敗”、多變的應用會有意或無意的拖累甚至搞垮監控平臺，影響更多的系統和應用正常監控。
Power.XMonitor支持黑白名單功能，只要應用接入方認爲自己的應用或服務完全穩定可靠無需監控，加入白名單的通通放行，不做監控處理，加入黑名單的則給出告警提醒，定時放棄監控。
1、應用黑白名單
某些穩定的字典型應用，穩定運行後除非硬件掛掉或斷電，否則幾乎不會再修改發佈或擴容，比如PowerDotNet的DBKey服務，可以將整個應用加入監控白名單。
2、接口黑白名單
API應用中某些接口穩定運行，或者非核心業務功能的接口，訪問量極少的接口或過時的接口，不監控也不影響應用運行，可以把這部分接口加入白名單，減少資源開銷。
3、頁面黑白名單
頁面應用中某些頁面，如靜態頁、訪問極少、邏輯簡單幾乎不會出錯的頁面，可以加入白名單。
七、監控高可用
監控接口完全異步化處理，客戶端推送超時時間設置要短一些，默認超時時間爲2秒，可通過配置中心動態調整，也支持動態監控開關，這樣做的目的是哪怕監控服務掛了也不影響業務主流程。
監控服務應該儘可能減少外部依賴，就算有依賴也要保證依賴的組件和服務高可用，否則監控服務及其依賴就需要監控服務監控，自己監控自己容易進入死循環，所以應該將依賴的服務繞開監控。
Power.XMonitor目前僅依賴獲取DBKey信息和發送消息兩個接口，當監控服務開始工作時會自動繞開監控這兩個基礎服務，當然這兩個接口的調用頻率並不高，且業務邏輯較爲簡單，經實踐驗證非常可靠。
參考：
https://github.com/opserver/Opserver