隨著伺服器數量的增加，使用者需求開始變得複雜，我們需要做到以下幾點：統一監控內容：雲幫手將基礎監控進行統一，預設每個機器都包含CPU，記憶體，磁碟空間等基礎資訊監控。

覆蓋式監控：雲幫手支援多IP伺服器納入監控，所有伺服器統一視覺化管理，功能覆蓋整個業務流程，避免多系統繁雜管理，保障業務高效執行。

及時通知，確保無漏報：雲幫手會在系統觸發告警規則後第一時間產生告警，且告警記錄可查詢，堅決做到不遲報不漏報。

可以跳轉這個連結去官網看看https://www.cloudx.cn/?utm_source=wu-wk

你這是假設的吧！上千臺伺服器規模，在行內也算是比較大的了，雖然沒法跟阿里騰訊這些巨頭比，但也是很牛逼的公司了，如果真是上千的伺服器讓你管（我自己在05年才管500臺，比你少很多了），那麼先恭喜你。作為這種規模網路的運維，要注意哪些呢？

1.儘可能多的要薪資，配小弟。捨得給薪資，才會捨得在資源方面進行投入，也容易招到小弟。為什麼大廠能招到牛人，就是因為薪資具有吸引力，不會為生計發愁；不發財才會把更多的心思和精力用於工作。

2.做好規劃，保證可用性。可用性高、系統及應用耦合性低，那麼即便出現部分系統故障或者down機，不影響正常對外服務，將有更多的時間來恢復故障，各方面的壓力都很小。不要把雞蛋都放在一個籃子裡，具體起來，可以根據業務或者應用，拆分成一個個小的、經濟合理的高可用叢集，比如主站叢集、資料庫叢集、訊息中介軟體叢集...有一家旅遊類頭部網站，所有資料都存在一個san機櫃中（網站、票務、三方合作...），結果悲劇發生，儲存掛了，全部服務停止，花了20多小時才從備份中恢復。

3.注重效能與成本平衡。設計合理的架構，可以大大提高效能，同樣數量的裝置或者系統，能支援更多的使用者，提高使用者體驗的同時，大大降低成本。而那些外包搞的專案，成本巨大，效能缺十分垃圾，主要原因是架構不行，比如前幾年，某重要涉商國家單位，人下班，伺服器下班；人放假，伺服器放假。

4.有效監控策略。一定要真有問題再告警，告警必須處理，要杜絕狼來了這樣的問題。

5.平臺及資料可擴充套件和可移植性。數量大，如果按照常規的方法，將會花費更多的時間和成本，甚至有時根本無法完成任務。因此，往私有云平臺轉移，是個非常好的主意。

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

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

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

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

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

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

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

第一階段：200臺以下

第二階段：200~1000臺

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

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

一、 機器數量小於200臺的階段

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

1. 簡單，易用；

2. 穩定執行；

3. 能夠報警，郵件，簡訊。

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

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

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

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

1. 統一監控內容：將基礎監控進行統一，預設每個機器都包含CPU，記憶體，磁碟空間等基礎資訊監控；

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

在這個時期對Nagios進行了深入的研究，編寫自定義指令碼、大量增加各種監控項，將Nagios大部分的外掛如nrpe、nsca和功能充分使用。

隨著機器越來越多，需要監控的服務也越來越多，告警資訊出現爆發式增長，每天收到上千封報警郵件。有個小插曲，我應該是第一個將騰訊企業郵箱撐爆的人，不是容量撐爆了，是郵件的數量超過了他們資料庫的最大值，導致我在一週內沒辦法收發郵件，也沒辦法刪除。

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

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

2. 自建監控。

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

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

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

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

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

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

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

4. 分散式部署，避免單點：每個機房設定一個分節點，就是上面說的報警節點，設定一箇中心節點，先在各個機房告警，然後彙總

監控，告警，這兩點做到就可以了

推薦你用wgcloud監控系統，這個簡單一些，不像zabbix那麼複雜