監控系統選型之監控功能淺析

1、背景

---

 隨着互聯網的迅速發展，各類雲廠商不斷崛起，5年前服務器上萬規模的互聯網公司可能不超過200家，最近幾年來，這個數字在不斷上漲，並且增加的速度驚人，尤爲是虛擬化、雲計算技術的出現，十萬級別的服務器規模應該也會慢慢普及。兵馬未動，監控先行。監控的重要性沒必要多說，有認曾經將監控比喻成運維之眼，做爲一名運維人員，若是沒有監控，就至關於在"瞎忙活"。可是對於一個強大的監控軟件，到底須要具有哪些功能，要怎樣展示才能更加體現高大上以及在實現上有哪些難點.....等等一系列問題，你是否考慮過呢？

2、分析

---

一個強大的監控系統，以下一些功能必不可少。

1.數據批量採集和優化處理（原始數據收集以及處理）

2.集中展現（圖表展現和數字展現以及個性化展現）

3.告警（分組告警、告警升級、自定義告警以及告警抑制）

4.權限分離（用戶權限隔離）

5.審計（安全審計，操做流水記錄）

3、詳解

---

一、數據採集和處理

  如同炒菜，你首先須要去把食材買來，而後才能開工烹飪。監控系統也須要食材----數據。他首先須要從各地採集海量數據。如：cpu、內存、網絡、磁盤等數據，固然還有其餘數據：包括服務器uptime、os信息等等。採集到數據後，統一集中存儲到中央，也就是數據庫，而後進行統一處理和分析。這裏就有一個問題，是否是全部數據須要所有存儲到數據庫呢？若是是，所有數據都須要存儲的話，空間多是個大問題，也許你認爲如今磁盤硬件很便宜了，可是若是原始數據不通過加工，他的增加速度是你沒法想象的。

  咱們來作個簡單計算：假設咱們有6000個監控項（大約60個host，每一個host100個item)，每60s採集一次，也就是每秒須要採6000/60=100個值，也就是數據庫每一秒須要新增100個值。而這些值須要在數據庫保持必定的時間，一般是幾個月、半年、或者是一年。每一個新的數據和索引值須要必定磁盤空間的，這裏假如咱們保持最少時間：30天。咱們每秒新增100個值，30天累計下來：（30*24*3600）*100=259,200.000，或約260M。根據所使用的數據庫引擎，接收到的值類型（浮點型，整型，字符串，日誌文件等），磁盤空間保持一個單一的值可能會有所不一樣，從40字節到幾百個字節不等。一般狀況下，每一個值大約是50個字節。在咱們的案例中，這意味着260M的值將須要260M * 50字節= 13GB的磁盤空間。也就是說，60臺主機，每一個主機100個監控項，一個月的量基本上就能夠達到13GB的磁盤空間，以此類推，若是是6000臺，每臺100個監控項，數據須要保持半年，那就是13GB的600倍，也就是7800GB了。若是是6萬臺、16萬臺呢，並且這裏的監控項平均100個，已是按最少的進行計算了，因此對數據進行修整也是個難點。

  是否是須要把每分鐘的數據一直進行保存呢？我我的認爲，除了一些關鍵性的業務外（如：計費類），其餘大部分都是能夠進行稀疏處理的。好比，採集的時候是一分鐘採集一次，數據線也是一分鐘一個點，可是到了後期，時間一長，咱們可能不須要這麼精細，而只是須要查看一個趨勢圖而已，咱們通常能夠這樣處理：好比一個星期，咱們能夠每小時一個點（計算一小時的平均值、最大值、最小值），而一個月，咱們能夠一天一個點或者半天一個點這樣處理，這裏都是取時間段的平均值、最大值、最小值，按照這樣的稀疏規則，可能會節省很多空間。

二、數據展現和分析

  做爲數量這麼龐大的監控系統，天天採集到大量的服務器數據，可是，光采集了數據並進行存儲，也是毫無用處的。咱們須要集中展現和挖掘，才能將這些數據轉化成商業價值，經過這些數據挖掘和分析，能夠指導咱們線上生產環境，並做出一些成本預算、趨勢分析。好比：服務器選型、故障判斷、流量分析、用戶分佈、遊戲活動效果、資源需求等等。這些對於下降成本、故障處理以及線上運營有很是大的指導做用。固然，這裏須要用大數據的思惟去思考，咱們也就不分析的那麼高深了。哈哈，主要是我目前還沒達到那個水平。

三、告警

  若是咱們須要對某個遊戲進程的存活與否進行監控告警，須要如何實現呢？一般作法就是寫個腳本，而後再作個定時任務，定時去執行這個腳本掃描進行是否存在，一旦檢測都進程不存在，則進行短信和郵件通知。可是這種原始的方式仍是存在許多問題的：

  1.若是須要每臺機器都去寫腳本、而後作定時任務，你可能就會天天都奔波於腳本和定時任務之間

  2.若是須要服務器維護，而後你又去每臺機器停掉定時任務，繼續奔波於每臺機器的定時任務

  3.若是有一天又來了新的需求，須要在監控到進程宕掉後，進行進程的拉起，你可能又會進入下一輪腳本和定時任務之間奔波了

 一個偉大的運維人員就甘願天天被這樣輪麼？何況，我這裏也只是舉了個最簡單的例子。告警還有其餘須要考慮到方面：

  1.須要針對不一樣主機組的主機進行告警的發送（告警分組）；

  2.咱們也不可能一次性就將告警發送給領導，領導接受告警短信多了，可能他會對你這個系統的可用性產生質疑。因此咱們還須要考慮監控的告警升級機制（第一負責人先收短信並處理，處理完成就告警恢復了；若是第一負責人在必定時間內沒有搞定，這是就須要進行故障升級了，就要通知第二負責人，多是主管進行處理了；若是主管在必定時間內還沒搞定，此時，事情就搞大了，就須要對經理或者總監進行告警通知，並告知故障延時的緣由以及可以恢復的時間點，層層上報。)

  3.假如咱們某天遇到大規模網絡波動或者某個機櫃斷電，這時可能就會面臨一大波告警短信來襲，這時咱們就須要考慮告警抑制功能（整合成一條短信發出）。

  4.除了以上三種告警場景以外，平時可能有些預知的問題：好比機房網絡調整，可能會引發網絡波動，這時，就須要運維人員主動發起告警通知各個業務負責人了，因此，監控系統最好還要具有主動發送告警通知的功能，固然，這個功能也能夠放到後續的事件系統中去。

四、權限分離

  當機器已經達到必定規模，也就意味着機器的使用者也達到了必定規模，這個時候，若是不一樣部門的人須要只查看本身負責項目的機器信息，也是你須要考慮權限分離的時候了。同時，權限分離，包括查看、使用、報警、報警屏蔽、模板設定等一系列權限的分離。

五、審計

  審計是任何一個系統都必須具有的，也就是對於本系統使用者的任何操做有跡可循，須要記錄哪一個用戶在哪一個時間點幹了哪些事。

至此，一個強大的監控系統必備功能就分析完了，接下來咱們看看目前有哪些監控系統供咱們選項，固然，這裏選項只限於在開源系統中，至於爲何要選擇開源，請參閱下一篇文章。

http://51ctoo.blog.51cto.com/5742811/1697236