機房監控系統是企業機房內不可或缺的重要輔助工具，是機房內各設備的守護使者。對于企業來說，了解機房監控就是對自身機房增加一層安全保障，要想機房問題少，機房監控少不了。

監控目標

我們先來了解什么是監控，監控的重要性以及監控的目標，當然每個人所在的行業不同、公司不同、業務不同、崗位不同、對監控的理解也不同，但是我們需要注意，監控是需要站在公司的業務角度去考慮，而不是針對某個監控技術的使用。

1、 對系統不間斷實時監控：實際上是對系統不間斷的實時監控(這就是監控) 。

2、 實時反饋系統當前狀態：我們監控某個硬件、或者某個系統，都是需要能實時看到當前系統的狀態，是正常、異常、或者故障。

3、 保證服務可靠性安全性：我們監控的目的就是要保證系統、服務、業務正常運行。

4、 保證業務持續穩定運行:如果我們的監控做得很完善，即使出現故障，能第一時間接收到故障報警，在第一時間處理解決，從而保證業務持續性的穩定運行。

監控方法

既然我們了解到了監控的重要性、以及監控的目的，那么下面我們需要了解下監控有哪些方法。

1、 了解監控對象：我們要監控的對象你是否了解呢？比如 CPU 到底是如何工作的？

2、 性能基準指標：我們要監控這個東西的什么屬性？比如 CPU 的使用率、負載、用戶態、內核態、上下文切換。

3、 報警閾值定義：怎么樣才算是故障，要報警呢？比如 CPU 的負載到底多少算高，用戶態、內核態分別跑多少算高？

4、 故障處理流程：收到了故障報警，那么我們怎么處理呢？有什么更高效的處理流程嗎？

監控核心

我們了解了監控的方法、監控對象、性能指標、報警閾值定義、以及故障處理流程幾步驟，當然我們更需要知道監控的核心是什么？

1、 發現問題：當系統發生故障報警，我們會收到故障報警的信息。

2、 定位問題：故障郵件一般都會寫某某主機故障、具體故障的內容，我們需要對報警內容進行分析，比如一臺服務器連不上:我們就需要考慮是網絡問題、還是負載太高導致長時間無法連接，又或者某開發觸發了防火墻禁止的相關策略等等，我們就需要去分析故障具體原因。

3、 解決問題：當然我們了解到故障的原因后，就需要通過故障解決的優先級去解決該故障。

4、 總結問題：當我們解決完重大故障后，需要對故障原因以及防范進行總結歸納，避免以后重復出現。

監控工具

一款好的監控系統一定是最切合用戶使用習慣的，在眾多企業級機房監控中選出最完美的監控系統幾乎不現實，由于每款機房監控系統都各有各的優點，導致用戶在選擇上時常面臨新的挑戰（尤其是選擇恐懼癥患者）。

北京金恒智能CREATE機房環境及能效管理系統綜合應用計算機網絡技術、移動通信技術、自動控制技術、新型傳感技術、數據庫技術等，面向機房動力能效、機房場地環境和機房安全保障，通過信息實時采集、數據智能分析、預警、場景化數據展現、移動查詢、遠程操控等手段，實現對機房環境的便捷、高效管理。

大家在選擇合適的機房監控時要著重對比價格、產品功能以及用戶體驗等信息，尤其是用戶體驗方面。在后期的監控運維管理工作中，監控系統要做到能簡潔呈現絕不拖泥帶水，需要著重介紹不可一筆帶過。優化系統功能，為用戶提供更優質的服務。

提供多種智能基線報警策略，基于趨勢提前預警，有效規避機房事故發生。

CREATE科技機房監控系統支持多種數據采集方式，支持混合組網結構，可以逐級靈活組網。系統容量大，可平滑擴容，數據處理能力強。

CREATE機房監控系統面向業務和管理提供豐富的數據模塊和自定義功能，用戶可將不同數據模塊進行組合，建立適合本崗位的私有桌面；同時提供重點設備關注功能，使不同人員可以有針對性的對指定設備進行實時關注、跟蹤。

提供獨有的能效分析機制以及能效拓撲、電力拓撲等展現方式，為用戶提供PUE值和能效狀況專業視圖，實現實時展示與管理。

面向科技部門常規崗位和運維職能，系統提供針對性的工作場景（運維場景、報警場景、巡檢場景等）和數據支持，滿足客戶分類需求。

監控流程

CREATE機房監控系統為客戶提供了完整的監控流程，確保機房內各設備穩定運行。

1、 數據采集： 支持SNMP、WMI、SYSLOG、AGENT、JDBC、ODBC、TELNET、SSH、PING、DNS、IPMI等各種監控方式 。

2、 數據存儲：   CREATE機房監控所獲得的數據 存儲在MySQL上，也可以存儲在其他數據庫服務。

3、 數據分析：系統提供所有監控對象的監控指標、缺省閥值、報警策略等，支持系統快速實施和監控調整 。

4、 數據展示：web界面 以及 移動APP 展示，提供整體 IT環境總覽，多個不同告警、監測、配置、統計等功能提供多種不同視圖展示。

5、 監控報警：可選聲、光、現場語音、短信、Email、電話轉移、視頻聯動、控制聯動、投大屏幕等告警，也可實現分類、分時段告警抑制 。

6、 報警處理： 當接收到報警，我們需要根據故障的級別進行處理，比如 ： 重要緊急、重要不緊急等。 同時 屏蔽掉無用從屬報警，實現故障精準定位，解決告警風暴對運維人員的困擾。

此外CREATE機房監控系統還支持shell腳本和SQL語句自定義擴展，方便用戶隨時增加監控項。

監控指標

我們上面了解了監控方法、目標、流程、也了解了監控工具，可能有人會疑惑，我們具體要監控寫什么東西，那么我在這里進行了分類整理。

主要監控內容列舉:「 硬件監控 」 - 「 系統監控 」 - 「 應用監控 」 - 「 網絡監控 」 - 「 流量分析 」 - 「 日志監控 」 - 「 安全監控」 - 「 API監控 」 - 「 性能監控 」 - 「 業務監控 」。

1、 硬件監控

早期我們通過機房巡檢的方式，查看硬件設備燈光閃爍情況判斷是否故障，這樣非常浪費人力，并且是重復性無技術含量的工作，大家懂得。

當然我們現在可以通過  IPMI 對硬件詳細情況進行監控，并對 CPU、內存、磁盤、溫度、風扇、電壓等設置報警設置報警閾值(自行對監控報警內容編寫合理的報警范圍)。

2、 系統監控

中小型企業基本全是 Linux 服務器，那么我們肯定是要監控起系統資源的使用情況，系統監控是監控體系的基礎。

— CPU

CPU 有幾個重要的概念：上下文切換、運行隊列和使用率。這也是我們CPU監控的幾個重點指標。通常情況，每個處理器的運行隊列不要高于 3，CPU 利用率中 “用戶態/內核態” 比例維持在 70/30，空閑狀態維持在 50%，上下文切換要根據系統繁忙程度來綜合考量。針對 CPU 常用的工具有：htop、top、vmstat、mpstat、dstat、glances 等。

— 內存

通常我們需要監控內存的使用率、SWAP 使用率、同時可以通過 Zabbix 描繪內存使用率的曲線圖形發現某服務內存溢出等。針對內存常用的工具有: free、top、vmstat、glances 等。

— IO

IO 分為磁盤 IO 和網絡 IO 。除了在做性能調優我們要監控更詳細的數據外，那么日常監控，只關注磁盤使用率、磁盤吞吐量、磁盤寫入繁忙程度，網絡也是監控網卡流量即可。常用工具有 ： iostat、iotop、df、iftop、sar、glances 等。

3、 應用監控

把硬件監控和系統監控研究明白后，我們進一步操作是需要登陸到服務器上查看服務器運行了哪些服務，都需要監控起來。

應用服務監控也是監控體系中比較重要的內容，例如：LVS、Haproxy、Docker、Nginx、PHP、Memcached、Redis、MySQL、Rabbitmq等等，相關的服務都需要監控起來。

4、 網絡監控

網絡監控是我們構建監控平臺是必須要考慮的，尤其是針對有多個機房的場景，各個機房之間的網絡狀態，機房和全國各地的網絡狀態都是我們需要重點關注的對象，那么如何掌握這些狀態信息呢？我們需要借助于網絡監控工具 Smokeping。

Smokeping 是 RRDTool 的作者 Tobi Oetiker 的作品，是用 Perl 寫的，主要是監視網絡性能，WWW 服務器性能，DNS 查詢性能等，使用 RRDTool 繪圖，而且支持分布式，直接從多個 Agent 進行數據的匯總。

5、 流量分析

網站流量分析對于運維人員來說，更是一門必須掌握的知識了。比如對于一家電商公司來說：通過對訂單來源的統計和分析，可以了解我們在某個網站上的廣告投入有沒有收到預期的效果?？梢詤^分不同地區的訪問人數、甚至商品交易額等。百度統計、Google分析、站長工具等等，只需要在頁面嵌入一個js即可。但是，數據始終是在對方手中，個性化定制不方便，于是 Google 出一個叫 PiWik 的開源分析工具。

6、 日志監控

通常情況下，隨著系統的運行，操作系統會產生系統日志。應用程序會產生應用程序的訪問日志、錯誤日志、運行日志、網絡日志，我們可以使用 ELK 來進行日志監控。

對于日志監控來說，最見的需求就是收集、存儲、查詢、展示，開源社區正好有相對應的開源項目：logstash（收集）+ elasticsearch（存儲+搜索）+ kibana（展示）。

我們將這三個組合起來的技術稱之為 ELK Stack，所以說 ELK Stack指的是Elasticsearch、Logstash、Kibana 技術棧的結合。

如果收集了日志信息，那么如果部署更新有異常出現，可以立即在 Kibana上看到。

7、 安全監控

雖然 Linux 開源的安全產品不少，比如：四層 Iptables，七層 WEB 防護Nginx+Lua實現的 WAF，最后將相關的日志都收至 ELK Stack，通過圖形化進行不同的攻擊類型展示。但是始終是一件比較耗費時間，并且個人效果并不是很好。這個時候我們可以選擇接入第三方服務廠商。

三方廠商提供全面的漏洞庫，涵蓋服務、后門、數據庫、配置檢測、CGI、SMTP 等多種類型全面檢測主機、Web 應用漏洞自主挖掘和行業共享相結合第一時間更新 0day 漏洞，杜絕最新安全隱患。

8、 API 監控

由于 API 變得越來越重要，很顯然我們也需要這樣的數據來分辨我們提供的 API 是否能夠正常運作。監控API接口 GET、POST、PUT、DELETE、HEAD、OPTIONS 的請求可用性、正確性、響應時間為三大重性能指標。

9、 性能監控

全面監控網頁性能，DNS 響應時間、HTTP 建立連接時間、頁面性能指數、響應時間、可用率、元素大小等。

10、 業務監控

沒有業務指標監控的監控平臺，不是一個完善的監控平臺，通常在我們的監控系統中，必須將我們重要的業務指標進行監控，并設置閾值進行告警通知。

監控報警

故障報警通知的方式有很多種，當然我們最常用的還是短信，郵件。

報警處理

一般報警后我們故障如何處理呢？首先，我們可以通過告警升級機制先自動處理，比如Nginx服務Down了，可以設置告警升級自動啟動Nginx。

但是如果一般業務出現了嚴重故障，我們通常根據故障的級別，故障的業務，來指派不同的運維人員進行處理。

當然不同業務形態、不同架構、不同服務可能采用的方式都不同，這個沒有一個固定的模式套用。

來源：機房動力環境監控系統 http://m.scdprobes.com   本文采集于網絡，如有問題有聯系刪除