监控ui_做了10年监控系统，有些经验想和你分享
前言
都說監控系統是運維的第三只眼睛，因此一旦線上出問題，業務方第一反應是，監控系統有沒有提前告警？是不是告警太多被淹沒了？為啥沒有把根因報出來？上面的三個質疑，相信做過監控的同學都會深有體會。我做了10年的監控，背鍋不少，在2021年的第一天，我想跟你聊一聊我的一些心得。
什么是監控
做監控前，先問自己一個問題。監控的本質是什么？我的理解是監測并實施控制，監測并告警只是第一步，有效的控制才是根本。
數據采集：采集的方式有很多種，包括日志埋點進行采集(通過Logstash、Filebeat等進行上報和解析)，JMX標準接口輸出監控指標，被監控對象提供RESTAPI進行數據采集(如Hadoop、ES)，系統命令行，統一的SDK進行侵入式的埋點和上報等。
數據傳輸：將采集的數據以TCP、UDP或者HTTP協議的形式上報給監控系統，有主動Push模式，也有被動Pull模式。
數據存儲：有使用MySQL、Oracle等RDBMS存儲的，也有使用時序數據庫RRDTool、OpentTSDB、InfluxDB存儲的，還有使用HBase存儲的。
數據展示：數據指標的圖形化展示。
監控告警：靈活的告警設置，以及支持郵件、短信、IM等多種通知通道。
所以做監控的最終目的是先于用戶發現問題，提供有價值的告警，并閉環解決。
監控1.0
08年剛到WS的時候，CDN業務規模還很小，公司就幾百臺機器，監控項不到20種。當時過去的時候，阿賢已經把監控系統都搭得差不多了，基本能滿足業務初期的監控需求，監測服務器的死活，服務狀態異常squid/lighttpd/rsync/snmp。
架構說明：
pingServer服務端部署在內網，它從CDN平臺獲取監控組及組對應的監控機，為監控機分配監控測試任務
wsPoller對測試任務進行遠程測試，并根據測試結果產生報警發送至告警平臺
通過SNMPOID擴展增加監控的采集項
存在的問題：
單點策告警，容易誤報
wsPoller無法根據自身的網絡、負載自動踢除
機器性能監控缺失
不支持本地采集
監控2.0
隨著客戶對服務質量的要求變高，監控1.0的弊端開始顯露。09年初，我們決定開發監控2.0。
團隊在研究完Nagios、Cacti、Zabbix開源系統后，發現這些系統在擴展性方面，告警運維值班便捷性上滿足不了我司的運維需求。
苗輝是當時的leader，這家伙就喜歡自己折騰個東西出來，而我當時心里挺猶豫，有開源的不用，為啥要從0到1自己搞。只是這個家伙"吹牛"還是可以的，把老板說服了，帶著4~5個應屆生，我們就開干了。單單設計文檔我們就整了100多頁，方案來回討論了有1個月，團隊苦逼的搞了大半年，alpha版本終于上線了。
架構說明：
wsmsagent——wsMS的數據收集接口；
MI——wsMS的數據中轉加工站；
AL——wsMS的告警分析；
RRDS——wsMS的監控數據繪圖引擎；
SCHEDULER——wsMS自動均衡的決策中心；
SCADA——wsMS的通用采集監測組件；
UI——展示界面。
監控3.0
這個系統線上運營了2年，2011年隨著機器規模迅速增加到7K+，平臺開始爆發出各種問題：
機器增加到2萬的時候，監控數據單表1天超過5億條數據，復雜的SQL告警規則查詢耗時太長；
原始告警移到歷史告警通過Insert和Delete，性能太低；
通過數據持久化再分析生成告警，已經滿足不了實時性的要求；
復雜的告警規則通過SQL已經無法支持；
新增一種采集類型的數據，都需要二次開發，成本較高；
每天有2W+的告警，運維根本處理不過來；
監控和告警數據很多，為什么還是有不少故障監控沒有發現？
這個時候苗輝跑去百度了，我一個人壓力山大。當時外部對監控不是很滿意，告警刷屏時有發生。
2015年底我決定搞監控3.0，以構建立體化的監控體系為目標，將告警分層，覆蓋從基礎設施->組件->產品服務->客戶業務的四層告警。自上而下做告警定位，由下而上確定告警影響范圍。建立告警間的相互關聯關系，當出現一個嚴重級別的告警時，能展示告警的影響范圍。
架構圖
調度系統
UI層：提供任務類型配置、任務分配結果查詢，任務狀態查詢，組件狀態查。2)由UI-master,UI-slave組成，利用LVS或NGNIX做主從。
任務調度層：根據原始任務狀態，監控機狀態，任務配置狀態決策是否進行任務分配，通過zeroMQ向任務分配層發送分配任務2)同時定時向任務加載層發送任務加載任務3)有core-master，core-slave組成，利用zk或hzelcast做主從。
任務加載層：負責接收Core-master的加載任務，向外部系統獲取原始任務，寫入mysql
任務分配層：負責接收Core-master的分配任務，執行分配策略，將數據寫入memcache
數據緩存層：memcahe緩存任務分配結果，cachedump定時將分配結果快照寫入mysql
任務分發層：負責接收scada或其他采集客戶端的請求，將任務分發給采集端
ZeroMQ：zeroMQ，消息隊列，可自動實現負載均衡
Monitor：負責調度平臺可視化數據維護，包含各組件的運行狀態，任務加載，調度，分配，分發狀態
ZK/hazelcast：分布式協調系統，用于core組件進行主備選舉，機房內部署集群，設置iptable只允許同機房訪問。
告警決策
NodeCluster
消息生產集群，接入不同的數據源類型，生產待計算的原始消息。如接收sdn推送的監控采集數據，以每一行為一條計算數據提交。
MessageCluster
使用kafka消息中間件，暫存計算消息。實現數據的流式輸入。
JstormCluster
核心計算集群，基于storm的java版本，改進HA問題和計算性能優化。
MonitorCluster
集群狀態監控，負責進行集群內部的組件狀態、topology計算狀態的監控報警
ThorUI
UI作為實時計算平臺的運營界面，主要任務是各個組件的運行狀態收集、消息任務配置、監控報警展示、系統配置等。
數據庫性能調優
在監控2.0階段，監控數據是存儲在MySQL，監控數據每天達到750G+，單表每天數據量10億條，數據查詢非常慢。我們對監控表做讀寫分離和水平分表看下測試的效果，但測試的結果讓我們大失所望。
讀寫分離和單實例的查詢和更新響應時間沒有太大的區別；
通過mycat的水平分表，在大量數據下有優勢，但小量數據則無優勢。所謂大量數據，表內數據最好在千萬級別以上，插入量最好在百萬級別以上。
上述兩個方案行不通，我們決定采用第3種方案，表分區方案。即以5分鐘為一分區，根據每個監控對象實際需求創建分區數，由crontab腳本定時執行，執行時根據總時長、監控數據保留時長、當前時間，數據計算出要刪除的分區，truncate分區數據。表分區方案將delete和load、select隔離在不同分區，減少delete對load、select的影響。通過一段時間的測試，發現測試效果還是不錯的，比之前有一定幅度的提升。
如何基于開源快速搭建一個監控系統
1.zabbix
如果你的公司機器規模少于1000臺，沒有用到K8S，告警邏輯也不復雜，那推薦你用zabbix，基本能滿足企業內部普通的IT運維。
2.Prometheus+Clickhouse
如果你的公司機器規模大于5000臺，并且是通過容器化編排部署，告警邏輯也較為復雜，推薦Prometheus+Clickhouse。可參考之前的文章。
3.Prometheus+Telegraf+influxdb
Telegraf是實現數據采集??????????????????的工具。Telegraf 具有內存占用小的特點，通過插件系統開發人員可輕松添加支持其他服務的擴展。在平臺監控系統中，可以使用 Telegraf 采集多種組件的運行信息，而不需要自己手寫腳本定時采集，大大降低數據獲取的難度。
總結
最后，我總結出來做好監控很重要的4個點：
一定要建立體系化的監控告警平臺，確定監控scope，避免成為“背鍋俠”。
監控不只是運維的事，研發設計要把組件監控納入進來。
監控越往前做越有效，等到組件上線運營后再補充的代價是極高的。
監控發展的必經之路，少->全->精，要避免告警風暴，做到精準。
簡介?
基哥，座標廈門，目前專注運維架構，DevOps的落地實踐。歡迎添加我的微信號(hongdiji)一起學習交流。
長按掃碼關注
一個在看，小編會開心一整天...
總結
以上是生活随笔為你收集整理的监控ui_做了10年监控系统，有些经验想和你分享的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： opporeno3详细参数_vivox3
- 下一篇： dubbo内置哪几种服务容器_dubbo