從 0 到 1000+ 臺服務(wù)器監(jiān)控的構(gòu)建之路

AdMaster精碩科技是中國的獨(dú)立第三方營銷大數(shù)據(jù)解決方案提供商，也是目前國內(nèi)的獨(dú)立第三方DMP（大數(shù)據(jù)管理平臺）平臺。目前，AdMaster已經(jīng)為快消、IT、汽車等多個行業(yè)80%的世界100強(qiáng)品牌及眾多國內(nèi)知名品牌提供數(shù)據(jù)服務(wù)，杜蕾斯、寶潔、卡夫、雅詩蘭黛、可口可樂、伊利、聯(lián)合利華、麥當(dāng)勞、微軟、東風(fēng)日產(chǎn)等大家耳熟能詳?shù)钠放贫荚谑褂镁T科技的數(shù)據(jù)服務(wù)。

云智慧有幸邀請到精碩科技運(yùn)維總監(jiān)顧凱先生，為大家?guī)怼稄膸着_到幾千臺的運(yùn)維經(jīng)歷》精彩分享：

從入職到AdMaster以來歷時五年多，經(jīng)歷了公司從幾十臺到幾千臺服務(wù)器的飛速增加階段，目前AdMaster每天增長量數(shù)據(jù)量超過5T，每天請求數(shù)超過100億，每天計(jì)算超過1000億條記錄，每天計(jì)算任務(wù)數(shù)超過10萬個，1000億記錄的秒級查詢，100萬級的QPS。

多年以來一直以穩(wěn)定運(yùn)行為前提，確保業(yè)務(wù)永不掉線，帶領(lǐng)運(yùn)維團(tuán)隊(duì)自主開發(fā)了運(yùn)維系統(tǒng)，包含，資產(chǎn)管理，工單管理，監(jiān)控系統(tǒng)，域名管理，公有云管理，私有云管理等平臺，并將運(yùn)維數(shù)據(jù)進(jìn)行分析整理，將運(yùn)維工作透明化，可視化。

這次主要給大家介紹一下從幾十臺到幾千臺服務(wù)器的運(yùn)維過程中，監(jiān)控系統(tǒng)的變遷經(jīng)歷。常說一千個人心中有一千個哈姆雷特，一千個運(yùn)維的心中有一千種運(yùn)維的方法，沒有一個方法是萬能的、可以適用所有的場景，具體問題還得具體分析，我將這五年的經(jīng)歷大致分了三個階段：

第一階段：200臺以下

第二階段：200~1000臺

第三階段：1000+（1000以上和2000以上沒啥區(qū)別了）

每個階段的分界點(diǎn)也不是那么精確的，就是一個大概的時期，變化都是一個逐漸的過程。

一、 機(jī)器數(shù)量小于200臺的階段

這個時期需求簡單，主要用于通知問題、快速定位解決問題，大致總結(jié)一下，主要需求就三點(diǎn)：

1. 簡單，易用；

2. 穩(wěn)定運(yùn)行；

3. 能夠報警，郵件，短信。

基于以上需求，可以使用比較流行開源的監(jiān)控軟件Nagios，Cacti，Zabbix，Ganglia，etc。流行的開源產(chǎn)品有較多的文檔，可快速上手，并且有大量的前人使用經(jīng)驗(yàn)，可以避免許多問題，即使遇到問題也容易找到解決辦法。其中郵件報警一般是都支持的，短信需要自己對接一下短信平臺。

我們在早期的時候選擇了Nagios和Cacti，選擇Nagios主要是個人原因，我最熟悉，使用Cacti是因?yàn)閷粨Q機(jī)的監(jiān)控特別方便，幾乎是傻瓜式的。其實(shí)在這個階段，不管是哪一個監(jiān)控產(chǎn)品，基本都可以滿足需求，選擇的因素還是看個人喜好，這個時期運(yùn)維同學(xué)是可以偶爾任性一下的。

二、機(jī)器數(shù)量200到1000的階段

這個時期，需求開始變得復(fù)雜，不過主要還是用于通知、告警，避免同樣的問題再次發(fā)生，我在這個時期主要做了以下事情：

1. 統(tǒng)一監(jiān)控內(nèi)容：將基礎(chǔ)監(jiān)控進(jìn)行統(tǒng)一，默認(rèn)每個機(jī)器都包含CPU，內(nèi)存，磁盤空間等基礎(chǔ)信息監(jiān)控；

2. 覆蓋式監(jiān)控：將所有機(jī)器均納入監(jiān)控，除去基礎(chǔ)監(jiān)控以外，最重要的當(dāng)屬業(yè)務(wù)監(jiān)控，盡可能的覆蓋業(yè)務(wù)流程，通過自定義監(jiān)控減少和去除重復(fù)的問題，保障業(yè)務(wù)穩(wěn)定運(yùn)行。

3. 及時通知，確保無漏報：將所有監(jiān)控分類，根據(jù)重要程度、緊急程度等，分別用郵件，微信，短信，電話等不同級別的方式通知，確保每個監(jiān)控都有人處理，并且對于重要的業(yè)務(wù)采用call死你的方式，不處理就一直通知。

在這個時期對Nagios進(jìn)行了深入的研究，編寫自定義腳本、大量增加各種監(jiān)控項(xiàng)，將Nagios大部分的插件如nrpe、nsca和功能充分使用。

隨著機(jī)器越來越多，需要監(jiān)控的服務(wù)也越來越多，告警信息出現(xiàn)爆發(fā)式增長，每天收到上千封報警郵件。有個小插曲，我應(yīng)該是第一個將騰訊企業(yè)郵箱撐爆的人，不是容量撐爆了，是郵件的數(shù)量超過了他們數(shù)據(jù)庫的大值，導(dǎo)致我在一周內(nèi)沒辦法收發(fā)郵件，也沒辦法刪除。

這個階段的后期，也就是快接近1000臺機(jī)器的時候，Nagios的監(jiān)控功能已經(jīng)無法滿足需求了，并且Nagios圖形功能總是捉襟見肘，于是開始思考超過1000臺的情況了，擺在面前的路有兩條：

1. 根據(jù)自己的需求繼續(xù)深度開發(fā)Nagios；

2. 自建監(jiān)控。

這時候有些朋友會想：換一個別的開源監(jiān)控就能解決了。使用開源軟件的大問題就是，這個軟件有什么功能你才能用什么功能，沒有的功能要么自己開發(fā)，要么放棄使用，大量報警只是一個改變的轉(zhuǎn)折點(diǎn)，經(jīng)過長時間的使用和積累，通用的、普適的開源監(jiān)控產(chǎn)品已經(jīng)不能完全滿足龐大復(fù)雜的需求了。

經(jīng)過很長一段時間的慎重考慮，我決定自己搞一套監(jiān)控系統(tǒng)，其實(shí)也是因?yàn)橹吧钊肓私釴agios的整體架構(gòu)和運(yùn)作模式，覺得自己做一套也不是不可能的。

三、機(jī)器數(shù)量超過1000臺的階段

經(jīng)過前期的思索和準(zhǔn)備，到這個階段開始開發(fā)自己的監(jiān)控系統(tǒng)，解決痛點(diǎn)，完成需求，主要有幾個事情：

1. 具備目前在用的Nagios所有功能：比照Nagios去做，覆蓋原來的功能，并針對Nagios的問題進(jìn)行優(yōu)化改進(jìn)，然后在替代了Nagios之后再升級。（第一步最重要了，如果連之前的Nagios的功能都不能替代，自建之路只能在這里就停下了。）

2. 將告警進(jìn)行整理，化繁為簡，減少重復(fù)告警：當(dāng)出現(xiàn)轟炸式告警信息之后，如果不進(jìn)行及時整理勢必會將真正需要處理的事情耽誤，并且由于某些原因，比如線路問題，會發(fā)生重復(fù)告警，所以必需要將告警信息進(jìn)行處理再發(fā)出，預(yù)警信息由之前的每天3000+，下降到現(xiàn)在每天300以內(nèi)。

3. 分離告警和顯示：前面的監(jiān)控系統(tǒng)，基本上告警功能和顯示功能均在一起，不同機(jī)房的信息也需要匯總在中心節(jié)點(diǎn)后統(tǒng)一顯示和告警。重要的告警的處理是分秒必爭的，也跟界面顯示無關(guān)，所以我在設(shè)計(jì)的時候?qū)@示和告警功能進(jìn)行了一次分離，在本地機(jī)房進(jìn)行報警，然后再集中展示。

4. 分布式部署，避免單點(diǎn)：每個機(jī)房設(shè)置一個分節(jié)點(diǎn)，就是上面說的報警節(jié)點(diǎn)，設(shè)置一個中心節(jié)點(diǎn)，先在各個機(jī)房告警，然后匯總在中心展示。分節(jié)點(diǎn)與中心節(jié)點(diǎn)互備，通過智能DNS進(jìn)行切換，如中心節(jié)點(diǎn)宕機(jī)，DNS自動切換到一個分中心節(jié)點(diǎn)，分節(jié)點(diǎn)升級為中心節(jié)點(diǎn)。

分布式節(jié)點(diǎn)切換示意圖

總結(jié)

自建監(jiān)控系統(tǒng)的好處就是可以充分利用數(shù)據(jù)、組合數(shù)據(jù)、分析數(shù)據(jù)、解釋數(shù)據(jù)，將晦澀難懂的數(shù)據(jù)解讀成人人能懂的數(shù)據(jù)，讓產(chǎn)品人員、銷售人員、老板統(tǒng)統(tǒng)明白當(dāng)前的業(yè)務(wù)狀態(tài)是怎么樣的。最后給大家展示兩個我們自建監(jiān)控系統(tǒng)中分析后展示的數(shù)據(jù)：

這個圖顯示了全國各省訪問Track系統(tǒng)的情況，不僅包含了速度，訪問的數(shù)據(jù)中心，還能顯示是否出現(xiàn)域名劫持等信息。當(dāng)然靠自己的監(jiān)測節(jié)點(diǎn)是得不到這么多這么全的監(jiān)控?cái)?shù)據(jù)的，這時候需要云智慧的“監(jiān)控寶”出面幫忙了，我們使用監(jiān)控寶的全國200多個節(jié)點(diǎn)，將檢測數(shù)據(jù)通過API回傳，再整理分析、反饋在圖上。交換機(jī)的流量之前使用的是Cacti，交換機(jī)多了之后查找起來簡直是個龐大的任務(wù)，針對這個需求痛點(diǎn)，我們的監(jiān)控系統(tǒng)支持了交換機(jī)監(jiān)控，除了基礎(chǔ)的CPU等信息外，專門在流量上花了點(diǎn)心思。

通過上圖可以一目了然的看到當(dāng)前交換機(jī)之間的速度情況，流量都來自哪里，有多少。

這張圖可以看到哪里流量達(dá)到了預(yù)警值，哪個交換機(jī)出現(xiàn)了問題，在快速定位處理上提供了很大的便利。

最后，每個公司的需求不一樣，每個運(yùn)維面對的痛點(diǎn)也不盡相同，不管有多少變化，萬變不離其宗，有了機(jī)器上的各種監(jiān)控?cái)?shù)據(jù)，就可以組合分析出你想要的結(jié)果，自建的路上，我們才剛剛開始，keep moving！謝謝大家！

QA部分

問：這個底層還是nagios嗎？

答：不是了，完全都是自己從頭寫的，借鑒了nagios的思路，但是采集的方法，匯總處理的方法不一樣了。

問：數(shù)據(jù)庫這塊有監(jiān)控么？還是交由專門的dba負(fù)責(zé)？

答：我們沒有單獨(dú)針對對數(shù)據(jù)庫的監(jiān)控，還是調(diào)用別人的監(jiān)控腳本，然后獲取數(shù)據(jù)。

問：你們在業(yè)務(wù)監(jiān)控上都做了那些工作？

答：業(yè)務(wù)監(jiān)控我們也有一些，給大家發(fā)個圖：

這個是我們的業(yè)務(wù)監(jiān)控，將所有的監(jiān)控?cái)?shù)據(jù)用文字進(jìn)行描述，讓產(chǎn)品、業(yè)務(wù)同學(xué)以及老板都知道現(xiàn)在是什么情況。

問：這么大的數(shù)據(jù)收集量，數(shù)據(jù)庫端有做特殊的優(yōu)化嗎？異步處理？

答：是異步的，這個業(yè)務(wù)系統(tǒng)是放在大屏上展示的，出了問題時不用來研發(fā)和運(yùn)維這邊詢問，就能直接看到哪里出了問題，也知道具體找誰詢問恢復(fù)情況。

問：這個監(jiān)控對資源的消耗有多大？

答：還好，集中展示處理數(shù)據(jù)的時候遇到過一些瓶頸，不斷在優(yōu)化。

問：智能DNS系統(tǒng)是自己開發(fā)的嗎？

答：智能DNS我們用了第三方的，自己的也有。

問：請問下你們數(shù)據(jù)庫是MySQL集群么？

答：MySQL的主從，將報警和展示分開還有一個原因，就是擔(dān)心性能問題。展示可以慢幾秒鐘、幾分鐘，但報警不可以，所以報警是即時的，并且不用擔(dān)心監(jiān)控機(jī)器掛了就會變成瞎子。我們目前有6個節(jié)點(diǎn)分布在全國，全掛掉的幾率很小，只要有一臺活著就可以報警。

問：這個精確值是秒嗎？

答：秒級的，最慢的通知是電話，需要十幾秒。

問：你們現(xiàn)在只用了監(jiān)控寶嗎？透視寶有沒有在用呢？

答：透視寶正在研究。

問：交換機(jī)獲取的什么指標(biāo)？

答：CPU，內(nèi)存，警告信息，流量，端口。

問：再請教下阿里云的服務(wù)器性能是不是比自己托管服務(wù)器差很多？

答：目前公司用的阿里云自建數(shù)據(jù)庫，性能有很大問題，云服務(wù)的IO普遍存在問題，阿里最嚴(yán)重。

問：業(yè)務(wù)監(jiān)控怎么做的？

答：業(yè)務(wù)監(jiān)控其實(shí)跟透視寶類似，只不過沒有做到那么細(xì)粒度。

問：是在程序里埋點(diǎn)嗎？

答：不在程序里埋點(diǎn)，就是利用監(jiān)控?cái)?shù)據(jù)實(shí)現(xiàn)的，所以只能做到現(xiàn)象級別，不能做到代碼級。

問：是監(jiān)控日志？還是CPU這些？

答：不是CPU了，針對程序是否正常運(yùn)行的一些綜合判斷，業(yè)務(wù)監(jiān)控看到的一項(xiàng)，后面可能對應(yīng)了十幾個監(jiān)控，還有一些邏輯判定，主要是將人的分析模式變成了自動的。這個跟公司業(yè)務(wù)有關(guān)，有的是API、有的是程序，不同業(yè)務(wù)也不一樣，還有響應(yīng)速度等。

問：公司有幾個運(yùn)維？

答：算上我一共8個人，這個圖是我們自己開發(fā)的平臺。

問：運(yùn)維每天工作怎么劃分的，分產(chǎn)品嗎？

答：早期分產(chǎn)品，第二階段自動化作完之后，基本上隨意了，都通過工單系統(tǒng)來完成，常規(guī)的工單審批結(jié)束后自動上線，不需要運(yùn)維參與。

問：有沒有一堆業(yè)務(wù)統(tǒng)計(jì)需求？

答：有，需求由我來分配，經(jīng)常需要統(tǒng)計(jì)的需求我們會做好了，直接給他們看系統(tǒng)取數(shù)。

問：私有云用的什么工具？

答：基于kvm做的開發(fā)，早期用gopstack、openstack，后來發(fā)現(xiàn)太重了。簡單理解一下私有云，就是kvm 自動化。

問：你們物理機(jī)都大概什么配置？

答：最低配也是雙6核，64G。

問：你們可視化后是什么樣子，是工單嗎？

答：將運(yùn)維可視化的原因其實(shí)還有一個就是別人不理解運(yùn)維，不知道運(yùn)維在干什么，經(jīng)常被誤解為安裝系統(tǒng)、執(zhí)行腳本的?？梢暬褪菍⒋蠹抑攸c(diǎn)關(guān)注的展示出來，用運(yùn)維的數(shù)據(jù)教育他們，工單是所有運(yùn)維操作的起點(diǎn)，也是避免背鍋扯皮的利器，工單系統(tǒng)其實(shí)是我最花心思設(shè)計(jì)的系統(tǒng)，工單的流程，尤其是審批。遇到濫用工單的情況，能氣死你。

問：有沒有碰到過服務(wù)器正常、中間件和數(shù)據(jù)庫也正常，而線上業(yè)務(wù)突然失效的情況？

答：你這個可能需要透視寶。

問：透視寶可以監(jiān)控網(wǎng)絡(luò)出口帶寬的擁堵嗎？

答：透視寶主要是做應(yīng)用性能監(jiān)控的，透視寶就像是應(yīng)用系統(tǒng)的CT掃描儀，能夠采集實(shí)際用戶移動端和瀏覽器端體驗(yàn)性能數(shù)據(jù)、服務(wù)器上運(yùn)行的應(yīng)用環(huán)境、數(shù)據(jù)庫訪問、應(yīng)用代碼的執(zhí)行性能數(shù)據(jù)，然后利用大數(shù)據(jù)技術(shù)把采集到的數(shù)據(jù)進(jìn)行快速診斷分析，發(fā)現(xiàn)影響應(yīng)用性能的“病灶”，并給出診斷建議，網(wǎng)絡(luò)環(huán)節(jié)的監(jiān)控是由監(jiān)控寶完成的，二者結(jié)合可以真正實(shí)現(xiàn)從用戶端到服務(wù)端的全鏈路服務(wù)監(jiān)控和問題診斷。

問：突然失效是什么意思，前端代理有報錯嗎？有需求就下掉？

答：比如一個功能運(yùn)作正常，突然點(diǎn)了沒反應(yīng)，代碼沒有任何報錯，過一段時間又恢復(fù)了，日志都正常沒征兆，但就是找不到原因，CPU、內(nèi)存這些都正常，網(wǎng)絡(luò)流量也沒有波動，連接數(shù)也是正常范圍。

問：大家有沒有碰到過內(nèi)網(wǎng)問題導(dǎo)致的業(yè)務(wù)失效？

答：透視寶應(yīng)該可以幫到你，透視寶做的很細(xì)。透視寶是可解決內(nèi)部的問題，監(jiān)控寶可以解決外部的問題，結(jié)合起來就ok了，可以檢查下交換機(jī)，看是不是有SFP網(wǎng)絡(luò)震蕩，這個我遇到過。

問：sfp網(wǎng)絡(luò)震蕩是什么？如果網(wǎng)絡(luò)問題，那應(yīng)該其他所有都有影響吧？

答：網(wǎng)絡(luò)震蕩就是交換機(jī)重新學(xué)習(xí)mac地址，導(dǎo)致短時間內(nèi)網(wǎng)絡(luò)不通。

問：網(wǎng)絡(luò)震蕩是什么原因引起的？

答：專業(yè)的解釋是由于報文變化或者定時器超時，反復(fù)觸發(fā)重計(jì)算，會一直持續(xù)在根橋選擇、端口角色切換、端口狀態(tài)遷移三個過程，常見的原因有：

鏈路故障：網(wǎng)絡(luò)上某個端口的鏈路屬性，如端口狀態(tài)、速率和雙工模式等持續(xù)變化；

節(jié)點(diǎn)故障：單個交換機(jī)CPU較高，無法在定時間隔內(nèi)發(fā)送或處理STP報文；

網(wǎng)絡(luò)故障：網(wǎng)絡(luò)發(fā)送擁塞，導(dǎo)致根端口方向的STP報文在轉(zhuǎn)發(fā)過程中被丟棄；L2PT透傳了其他網(wǎng)絡(luò)的STP報文，造成本端STP誤收斂；網(wǎng)絡(luò)上錯誤的配置了組播抑制功能，偶爾丟棄STP報文。針對不同的故障原因，需要修改配置或者優(yōu)化網(wǎng)絡(luò)設(shè)計(jì)，解決震蕩問題。

簡單的說，一個模塊出現(xiàn)問題、一根網(wǎng)線出現(xiàn)問題，導(dǎo)致頻繁的up down幾次，就會出現(xiàn)網(wǎng)絡(luò)震蕩。

問：碰到這種問題不會報警嗎？特征就是短時間內(nèi)網(wǎng)絡(luò)不通？大概有多久，顧總是怎么發(fā)現(xiàn)的？

答：單看交換機(jī)的話會被認(rèn)為誤報，結(jié)合業(yè)務(wù)發(fā)現(xiàn)不是，我們的大數(shù)據(jù)集群增長過程遇到的問題，看你怎么設(shè)置閾值了，常規(guī)的不會報。我針對這個作了特殊的監(jiān)控，端口發(fā)現(xiàn)不出來，交換機(jī)常規(guī)日志里也沒有，有個特殊的日志記錄的，一下想不起來了（能否補(bǔ)充？）

當(dāng)前文章：從 0 到 1000+ 臺服務(wù)器監(jiān)控的構(gòu)建之路
本文來源：http://www.bm7419.com/news3/103053.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站內(nèi)鏈、企業(yè)建站、全網(wǎng)營銷推廣、關(guān)鍵詞優(yōu)化、手機(jī)網(wǎng)站建設(shè)、外貿(mào)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)