來源：民工哥技術之路
ID：jishuroad
作者：顧凱
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作交換機日誌收集處理。