前言

都說監(jiān)控系統(tǒng)是運(yùn)維的第三只眼睛，因此一旦線上出問題，業(yè)務(wù)方第一反應(yīng)是，監(jiān)控系統(tǒng)有沒有提前告警？是不是告警太多被淹沒了？為啥沒有把根因報(bào)出來？上面的三個(gè)質(zhì)疑，相信做過監(jiān)控的同學(xué)都會(huì)深有體會(huì)。我做了10年的監(jiān)控，背鍋不少，在2021年的第一天，我想跟你聊一聊我的一些心得。

什么是監(jiān)控

做監(jiān)控前，先問自己一個(gè)問題。監(jiān)控的本質(zhì)是什么？我的理解是監(jiān)測(cè)并實(shí)施控制，監(jiān)測(cè)并告警只是第一步，有效的控制才是根本。

• 數(shù)據(jù)采集：采集的方式有很多種，包括日志埋點(diǎn)進(jìn)行采集(通過Logstash、Filebeat等進(jìn)行上報(bào)和解析)，JMX標(biāo)準(zhǔn)接口輸出監(jiān)控指標(biāo)，被監(jiān)控對(duì)象提供RESTAPI進(jìn)行數(shù)據(jù)采集(如Hadoop、ES)，系統(tǒng)命令行，統(tǒng)一的SDK進(jìn)行侵入式的埋點(diǎn)和上報(bào)等。

• 數(shù)據(jù)傳輸：將采集的數(shù)據(jù)以TCP、UDP或者HTTP協(xié)議的形式上報(bào)給監(jiān)控系統(tǒng)，有主動(dòng)Push模式，也有被動(dòng)Pull模式。

• 數(shù)據(jù)存儲(chǔ)：有使用MySQL、Oracle等RDBMS存儲(chǔ)的，也有使用時(shí)序數(shù)據(jù)庫RRDTool、OpentTSDB、InfluxDB存儲(chǔ)的，還有使用HBase存儲(chǔ)的。

• 數(shù)據(jù)展示：數(shù)據(jù)指標(biāo)的圖形化展示。

• 監(jiān)控告警：靈活的告警設(shè)置，以及支持郵件、短信、IM等多種通知通道。

所以做監(jiān)控的最終目的是先于用戶發(fā)現(xiàn)問題，提供有價(jià)值的告警，并閉環(huán)解決。

監(jiān)控1.0

08年剛到WS的時(shí)候，CDN業(yè)務(wù)規(guī)模還很小，公司就幾百臺(tái)機(jī)器，監(jiān)控項(xiàng)不到20種。當(dāng)時(shí)過去的時(shí)候，阿賢已經(jīng)把監(jiān)控系統(tǒng)都搭得差不多了，基本能滿足業(yè)務(wù)初期的監(jiān)控需求，監(jiān)測(cè)服務(wù)器的死活，服務(wù)狀態(tài)異常squid/lighttpd/rsync/snmp。

架構(gòu)說明：

• pingServer服務(wù)端部署在內(nèi)網(wǎng)，它從CDN平臺(tái)獲取監(jiān)控組及組對(duì)應(yīng)的監(jiān)控機(jī)，為監(jiān)控機(jī)分配監(jiān)控測(cè)試任務(wù)

• wsPoller對(duì)測(cè)試任務(wù)進(jìn)行遠(yuǎn)程測(cè)試，并根據(jù)測(cè)試結(jié)果產(chǎn)生報(bào)警發(fā)送至告警平臺(tái)

• 通過SNMPOID擴(kuò)展增加監(jiān)控的采集項(xiàng)

存在的問題：

• 單點(diǎn)策告警，容易誤報(bào)

• wsPoller無法根據(jù)自身的網(wǎng)絡(luò)、負(fù)載自動(dòng)踢除

• 機(jī)器性能監(jiān)控缺失

• 不支持本地采集

監(jiān)控2.0

隨著客戶對(duì)服務(wù)質(zhì)量的要求變高，監(jiān)控1.0的弊端開始顯露。09年初，我們決定開發(fā)監(jiān)控2.0。

團(tuán)隊(duì)在研究完Nagios、Cacti、Zabbix開源系統(tǒng)后，發(fā)現(xiàn)這些系統(tǒng)在擴(kuò)展性方面，告警運(yùn)維值班便捷性上滿足不了我司的運(yùn)維需求。

苗輝是當(dāng)時(shí)的leader，這家伙就喜歡自己折騰個(gè)東西出來，而我當(dāng)時(shí)心里挺猶豫，有開源的不用，為啥要從0到1自己搞。只是這個(gè)家伙"吹牛"還是可以的，把老板說服了，帶著4~5個(gè)應(yīng)屆生，我們就開干了。單單設(shè)計(jì)文檔我們就整了100多頁，方案來回討論了有1個(gè)月，團(tuán)隊(duì)苦逼的搞了大半年，alpha版本終于上線了。

架構(gòu)說明：

• wsmsagent——wsMS的數(shù)據(jù)收集接口；

• MI——wsMS的數(shù)據(jù)中轉(zhuǎn)加工站；

• AL——wsMS的告警分析；

• RRDS——wsMS的監(jiān)控?cái)?shù)據(jù)繪圖引擎；

• SCHEDULER——wsMS自動(dòng)均衡的決策中心；

• SCADA——wsMS的通用采集監(jiān)測(cè)組件；

• UI——展示界面。

監(jiān)控3.0

這個(gè)系統(tǒng)線上運(yùn)營了2年，2011年隨著機(jī)器規(guī)模迅速增加到7K+，平臺(tái)開始爆發(fā)出各種問題：

• 機(jī)器增加到2萬的時(shí)候，監(jiān)控?cái)?shù)據(jù)單表1天超過5億條數(shù)據(jù)，復(fù)雜的SQL告警規(guī)則查詢耗時(shí)太長(zhǎng)；

• 原始告警移到歷史告警通過Insert和Delete，性能太低；

• 通過數(shù)據(jù)持久化再分析生成告警，已經(jīng)滿足不了實(shí)時(shí)性的要求；

• 復(fù)雜的告警規(guī)則通過SQL已經(jīng)無法支持；

• 新增一種采集類型的數(shù)據(jù)，都需要二次開發(fā)，成本較高；

• 每天有2W+的告警，運(yùn)維根本處理不過來；

• 監(jiān)控和告警數(shù)據(jù)很多，為什么還是有不少故障監(jiān)控沒有發(fā)現(xiàn)？

這個(gè)時(shí)候苗輝跑去百度了，我一個(gè)人壓力山大。當(dāng)時(shí)外部對(duì)監(jiān)控不是很滿意，告警刷屏?xí)r有發(fā)生。

2015年底我決定搞監(jiān)控3.0，以構(gòu)建立體化的監(jiān)控體系為目標(biāo)，將告警分層，覆蓋從基礎(chǔ)設(shè)施->組件->產(chǎn)品服務(wù)->客戶業(yè)務(wù)的四層告警。自上而下做告警定位，由下而上確定告警影響范圍。建立告警間的相互關(guān)聯(lián)關(guān)系，當(dāng)出現(xiàn)一個(gè)嚴(yán)重級(jí)別的告警時(shí)，能展示告警的影響范圍。

架構(gòu)圖

---

調(diào)度系統(tǒng)

---

UI層：提供任務(wù)類型配置、任務(wù)分配結(jié)果查詢，任務(wù)狀態(tài)查詢，組件狀態(tài)查。2)由UI-master,UI-slave組成，利用LVS或NGNIX做主從。

任務(wù)調(diào)度層：根據(jù)原始任務(wù)狀態(tài)，監(jiān)控機(jī)狀態(tài)，任務(wù)配置狀態(tài)決策是否進(jìn)行任務(wù)分配，通過zeroMQ向任務(wù)分配層發(fā)送分配任務(wù)2)同時(shí)定時(shí)向任務(wù)加載層發(fā)送任務(wù)加載任務(wù)3)有core-master，core-slave組成，利用zk或hzelcast做主從。

任務(wù)加載層：負(fù)責(zé)接收Core-master的加載任務(wù)，向外部系統(tǒng)獲取原始任務(wù)，寫入mysql

任務(wù)分配層：負(fù)責(zé)接收Core-master的分配任務(wù)，執(zhí)行分配策略，將數(shù)據(jù)寫入memcache

數(shù)據(jù)緩存層：memcahe緩存任務(wù)分配結(jié)果，cachedump定時(shí)將分配結(jié)果快照寫入mysql

任務(wù)分發(fā)層：負(fù)責(zé)接收scada或其他采集客戶端的請(qǐng)求，將任務(wù)分發(fā)給采集端

ZeroMQ：zeroMQ，消息隊(duì)列，可自動(dòng)實(shí)現(xiàn)負(fù)載均衡

Monitor：負(fù)責(zé)調(diào)度平臺(tái)可視化數(shù)據(jù)維護(hù)，包含各組件的運(yùn)行狀態(tài)，任務(wù)加載，調(diào)度，分配，分發(fā)狀態(tài)

ZK/hazelcast：分布式協(xié)調(diào)系統(tǒng)，用于core組件進(jìn)行主備選舉，機(jī)房?jī)?nèi)部署集群，設(shè)置iptable只允許同機(jī)房訪問。

告警決策

---

NodeCluster

消息生產(chǎn)集群，接入不同的數(shù)據(jù)源類型，生產(chǎn)待計(jì)算的原始消息。如接收sdn推送的監(jiān)控采集數(shù)據(jù)，以每一行為一條計(jì)算數(shù)據(jù)提交。

MessageCluster

使用kafka消息中間件，暫存計(jì)算消息。實(shí)現(xiàn)數(shù)據(jù)的流式輸入。

JstormCluster

核心計(jì)算集群，基于storm的java版本，改進(jìn)HA問題和計(jì)算性能優(yōu)化。

MonitorCluster

集群狀態(tài)監(jiān)控，負(fù)責(zé)進(jìn)行集群內(nèi)部的組件狀態(tài)、topology計(jì)算狀態(tài)的監(jiān)控報(bào)警

ThorUI

UI作為實(shí)時(shí)計(jì)算平臺(tái)的運(yùn)營界面，主要任務(wù)是各個(gè)組件的運(yùn)行狀態(tài)收集、消息任務(wù)配置、監(jiān)控報(bào)警展示、系統(tǒng)配置等。

數(shù)據(jù)庫性能調(diào)優(yōu)

在監(jiān)控2.0階段，監(jiān)控?cái)?shù)據(jù)是存儲(chǔ)在MySQL，監(jiān)控?cái)?shù)據(jù)每天達(dá)到750G+，單表每天數(shù)據(jù)量10億條，數(shù)據(jù)查詢非常慢。我們對(duì)監(jiān)控表做讀寫分離和水平分表看下測(cè)試的效果，但測(cè)試的結(jié)果讓我們大失所望。

• 讀寫分離和單實(shí)例的查詢和更新響應(yīng)時(shí)間沒有太大的區(qū)別；

• 通過mycat的水平分表，在大量數(shù)據(jù)下有優(yōu)勢(shì)，但小量數(shù)據(jù)則無優(yōu)勢(shì)。所謂大量數(shù)據(jù)，表內(nèi)數(shù)據(jù)最好在千萬級(jí)別以上，插入量最好在百萬級(jí)別以上。

上述兩個(gè)方案行不通，我們決定采用第3種方案，表分區(qū)方案。即以5分鐘為一分區(qū)，根據(jù)每個(gè)監(jiān)控對(duì)象實(shí)際需求創(chuàng)建分區(qū)數(shù)，由crontab腳本定時(shí)執(zhí)行，執(zhí)行時(shí)根據(jù)總時(shí)長(zhǎng)、監(jiān)控?cái)?shù)據(jù)保留時(shí)長(zhǎng)、當(dāng)前時(shí)間，數(shù)據(jù)計(jì)算出要?jiǎng)h除的分區(qū)，truncate分區(qū)數(shù)據(jù)。表分區(qū)方案將delete和load、select隔離在不同分區(qū)，減少delete對(duì)load、select的影響。通過一段時(shí)間的測(cè)試，發(fā)現(xiàn)測(cè)試效果還是不錯(cuò)的，比之前有一定幅度的提升。

如何基于開源快速搭建一個(gè)監(jiān)控系統(tǒng)

1.zabbix

如果你的公司機(jī)器規(guī)模少于1000臺(tái)，沒有用到K8S，告警邏輯也不復(fù)雜，那推薦你用zabbix，基本能滿足企業(yè)內(nèi)部普通的IT運(yùn)維。

---

2.Prometheus+Clickhouse

如果你的公司機(jī)器規(guī)模大于5000臺(tái)，并且是通過容器化編排部署，告警邏輯也較為復(fù)雜，推薦Prometheus+Clickhouse?？蓞⒖贾暗奈恼隆?/p>

---

3.Prometheus+Telegraf+influxdb

Telegraf是實(shí)現(xiàn)數(shù)據(jù)采集??????????????????的工具。Telegraf 具有內(nèi)存占用小的特點(diǎn)，通過插件系統(tǒng)開發(fā)人員可輕松添加支持其他服務(wù)的擴(kuò)展。在平臺(tái)監(jiān)控系統(tǒng)中，可以使用 Telegraf 采集多種組件的運(yùn)行信息，而不需要自己手寫腳本定時(shí)采集，大大降低數(shù)據(jù)獲取的難度。

總結(jié)

最后，我總結(jié)出來做好監(jiān)控很重要的4個(gè)點(diǎn)：

• 一定要建立體系化的監(jiān)控告警平臺(tái)，確定監(jiān)控scope，避免成為“背鍋俠”。

• 監(jiān)控不只是運(yùn)維的事，研發(fā)設(shè)計(jì)要把組件監(jiān)控納入進(jìn)來。

• 監(jiān)控越往前做越有效，等到組件上線運(yùn)營后再補(bǔ)充的代價(jià)是極高的。

• 監(jiān)控發(fā)展的必經(jīng)之路，少->全->精，要避免告警風(fēng)暴，做到精準(zhǔn)。

簡(jiǎn)介?

基哥，座標(biāo)廈門，目前專注運(yùn)維架構(gòu)，DevOps的落地實(shí)踐。歡迎添加我的微信號(hào)(hongdiji)一起學(xué)習(xí)交流。

長(zhǎng)按掃碼關(guān)注

一個(gè)在看，小編會(huì)開心一整天...

總結(jié)

以上是生活随笔為你收集整理的监控ui_做了10年监控系统，有些经验想和你分享的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。