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

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

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

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

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

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

第一階段：200臺以下

第二階段：200~1000臺

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

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

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

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

1. 簡單，易用；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

經(jīng)過很長一段時間的慎重考慮，我決定自己搞一套監(jiān)控系統(tǒng)，其實也是因為之前深入了解Nagios的整體架構(gòu)和運作模式，覺得自己做一套也不是不可能的。

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

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

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

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

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

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

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

總結(jié)

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

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

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

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

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

QA部分

問：這個底層還是nagios嗎？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

問：這個精確值是秒嗎？

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

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

答：透視寶正在研究。

問：交換機獲取的什么指標？

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

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

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

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

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

問：是在程序里埋點嗎？

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

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

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

問：公司有幾個運維？

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

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

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

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

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

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

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

問：你們物理機都大概什么配置？

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

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

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

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

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

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

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

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

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

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

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

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

答：網(wǎng)絡震蕩就是交換機重新學習mac地址，導致短時間內(nèi)網(wǎng)絡不通。

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

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

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

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

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

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

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

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

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

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

廣告

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