監控，是運維的眼睛，是穩定性建設中最重要的一環。
一般來講，基礎監控系統的主要功能就是發現問題。
故障發生前，通過監控的看圖巡檢，發現隱患；故障發生時，通過實時的告警，快速發現問題，定位問題所在；故障發生后，使用過去的歷史數據圖表，進行事后復盤，避免下次發生。
本篇文章，我們不討論根因定位、故障自愈之類的高端的主題，只跟大家聊一下筆者關于基礎監控系統的一些建設心得。
一般監控系統的功能
一般的基礎監控系統，主要有看圖和告警兩大功能，通過這兩大功能，滿足上述的發現問題的需求。
看圖的功能，在看單張圖的基礎上，大部分監控系統會定制一個監控大盤的功能，將多張定義好的監控圖，放在一個頁面，記錄一個URL，每次只要打開這個URL，就能看到自己定義好的所有監控圖。
監控大盤主要適合運維定時巡檢的場景。比方說，運維同學，把所有業務的核心指標都放在一個監控大盤里。每天早上，只要打開這個頁面，就可以看到自己業務最核心指標的情況，流量變化、穩定性隱患，一目了然。
監控系統模塊拆解
我們以open-falcon架構圖為例，其實這張圖看起來復雜，拆解起來卻很簡單。
綠色的實線，是數據的上報流；橙色的虛線，是策略的分發流；藍色的虛線，是看圖的數據流。
整體來看，一般的監控系統分為四部分：
采集：對應open-falcon的agent以及App library
存儲：對應open-falcon的transfer、Query和graph
告警：對應open-falcon的Judge、Alarm
繪圖：對應open-falcon的Dashboard
數據采集的原則
數據采集，說起來比較簡單，只要把數據報上來就行，具體怎么采集，那就八仙過海各顯神通了。
但是我們作為平臺的設計者，必須要考慮標準化與規范化。
標準化，即抽象出統一的數據模型，用以支持各種自定義的采集數據。
這里值得一提的是，確定統一的數據模型，非但不會影響各種自定義的采集需求，反而能更靈活的支撐各種自定義的需求。
另一個需要注意的，就是采集方式的標準化。
我們采集端口、進程、日志、流量的各方面數據的方式，這個做好標準之后，監控的數據就會很規范。
我們在一個業務線所做的穩定性建設方案，就可以無縫地遷移到另一個業務線，無需重復造輪子，而且是摸索很久之后的最佳實踐。
存儲建設的關鍵點
存儲的建設，我覺得很重要的有三點：
- 功能
從功能上來講，數據的存儲比較簡單，只要能存取時間序列數據即可，這一點，業界所有的時序數據庫都可以做到。
但是，高端的繪圖能力和強大的告警能力，大都會依賴動態的tag關聯補全，這個索引能力要根據設計的功能來酌情建設。
open-falcon的索引是放在MySQL里的，而且數據結構比較固定，在這方面的能力還有待加強。
筆者公司為了滿足需求，是自建了一套索引模塊的。
- 性能
一般來講，我們自己建設一套時間序列存儲，成本還是很高的。因此對于大多數同學來說，大家經歷的都是時間序列數據庫的選擇。
大家在選擇合適的時序數據庫時，在性能上主要要考慮兩點：
一是數據的讀寫性能，尤其是并發讀寫時的性能，在建設之初，要做好壓測和QPS的容量規劃。
二是監控的時序數據必須要做好降采樣，也就是數據的定時歸檔。將過去一段時間的N個點，聚合成一個粗時間粒度的點。這里要注意，千萬不要做定時任務，InfluxDB的定時降采樣會帶來非常大的CPU高峰，對于要應對高并發查詢和寫入的監控存儲來說，這種性能的潮汐是非常危險的。
降采樣這一點，Open-Falcon底層的RRDTool技術就非常優秀，采用的是寫時降采樣，數據點在寫入的過程中，降采樣已經做好了，雖然會一定程度上帶來一點性能消耗，但不會出現性能的瓶頸。
- 容量
無論什么樣的存儲，無論效率和壓縮比有多高，總是會滿的。這種時候，擴展就變成了一個繞不過去的命題。
關于容量方面，要強調的是，必須要有分布式的架構，可以隨時擴容。
繪圖功能的考量
繪圖功能的定制，因人和業務而異。從筆者公司的建設經驗來看，給大家三條建議：
- 與資源管理（服務樹系統）打通
監控系統，看的是機器的資源與運行的服務情況。
資源管理，管理的是資源的歸屬情況。
因此，通過資源管理樹，快速篩選出機器列表，進而一鍵查看監控圖，可能是每個公司都會有的需求。
- 數據橫向的比較
在一張監控圖中，同時顯示當前與一段時間的環比，是發現問題的一種非常好的手段。
如上圖，綠線代表今天的數據情況，藍線代表一天前，紅線代表7天前，通過對趨勢的比較，可以很容易把握住服務的狀態，哪里出問題一目了然。
- 數據縱向的聚合
假設我有一個節點，下有十臺機器，我顯示這十臺機器的情況，就要有十條曲線。但我現在想要看一個整個節點的總體情況，那曲線的聚合，就必不可少了。
可以通過將多條曲線，同一時刻的數據相加或者求平均，來進行數據的聚合，用以體現出一個總體的情況。
如何讓報警能力更加強大
告警一般來講，需要兩部分數據，一部分是配置數據，一部分是監控數據。
報警配置的獲取，見仁見智吧，不涉及性能問題，可以通過隊列來通知，也可以定時拉取，只要保證好一致性和實時性就好了。
監控數據的獲取，一般來講，分為“推”和“拉”兩種模式：
- 推模式——告警數據在上報時，自動推往告警模塊
這種模式最大的一個優點就是實時性好，因為報警的模塊可以第一時間拿到這個數據。
但是“推模式”有很致命的缺點，首先數據是全量灌過來的，解析和暫存會消耗大量的內存。而且這種模式，報警模塊只能按照數據來進行分片，如果需要聚合場景計算，很可能這部分數據推往了不同的報警節點，就無法滿足了。
- 拉模式——由告警模塊定時從存儲拉取監控數據
“拉”模式最大的好處在于，報警分片可以按照策略來分片，這樣報警模塊只需要拉取自己需要的數據即可，而且可以完美支持聚合場景，減少了很大一部分內存消耗。
而“拉模式”的缺點在于，監控的數據體量非常龐大，高并發的查詢會對存儲集群造成極大的壓力。此處如果出現性能瓶頸，可以考慮監控數據的冷熱分離。
監控的穩定性架構
監控系統，是穩定性工作的基石。如果監控系統都不夠穩定，那我們依賴監控系統進行穩定性建設就無從談起。
最后，給大家分享幾個筆者公司在建設監控系統時的穩定性架構，有問題大家可以隨時指出：
在數據上報的鏈路建設中，可以考慮使用消息隊列來應對流量的潮汐。因為監控數據的上報，尤其是用戶自定義數據的上報，很可能不是均勻的，會與流量、業務峰谷有關。
此時，通過一個消息隊列，來緩沖大批量的沒有時間處理的數據，是一個不錯的選擇。
存儲的穩定性，可以考慮數據雙寫。兩個集群分開部署?？梢詰獙?strong>專線斷開以及分片掛掉兩種情況。
告警其實是比較難做雙活的，尤其是alarm這種報警的收斂模塊。
因為雙活意味著兩份，兩份服務，也意味著同一條報警發兩次。這明顯不符合預期。
因此，對于告警體系，給大家推薦我們的主從模式：從集群平時處于休眠狀態，會定時的對主集群進行探測，一旦發現主集群掛掉，或探測不通，就將自身拉起，達到一個故障時間內的雙活。
以上就是筆者關于監控系統的一些建設心得的大綱，后續筆者會針對每一個方向寫一篇深入的專題。
歡迎大家隨時討論交流。
