本文再寫一篇和具體業務邏輯幾乎無關的公共服務應用監控平臺，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://www.nagios.org
https://www.zabbix.com
https://github.com/opserver/Opserver
http://open-falcon.org
https://hertzbeat.com
https://github.com/louislam/uptime-kuma
https://prometheus.io
https://grafana.com
http://app-metrics.io
https://www.influxdata.com
https://www.cacti.net
https://icinga.com
https://www.netxms.org
https://help.aliyun.com/product/34364.html
作者：Jeff Wong
出處：http://jeffwongishandsome.cnblogs.com/
本文著作權歸作者和博客園共有，歡迎圍觀轉載，轉載時請您務必在文章明顯位置給出原文鏈接，謝謝您的合作，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/465090.html
標籤：架構設計