http://mp.weixin.qq.com/s/4wu7649I0juCGRAMTZNR8w?utm_source=tuicool&utm_medium=referral

多年以來一直以穩定執行為前提，確保業務永不掉線，帶領運維團隊自主開發了運維繫統，包含，資產管理，工單管理，監控系統，域名管理，公有云管理，私有云管理等平臺，並將運維資料進行分析整理，將運維工作透明化，視覺化。

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

第一階段：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的思路，但是採集的方法，彙總處理的方法不一樣了。

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

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

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

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

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

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

答：智慧DNS我們用了第三方的，自己的也有作為備份。

問：請問下你們資料庫是MySQL叢集麼？

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

問：這個精確值是秒嗎？

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

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

答：透視寶正在研究。

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

答：CPU，記憶體，警告資訊，流量，埠。

問：業務監控怎麼做的？

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

問：是在程式裡埋點嗎？

答：不在程式裡埋點，就是利用監控資料實現的，所以只能做到現象級別，不能做到程式碼級。

問：公司有幾個運維？

答：算上我一共8個人。

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

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

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

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

問：有沒有碰到過伺服器正常、中介軟體和資料庫也正常，而線上業務突然失效的情況？

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

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

答： 透視寶主要是做應用效能監控的，透視寶就像是應用系統的CT掃描器，能夠採集實際使用者移動端和瀏覽器端體驗效能資料、伺服器上執行的應用環境、資料庫訪問、應用程式碼的執行效能資料，然後利用大資料技術把採集到的資料進行快速診斷分析，發現影響應用效能的“病灶”，並給出診斷建議，網路環節的監控是由監控寶完成的，二者結合可以真正實現從使用者端到服務端的全鏈路服務監控和問題診斷。

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

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

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

答：網路上的交換機，由於報文變化或者定時器超時，反覆觸發重計算，會一直持續在根橋選擇、埠角色切換、埠狀態遷移三個過程，這個過程如果持續進行多次，簡稱為STP震盪

問：網路震盪是什麼原因引起的？

答：鏈路故障：網路上某個埠的鏈路屬性，如埠狀態、速率和雙工模式等持續變化；

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

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

簡單的說，一個模組出現問題、一根網線出現問題，導致頻繁的up down幾次，就會出現網路震盪。