服務器需要每天監控什麼信息?

YYY


現在所有的企業都基本需要用到服務器,那麼服務器的所有信息都應該得到監控,以便管理然而一臺服務器每天需要監控的東西其實很多,比如常見的有以下內容:

一、網站故障監控,如果你所運行的項目出現了故障服務器要自動以短信或者郵件提醒的方式通知你,如果沒有這個監控,或許等你發現時損失已經很大。

二、服務器性能監控,其實就對服務器(計算機)CPU、內存、硬盤、負載等硬件使用多少的一個監控,如果出現了服務器硬件使用消耗過大那麼就要考慮是否升級服務器配置了。

三、網站安全監控,如果網站遭到黑客的攻擊這時服務器如果有這項監控那麼就會立刻通知你,這時採取相應的措施反攻擊,以免自己的網站受到攻擊。網站安全可以說是非常重要的,一旦黑客攻擊進來你的網站數據丟失,損失就很大了。

四、用戶訪問速度監控,監控所有訪問本服務器的用戶的訪問速度。

五、備份數據監控,查看網站的備份是否成功,哪些網站備份過、哪些沒有。網站備份可以讓你的數據有個保存,出現了突發問題可以立馬恢復到上一個版本。所以說網站的備份大家也要注重。

六、端口監控,服務器中端口檢測也尤為重要,監控服務器開啟了哪些端口哪些端口被佔用,如果某些端口被一些不知名的IP或者程序佔用那麼就要考慮是不是服務器中了病毒,被黑客所利用。

以上只是個人觀點,不足之處還請大家補充。


黎明科技園


一、 機器數量小於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自動切換到一個分中心節點,分節點升級為中心節點。


bobovideo


像常見的監控cpu、內存、磁盤使用率、站點等等。一般來說,其實服務器大多數時候都不會出問題,現在用著免費雲主機管理工具雲幫手,可視化面板,可以自定義告警條件,彈窗提示,不用手動老是檢查。


可以下載體驗一下:https://www.cloudx.cn/download?utm_source=cai-wukong


瓜瓜987


第一,硬盤,溫度,網絡丟包率。

第二階梯,基本屬於人工範疇,日誌,系統,軟體


aito1


比如網絡故障,服務器性能,網絡安全,用戶訪問速度監控等等。


分享到:


相關文章: