AdMaster精碩科技是中國領先的獨立第三方營銷大數據解決方案提供商，也是目前國内的獨立第三方DMP（大數據管理平台）平台。目前，AdMaster已經為快消、IT、汽車等多個行業80%的世界100強品牌及衆多國内知名品牌提供數據服務，杜蕾斯、寶潔、卡夫、雅詩蘭黛、可口可樂、伊利、聯合利華、麥當勞、微軟、東風日産等大家耳熟能詳的品牌都在使用精碩科技的數據服務。

雲智慧有幸邀請到精碩科技運維總監顧凱先生，為大家帶來《從幾台到幾千台的運維經曆》精彩分享：

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

多年以來一直以穩定運行為前提，确保業務永不掉線，帶領運維團隊自主開發了運維系統，包含，資産管理，工單管理，監控系統，域名管理，公有雲管理，私有雲管理等平台，并将運維數據進行分析整理，将運維工作透明化，可視化。

這次主要給大家介紹一下從幾十台到幾千台服務器的運維過程中，監控系統的變遷經曆。常說一千個人心中有一千個哈姆雷特，一千個運維的心中有一千種運維的方法，沒有一個方法是萬能的、可以适用所有的場景，具體問題還得具體分析，我将這五年的經曆大緻分了三個階段：

第一階段：200台以下

第二階段：200~1000台

第三階段：1000 （1000以上和2000以上沒啥區别了）

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

一、 機器數量小于200台的階段

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

1. 簡單，易用；

2. 穩定運行；

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

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

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

二、機器數量200到1000的階段

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

1. 統一監控内容：将基礎監控進行統一，默認每個機器都包含CPU，内存，磁盤空間等基礎信息監控；

2. 覆蓋式監控：将所有機器均納入監控，除去基礎監控以外，最重要的當屬業務監控，盡可能的覆蓋業務流程，通過自定義監控減少和去除重複的問題，保障業務穩定運行。

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

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

随着機器越來越多，需要監控的服務也越來越多，告警信息出現爆發式增長，每天收到上千封報警郵件。有個小插曲，我應該是第一個将騰訊企業郵箱撐爆的人，不是容量撐爆了，是郵件的數量超過了他們數據庫的最大值，導緻我在一周内沒辦法收發郵件，也沒辦法删除。

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

1. 根據自己的需求繼續深度開發Nagios；

2. 自建監控。

這時候有些朋友會想：換一個别的開源監控就能解決了。使用開源軟件的最大問題就是，這個軟件有什麼功能你才能用什麼功能，沒有的功能要麼自己開發，要麼放棄使用，大量報警隻是一個改變的轉折點，經過長時間的使用和積累，通用的、普适的開源監控産品已經不能完全滿足龐大複雜的需求了。

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

三、機器數量超過1000台的階段

經過前期的思索和準備，到這個階段開始開發自己的監控系統，解決痛點，完成需求，主要有幾個事情：

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

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

3. 分離告警和顯示：前面的監控系統，基本上告警功能和顯示功能均在一起，不同機房的信息也需要彙總在中心節點後統一顯示和告警。重要的告警的處理是分秒必争的，也跟界面顯示無關，所以我在設計的時候将顯示和告警功能進行了一次分離，在本地機房進行報警，然後再集中展示。

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

分布式節點切換示意圖

總結

自建監控系統的好處就是可以充分利用數據、組合數據、分析數據、解釋數據，将晦澀難懂的數據解讀成人人能懂的數據，讓産品人員、銷售人員、老闆統統明白當前的業務狀态是怎麼樣的。最後給大家展示兩個我們自建監控系統中分析後展示的數據：

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

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

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

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

QA部分

問：這個底層還是nagios嗎？

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

問：數據庫這塊有監控麼？還是交由專門的dba負責？

答：我們沒有單獨針對對數據庫的監控，還是調用别人的監控腳本，然後獲取數據。

問：你們在業務監控上都做了那些工作？

答：業務監控我們也有一些，給大家發個圖：

這個是我們的業務監控，将所有的監控數據用文字進行描述，讓産品、業務同學以及老闆都知道現在是什麼情況。

問：這麼大的數據收集量，數據庫端有做特殊的優化嗎？異步處理？

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

問：這個監控對資源的消耗有多大？

答：還好，集中展示處理數據的時候遇到過一些瓶頸，不斷在優化。

問：智能DNS系統是自己開發的嗎？

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

問：請問下你們數據庫是MySQL集群麼？

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

問：這個精确值是秒嗎？

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

問：你們現在隻用了監控寶嗎？透視寶有沒有在用呢？

答：透視寶正在研究。

問：交換機獲取的什麼指标？

答：CPU，内存，警告信息，流量，端口。

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

答：目前公司用的阿裡雲自建數據庫，性能有很大問題，雲服務的IO普遍存在問題，阿裡最嚴重。

問：業務監控怎麼做的？

答：業務監控其實跟透視寶類似，隻不過沒有做到那麼細粒度。

問：是在程序裡埋點嗎？

答：不在程序裡埋點，就是利用監控數據實現的，所以隻能做到現象級别，不能做到代碼級。

問：是監控日志？還是CPU這些？

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

問：公司有幾個運維？

答：算上我一共8個人，這個圖是我們自己開發的平台。

問：運維每天工作怎麼劃分的，分産品嗎？

答：早期分産品，第二階段自動化作完之後，基本上随意了，都通過工單系統來完成，常規的工單審批結束後自動上線，不需要運維參與。

問：有沒有一堆業務統計需求？

答：有，需求由我來分配，經常需要統計的需求我們會做好了，直接給他們看系統取數。

問：私有雲用的什麼工具？

答：基于kvm做的開發，早期用gopstack、openstack，後來發現太重了。簡單理解一下私有雲，就是kvm 自動化。

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

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

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

答：将運維可視化的原因其實還有一個就是别人不理解運維，不知道運維在幹什麼，經常被誤解為安裝系統、執行腳本的。可視化就是将大家重點關注的展示出來，用運維的數據教育他們，工單是所有運維操作的起點，也是避免背鍋扯皮的利器，工單系統其實是我最花心思設計的系統，工單的流程，尤其是審批。遇到濫用工單的情況，能氣死你。

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

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

問：透視寶可以監控網絡出口帶寬的擁堵嗎？

答：透視寶主要是做應用性能監控的，透視寶就像是應用系統的CT掃描儀，能夠采集實際用戶移動端和浏覽器端體驗性能數據、服務器上運行的應用環境、數據庫訪問、應用代碼的執行性能數據，然後利用大數據技術把采集到的數據進行快速診斷分析，發現影響應用性能的“病竈”，并給出診斷建議，網絡環節的監控是由監控寶完成的，二者結合可以真正實現從用戶端到服務端的全鍊路服務監控和問題診斷。

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

答：比如一個功能運作正常，突然點了沒反應，代碼沒有任何報錯，過一段時間又恢複了，日志都正常沒征兆，但就是找不到原因，CPU、内存這些都正常，網絡流量也沒有波動，連接數也是正常範圍。

問：大家有沒有碰到過内網問題導緻的業務失效？

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

問：sfp網絡震蕩是什麼？如果網絡問題，那應該其他所有都有影響吧？

答：網絡震蕩就是交換機重新學習mac地址，導緻短時間内網絡不通。

問：網絡震蕩是什麼原因引起的？

答：專業的解釋是由于報文變化或者定時器超時，反複觸發重計算，會一直持續在根橋選擇、端口角色切換、端口狀态遷移三個過程，常見的原因有：

鍊路故障：網絡上某個端口的鍊路屬性，如端口狀态、速率和雙工模式等持續變化；

節點故障：單個交換機CPU較高，無法在定時間隔内發送或處理STP報文；

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

簡單的說，一個模塊出現問題、一根網線出現問題，導緻頻繁的up down幾次，就會出現網絡震蕩。

問：碰到這種問題不會報警嗎？特征就是短時間内網絡不通？大概有多久，顧總是怎麼發現的？

答：單看交換機的話會被認為誤報，結合業務發現不是，我們的大數據集群增長過程遇到的問題，看你怎麼設置阈值了，常規的不會報。我針對這個作了特殊的監控，端口發現不出來，交換機常規日志裡也沒有，有個特殊的日志記錄的，一下想不起來了（能否補充？）

問：端口單雙工和速率變化呢？交換機日志還沒收集？

答：沒有改變，ELK作交換機日志收集處理。