基于操作系統(tǒng)命令和插件技術(shù)的服務(wù)器設(shè)備監(jiān)視和自動建模

胡信超，孔令帥

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

服務(wù)器設(shè)備的實時狀態(tài)監(jiān)視是自動化運維人員保證業(yè)務(wù)系統(tǒng)正常運行的重要手段。現(xiàn)有的服務(wù)器設(shè)備監(jiān)視技術(shù)或方法主要有：服務(wù)器運行狀態(tài)指示燈、各廠家提供的單機監(jiān)視程序、簡單操作系統(tǒng)命令、SNMP 協(xié)議、插件技術(shù)等。

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

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

1 常見服務(wù)器設(shè)備狀態(tài)監(jiān)視方法

1.1 基于服務(wù)器運行狀態(tài)指示燈的設(shè)備監(jiān)視

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

1.2 基于各廠家提供的單機監(jiān)視程序

互聯(lián)網(wǎng)上針對Windows 操作系統(tǒng)有各種類型的單機監(jiān)視程序，如：魯大師、CPU-Z 等。該類軟件的優(yōu)點是操作簡單且監(jiān)視信息全面，但是自動化運維人員無法通過網(wǎng)絡(luò)資源統(tǒng)一匯總所有的服務(wù)器設(shè)備信息，且在Linux 和Unix 上相應(yīng)的軟件較少，無法達(dá)到所有服務(wù)器設(shè)備運行狀態(tài)的集中監(jiān)視。

1.3 簡單操作命令的服務(wù)器設(shè)備狀態(tài)監(jiān)視

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

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

1.4 基于簡單網(wǎng)絡(luò)管理協(xié)議(SNMP)的服務(wù)器設(shè)備狀態(tài)監(jiān)視

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

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

同時SNMP 協(xié)議無法完成操作系統(tǒng)自身運行狀態(tài)信息的獲取，如：CPU 使用率TOP10 的進程信息等，無法對服務(wù)器進行全方位的狀態(tài)監(jiān)視[7]。

1.5 基于Hyperic-Sigar插件的服務(wù)器設(shè)備狀態(tài)監(jiān)視

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

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 語言開發(fā)而成，提供了豐富的API 接口,包括:Java，.NET，PERL，PHP，Python。

2 服務(wù)器設(shè)備監(jiān)視及自動建模

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

2.1 服務(wù)器模型及實時數(shù)據(jù)采集

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

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

2.2 采集數(shù)據(jù)整理

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

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

表1 服務(wù)器模型及運行信息采集

服務(wù)器磁盤模型[14]及運行信息主要由磁盤分區(qū)、磁盤分區(qū)名字、每個分區(qū)磁盤的總?cè)萘俊⒚總€磁盤使用率、每個磁盤的讀速率、每個磁盤寫速率組成，具體內(nèi)容如圖2 所示。

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

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

2.3 數(shù)據(jù)流程處理

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

圖1 服務(wù)器模型及運行信息文件

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

圖3 網(wǎng)卡模型及運行信息文件

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

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

圖4 CPU Top10進程信息文件

圖5 數(shù)據(jù)流程圖

3 結(jié)束語

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