• <big id="iig5e"><em id="iig5e"></em></big>

  • <big id="iig5e"><em id="iig5e"></em></big>
    <th id="iig5e"><option id="iig5e"></option></th>
    <th id="iig5e"><option id="iig5e"></option></th>
    <th id="iig5e"><video id="iig5e"></video></th>

  • 景安微信
    右側QQ聯系不上,可以加我微信
    您好,歡迎來到景安網絡!
    加盟景安
    主頁 >服務器軟件 >從0到1000+臺服務器監控的構建之路

    從0到1000+臺服務器監控的構建之路


    來源:景安網絡發表日期:2019-06-27瀏覽次數:Tags:服務器監控
    景安網絡專業的數據中心服務商,長期提供數據中心托管服務,私有云,互聯網解決方案,互聯網增值服務。針對工信委大力實施“萬企業上云”計劃,景安以我所能,為你而+,推出上云特惠,核心云計算產品降幅達50%!!也歡迎來聊右側qq

    從入職到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!謝謝大家!

    0(好文)
    0(太水)
    版權聲明:部分文章源于網絡,如侵權請聯系我們刪除
    買購快云Plus,云服務器折上折

    專題頁

    色播