監控，是運維的眼睛，是穩定性建設中最重要的一環。

一般來講，基礎監控系統的主要功能就是發現問題。

故障發生前，通過監控的看圖巡檢，發現隱患；故障發生時，通過實時的告警，快速發現問題，定位問題所在；故障發生後，使用過去的歷史資料圖表，進行事後覆盤，避免下次發生。

本篇文章，我們不討論根因定位、故障自愈之類的高階的主題，只跟大家聊一下筆者關於基礎監控系統的一些建設心得。

一般監控系統的功能

一般的基礎監控系統，主要有看圖和告警兩大功能，通過這兩大功能，滿足上述的發現問題的需求。

看圖的功能，在看單張圖的基礎上，大部分監控系統會定製一個監控大盤的功能，將多張定義好的監控圖，放在一個頁面，記錄一個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天前，通過對趨勢的比較，可以很容易把握住服務的狀態，哪裡出問題一目瞭然。

• 資料縱向的聚合

假設我有一個節點，下有十臺機器，我顯示這十臺機器的情況，就要有十條曲線。但我現在想要看一個整個節點的總體情況，那曲線的聚合，就必不可少了。

可以通過將多條曲線，同一時刻的資料相加或者求平均，來進行資料的聚合，用以體現出一個總體的情況。

如何讓報警能力更加強大

告警一般來講，需要兩部分資料，一部分是配置資料，一部分是監控資料。

報警配置的獲取，見仁見智吧，不涉及效能問題，可以通過佇列來通知，也可以定時拉取，只要保證好一致性和實時性就好了。

監控資料的獲取，一般來講，分為“推”和“拉”兩種模式：

• 推模式——告警資料在上報時，自動推往告警模組

這種模式最大的一個優點就是實時性好，因為報警的模組可以第一時間拿到這個資料。

但是“推模式”有很致命的缺點，首先資料是全量灌過來的，解析和暫存會消耗大量的記憶體。而且這種模式，報警模組只能按照資料來進行分片，如果需要聚合場景計算，很可能這部分資料推往了不同的報警節點，就無法滿足了。

• 拉模式——由告警模組定時從儲存拉取監控資料

“拉”模式最大的好處在於，報警分片可以按照策略來分片，這樣報警模組只需要拉取自己需要的資料即可，而且可以完美支援聚合場景，減少了很大一部分記憶體消耗。

而“拉模式”的缺點在於，監控的資料體量非常龐大，高併發的查詢會對儲存叢集造成極大的壓力。此處如果出現效能瓶頸，可以考慮監控資料的冷熱分離。

監控的穩定性架構

監控系統，是穩定性工作的基石。如果監控系統都不夠穩定，那我們依賴監控系統進行穩定性建設就無從談起。

最後，給大家分享幾個筆者公司在建設監控系統時的穩定性架構，有問題大家可以隨時指出：

在資料上報的鏈路建設中，可以考慮使用訊息佇列來應對流量的潮汐。因為監控資料的上報，尤其是使用者自定義資料的上報，很可能不是均勻的，會與流量、業務峰谷有關。

此時，通過一個訊息佇列，來緩衝大批量的沒有時間處理的資料，是一個不錯的選擇。

儲存的穩定性，可以考慮資料雙寫。兩個叢集分開部署。可以應對專線斷開以及分片掛掉兩種情況。

告警其實是比較難做雙活的，尤其是alarm這種報警的收斂模組。

因為雙活意味著兩份，兩份服務，也意味著同一條報警發兩次。這明顯不符合預期。

因此，對於告警體系，給大家推薦我們的主從模式：從叢集平時處於休眠狀態，會定時的對主叢集進行探測，一旦發現主叢集掛掉，或探測不通，就將自身拉起，達到一個故障時間內的雙活。

以上就是筆者關於監控系統的一些建設心得的大綱，後續筆者會針對每一個方向寫一篇深入的專題。

歡迎大家隨時討論交流。

本文作者：高家升