從幾十臺到幾千臺服務器的運維過程中，監控系統的變遷經歷。常說一千個人心中有一千個哈姆雷特，一千個運維的心中有一千種運維的方法，沒有一個方法是萬能的、可以適用所有的場景，具體問題還得具體分析，我將這五年的經歷大致分了三個階段：
第一階段：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自動切換到一個分中心節點，分節點升級為中心節點。
分布式節點切換示意圖
粵公網安備 44010502001126號