基于操作系統命令和插件技術的服務器設備監視和自動建模

胡信超，孔令帥

（積成電子股份有限公司，山東濟南 250010）

服務器設備的實時狀態監視是自動化運維人員保證業務系統正常運行的重要手段。現有的服務器設備監視技術或方法主要有：服務器運行狀態指示燈、各廠家提供的單機監視程序、簡單操作系統命令、SNMP 協議、插件技術等。

針對幾臺或十幾臺服務器設備，簡單地安裝監視程序、查看運行指示燈或通過SNMP 協議進行運行狀態的查詢，可以在自動化運維人員的精力掌握范圍之內，但是隨著不同領域的自動化水平的提高和系統及服務器設備復雜度的增加，僅僅靠上述的幾種方法無法有效提升監視效率[1]。

針對現狀，提出了一種通過操作系統命令和開源插件的方式對不同類型服務器進行狀態監視的方法，同時，為了提高監視效率，采用程序自動化處理的方式對掃描到的新設備進行自動建模，最大程度上減少自動化運維人員的工作量并減少由于人工的參與帶來的信息錄入不準確的現象[2]。

1 常見服務器設備狀態監視方法

1.1 基于服務器運行狀態指示燈的設備監視

每一個成熟的服務器產品都會在服務器上設置各種類型的服務器運行狀態指示燈，主要有：電源指示燈、硬盤指示燈、網絡指示燈等，如果服務器相應組件發生了故障，對應指示燈都會進行狀態或顏色的變化。該方法對服務器運行狀態的監視最為直觀有效，但是帶給自動化運維人員的信息量有限，且需要定時到設備機房查看，不僅無法對某些隱藏的狀態信息進行查閱，也會浪費運維人員的大量時間和精力。

1.2 基于各廠家提供的單機監視程序

互聯網上針對Windows 操作系統有各種類型的單機監視程序，如：魯大師、CPU-Z 等。該類軟件的優點是操作簡單且監視信息全面，但是自動化運維人員無法通過網絡資源統一匯總所有的服務器設備信息，且在Linux 和Unix 上相應的軟件較少，無法達到所有服務器設備運行狀態的集中監視。

1.3 簡單操作命令的服務器設備狀態監視

不同的操作系統都具備各自的狀態運行信息查詢指令，幾乎所有的服務器運行狀態信息都可以通過操作命令[3]的方式進行查詢，且該方式可以通過網絡遠程命令，如：ssh、遠程桌面等方式進行遠程查詢，自動化運維人員不需要走到每個服務器面前進行操作，在一定程度上減少了運維人員的體力勞動。

但是由于現場操作系統類型較多，操作命令種類繁雜，對運維人員知識技能的要求相對較高，且不能在同一設備上同時對所有設備進行監管，導致該方式的工作效率大打折扣[4]。

1.4 基于簡單網絡管理協議(SNMP)的服務器設備狀態監視

SNMP 中文名稱為簡單網絡管理協議，專門設計用于對網絡節點（服務器、工作站、路由器、交換機等）設備管理的一種標準協議。該協議中的每一種設備運行狀態信息都被賦予了一個對象標識符（OID），只要網絡管理（NMS）與每一個SNMP 設備（Agent）能夠在網絡上互通，且通過SNMP 版本和團體字（Community）的驗證，即可通過遠程的方式獲得被監管服務器的實時狀態運行信息，如：CPU 使用率、內存使用率、磁盤使用率、網卡/網口狀態等[5]。

該方法解決了無法一對多的設備運行狀態監管，并且能夠監管的數據類型種類較多。但是該方式需要程序開發人員的支持，每一種不同類型的設備，或同一廠家不同型號的設備對應的OID 都有差異，導致程序開發難度增加，并且后期的系統維護水平要求較高，系統維護復雜度較大，自動化運維人員需要進行專業知識和技能培訓[6]。

同時SNMP 協議無法完成操作系統自身運行狀態信息的獲取，如：CPU 使用率TOP10 的進程信息等，無法對服務器進行全方位的狀態監視[7]。

1.5 基于Hyperic-Sigar插件的服務器設備狀態監視

Hyperic-Sigar 是一個收集系統各項底層信息的工具集，有如下特點:

1）收集信息全面

收集的信息如：CPU、MEM、PROCESS、IOSTAT、NETWORK 等。使用Hyperic-Sigar 完全可以模仿出cpuinfo、meminfo、top、free、ifconfig 等多種Unix 平臺和Windows 平臺的指令。

2）跨平臺

支持的平臺包括:Windows 系列(32 系列、IA64 系列、AMD64 系列)、Linux 系列、freeBsd 系列、HPUnix系 列、Sparc/Sparc64/Sun solaris 系 列、macOs 系 列、AIX 系列等。

3）提供的API 接口全面

Hyperic-Sigar 本身由C 語言開發而成，提供了豐富的API 接口,包括:Java，.NET，PERL，PHP，Python。

2 服務器設備監視及自動建模

簡單使用上述任何一個方法都無法實現自動化運維人員高效、統一、便捷的服務器運行監視，但是通過對操作系統命令和Hyperic-Sigar 等技術的融合，實現被監管服務器的自動化建模及綜合數據的監視，可以在最大限度上減輕自動化運維人員的工作強度和復雜度，實現服務器設備的實時監視。

2.1 服務器模型及實時數據采集

由于Hyperic-Sigar 為第三方插件技術，所以在操作系統命令能夠支持的情況下，盡量減少Hyperic-Sigar 的使用，可以最大限度地提高數據采集服務的穩定性和可操控性。

針對Windows[8]、Linux[9]、Unix[10]三大類操作系統，服務模型及運行信息采集命令如表1 所示。

2.2 采集數據整理

針對不同的操作系統，對應表1 的數據采集和不同的后臺服務處理后，需要統一生成歸一化的可擴展標記語言（XML）[11-12]數據文件，便于數據處理服務的模型分析[13]及實時運行數據的展示。

生成的XML 文件主要為服務器模型及運行信息文件，如圖1 所示，詳細信息包含了主IP、CPU 數量、內存大小、內存使用率、交換區使用率、IO_WAIT占比、磁盤容量、磁盤整體使用率、磁盤整體讀速度、磁盤整體寫速度、進程數量、網絡連接數。

表1 服務器模型及運行信息采集

服務器磁盤模型[14]及運行信息主要由磁盤分區、磁盤分區名字、每個分區磁盤的總容量、每個磁盤使用率、每個磁盤的讀速率、每個磁盤寫速率組成，具體內容如圖2 所示。

服務器網卡模型及運行信息主要由網卡IP、網卡名字、每個網卡的MAC 信息、每個網卡的最大傳輸單元、每個網卡接收包的數量、每個網卡收到出錯包的數量、每個網卡發送包的數量、每個網卡發送出錯包數量、每個網卡發生沖突次數、每個網卡傳輸隊列長度等，具體內容如圖3 所示。

服務器進程Top10 信息主要展示占用CPU 使用率前十的進程信息，主要有進程的名字、CPU 使用率、內存信息、進程號、啟動時間，具體內容如圖4所示。

2.3 數據流程處理

每一個安裝完成數據采集代理的服務器，都會定時自動將采集到的模型信息和軟硬件運行信息通過socket(ActiveMQ)[15-16]的方式發送到該系統的綜合數據處理服務器。

圖1 服務器模型及運行信息文件

圖2 磁盤模型及運行信息文件

圖3 網卡模型及運行信息文件

綜合數據處理服務器對所有收集到的設備及操作系統模型及狀態運行信息進行統一分析處理。數據文件分析后，如果是新的模型文件，系統將針對具體情況創建服務器模型、磁盤模型、網卡模型和進程信息模型，具體數據流程詳見圖5。

如有新的服務器需要加入到監視隊列，僅需要自動化運維人員將數據采集Agent 部署到該服務器即可，Agent 將自動采集本地服務器模型及運行狀態信息給綜合數據處理服務器，可以最大限度地簡化自動化運維人員的工作流程。

圖4 CPU Top10進程信息文件

圖5 數據流程圖

3 結束語

根據自動化運維人員針對現場繁雜、數量眾多的服務器設備監視進行了探討和梳理，通過試驗驗證了該方案不僅可以減輕自動化運維人員的工作量，同時可以較全面地對所有常見類型的服務器進行實時監視，為眾多的自動化系統安全穩定運行打下了堅實的基礎。