本文選自 《交易技術(shù)前沿》總第三十六期文章(2019年9月)

陳靖宇

深圳證券交易所 系統(tǒng)運行部

Email: jingyuchen@szse.cn

摘要：為了應(yīng)對基礎(chǔ)設(shè)施規(guī)模不斷上升，數(shù)據(jù)中心兩地三中心帶來的運維挑戰(zhàn)，深交所結(jié)合現(xiàn)有基礎(chǔ)設(shè)施現(xiàn)狀，以通用性、靈活性為目標(biāo)，實現(xiàn)對基礎(chǔ)設(shè)施的自動化監(jiān)控和運維。本文從基礎(chǔ)設(shè)施運行的實際情況出發(fā)，借助IPMI，SNMPwalk，日志等多種方式采集數(shù)據(jù)，實現(xiàn)了基礎(chǔ)設(shè)施的運維監(jiān)控以及可視化。目前，系統(tǒng)已經(jīng)初步上線，運行穩(wěn)定，為后續(xù)以數(shù)據(jù)為基礎(chǔ)的智能化基礎(chǔ)設(shè)施運維打下堅實的基礎(chǔ)

關(guān)鍵詞：基礎(chǔ)設(shè)施、硬件監(jiān)控、數(shù)據(jù)可視化

一、背景

隨著云計算，大數(shù)據(jù)的大量運用，基礎(chǔ)設(shè)施的規(guī)模不斷擴(kuò)大，硬件故障的發(fā)生頻率逐漸上升，故障的響應(yīng)的時效性，準(zhǔn)確性以及故障的復(fù)雜性給基礎(chǔ)設(shè)施運維提出了更高的要求。為了更好的運維基礎(chǔ)設(shè)施，高效的硬件監(jiān)控必不可少，相比于應(yīng)用、中間件、操作系統(tǒng)的監(jiān)控，硬件監(jiān)控存在信息量少，采集途徑有限，數(shù)據(jù)不標(biāo)準(zhǔn)的特點。因此，搭建統(tǒng)一的硬件監(jiān)控平臺顯得尤為重要。 目前，基礎(chǔ)設(shè)施硬件監(jiān)控有以下三個方面問題：

1、 基礎(chǔ)設(shè)施尤其是服務(wù)器的品牌眾多，難以有標(biāo)準(zhǔn)統(tǒng)一的監(jiān)控指標(biāo)。由于業(yè)務(wù)系統(tǒng)的不斷更新和上線，服務(wù)器的采購需求變更等原因，現(xiàn)有服務(wù)器的品牌不統(tǒng)一，同品牌服務(wù)器型號不相同，BMC管理系統(tǒng)版本不一致，導(dǎo)致運維的成本上升，復(fù)雜性提高。

2、 指標(biāo)的種類繁多，卻難以準(zhǔn)確的反映基礎(chǔ)設(shè)施的狀態(tài)。由于基礎(chǔ)設(shè)施的品牌、型號不同，設(shè)備的傳感器數(shù)量，指標(biāo)的名稱、類型多樣，同時后續(xù)新增的設(shè)備同樣會有不同的指標(biāo)，對于監(jiān)控告警的設(shè)計要求兼顧數(shù)據(jù)完備性和靈活性的要求。

3、 基礎(chǔ)設(shè)施的關(guān)鍵部件故障需要提前預(yù)警。比如服務(wù)器的硬盤雖然可以通過RAID實現(xiàn)高可用，但是在服務(wù)器數(shù)量上升到一定數(shù)量級后，硬盤的頻繁不定期更換會使得運維人員疲于應(yīng)對。理想的情況是提前預(yù)測故障，在特定的操作窗口下，預(yù)先更換備件以達(dá)到有備無患的目的。

二、IAAS基礎(chǔ)設(shè)施監(jiān)控方案選型

物理服務(wù)器，交換機(jī)，F5，防火墻是最常見的4類基礎(chǔ)設(shè)施，數(shù)據(jù)的采集方式有日志、SNMPwalk、IPMI，SNMPTrap等方式。具體的監(jiān)控方式需要針對不同的設(shè)備類型和管理端的功能以及運維的需求進(jìn)行選擇。

日志是相對通用的采集數(shù)據(jù)源，基礎(chǔ)設(shè)施都有相應(yīng)的日志系統(tǒng)，提供各個維度的日志，由于日志屬于相對滯后的數(shù)據(jù)信息，在系統(tǒng)發(fā)生事件后才會在日志中寫入，因此往往作為排查故障的用途，而且交換機(jī)，F5，防火墻的日志生產(chǎn)數(shù)據(jù)多，容量大，難以做到實時采集分析告警，有效的故障信息密度很低，不利于搭建基于日志的故障監(jiān)控告警系統(tǒng)。

SNMPwalk通過主動發(fā)送設(shè)備定制的OID來獲取數(shù)據(jù)，可以實現(xiàn)高頻次的數(shù)據(jù)采集，時效性較好但數(shù)據(jù)的可讀性較差，需要進(jìn)行數(shù)據(jù)的處理整合，并豐富基本信息來作為監(jiān)控的指標(biāo)。

IPMI是物理服務(wù)器BMC管理端實現(xiàn)的基礎(chǔ)協(xié)議，通過該方式可以實現(xiàn)對服務(wù)器狀態(tài)的完整監(jiān)控，取得包括傳感器狀態(tài)，日志，固件信息，網(wǎng)絡(luò)配置，用戶管理等內(nèi)容，并且不受服務(wù)器類型，種類，固件版本的限制，適配性較好。雖然不同的服務(wù)器傳感器數(shù)量有差異，但總體上的關(guān)鍵指標(biāo)都有采集。

傳統(tǒng)的監(jiān)控方式是通過在基礎(chǔ)設(shè)施的管理端配置SNMPTrap發(fā)包的告警對接到告警平臺實現(xiàn)硬件的故障感知和響應(yīng)。這種方式存在以下缺點：

SNMPTrap包的內(nèi)容難以解析，可讀性差而且發(fā)包的機(jī)制難以準(zhǔn)確判斷，發(fā)送無效告警的幾率高。比如HP服務(wù)器存在當(dāng)固件版本與ILO版本不適配時，SNMP將會頻繁發(fā)包，但是不影響業(yè)務(wù)使用，只能通過屏蔽OID的手段忽略告警。

采集的數(shù)據(jù)量較少，被動依靠SNMP發(fā)包難以實現(xiàn)靈活主動的監(jiān)控管理。SNMPTrap的機(jī)制是通過BMC管理系統(tǒng)判斷系統(tǒng)是否存在異常，之后發(fā)送SNMPTrap包實現(xiàn)告警功能，對于運維人員來說該機(jī)制實際上是個黑盒，很多包的OID的含義難以查詢，不利于快速響應(yīng)故障。

通過分析上述數(shù)據(jù)采集的方式，我們針對不同的基礎(chǔ)設(shè)施設(shè)計了相應(yīng)的數(shù)據(jù)采集方案:

1、物理服務(wù)器的BMC日志數(shù)據(jù)量小且準(zhǔn)確，有著比較完備的BMC管理端，故障信息密度高，適合基于IPMI的方式進(jìn)行硬件監(jiān)控，IPMI采集傳感器和BMC日志來進(jìn)行硬件監(jiān)控。

2、交換機(jī)，F5，防火墻日志數(shù)據(jù)量大難以提取有效信息，往往作為故障發(fā)生后的定位、自查的作用，因此選擇SNMPwalk 的方式采集指標(biāo)并進(jìn)行數(shù)據(jù)的整合來實現(xiàn)監(jiān)控告警，而日志采集后作為故障定位的備查數(shù)據(jù)源，利用日志數(shù)據(jù)可讀性強(qiáng)的優(yōu)點，借助告警時間準(zhǔn)確查詢小范圍時間內(nèi)的日志來豐富告警信息。

3、針對基礎(chǔ)設(shè)施沒有提供接口的數(shù)據(jù)采集通過expect腳本登陸采集的方式獲取數(shù)據(jù)。比如交換機(jī)vlan劃分，端口映射等數(shù)據(jù)。

三、IAAS基礎(chǔ)設(shè)施監(jiān)控方案實現(xiàn)

3.1 總體架構(gòu)設(shè)計

圖1 基礎(chǔ)設(shè)施監(jiān)控架構(gòu)圖

整體的監(jiān)控框架分為IAAS層，采集層，存儲層和應(yīng)用層。如圖1所示，IAAS層包含服務(wù)器、交換機(jī)、F5、防火墻四類基礎(chǔ)設(shè)施，采集層實現(xiàn)IPMI、 SNMPwalk、日志，ssh登陸采集等數(shù)據(jù)收集端。

IPMI、SNMPwalk、日志等方式有其先天缺點，由于其采集效率依賴基礎(chǔ)設(shè)施管理端的性能，使得在基礎(chǔ)設(shè)施規(guī)模日益增長的場景下，順序采集信息的效率過低，因此我們設(shè)計通過線程池并發(fā)的方式來實現(xiàn)分鐘級的硬件監(jiān)控。

我們在存儲層針對不同的數(shù)據(jù)類型進(jìn)行分類保存，指標(biāo)類型數(shù)據(jù)經(jīng)過標(biāo)準(zhǔn)化后存入時序數(shù)據(jù)庫ClickHouse，日志類文本型數(shù)據(jù)存入ElasticSearch數(shù)據(jù)庫，基礎(chǔ)設(shè)施標(biāo)準(zhǔn)靜態(tài)配置數(shù)據(jù)存入mysql數(shù)據(jù)庫。最后在應(yīng)用層實現(xiàn)標(biāo)準(zhǔn)數(shù)據(jù)的展示、指標(biāo)數(shù)據(jù)及基線計算、日志數(shù)據(jù)分析等功能。指標(biāo)的采集和數(shù)據(jù)標(biāo)準(zhǔn)化和數(shù)據(jù)可視化是本文的重點，后續(xù)將就指標(biāo)類型數(shù)據(jù)處理，日志數(shù)據(jù)處理以及數(shù)據(jù)可視化三方面介紹基礎(chǔ)設(shè)施監(jiān)控設(shè)計方案。

3.2 指標(biāo)數(shù)據(jù)采集

服務(wù)器方面主要包含HP、H3C、Inspur、Dell等品牌，基于IPMI協(xié)議通過lanplus接口獲取服務(wù)器的傳感器和日志信息。雖然不同品牌的服務(wù)器的傳感器數(shù)量差異，導(dǎo)致采集的數(shù)據(jù)粒度不同，但是采集的IPMI指令是通用的，我們將數(shù)據(jù)進(jìn)行分類整合為功耗數(shù)據(jù)，風(fēng)扇轉(zhuǎn)速數(shù)據(jù)，服務(wù)器狀態(tài)，溫度數(shù)據(jù)，從而實現(xiàn)對不同品牌服務(wù)器的指標(biāo)進(jìn)行標(biāo)準(zhǔn)化輸出。

首先，由于不同服務(wù)器的傳感器指標(biāo)各不相同，我們采用借助輸出數(shù)據(jù)的單位字段進(jìn)行分類過濾。比如watts這類單位屬于功耗數(shù)據(jù)，RPM這類單位屬于風(fēng)扇轉(zhuǎn)速數(shù)據(jù)，degree這類單位屬于溫度數(shù)據(jù)，服務(wù)器狀態(tài)等數(shù)據(jù)統(tǒng)一指標(biāo)名，然后將各種指標(biāo)名打上類型標(biāo)簽存入ClickHouse。

其次，在應(yīng)用層我們借助Grafana按類型查詢各類型指標(biāo)進(jìn)行聚合查詢實現(xiàn)對各類指標(biāo)的展示分析。比如各類服務(wù)器的有1U，2U，4U的，所包含的的風(fēng)扇數(shù)量不同，通過聚合查詢?nèi)【祵崿F(xiàn)對數(shù)據(jù)的整合。

交換機(jī)，F5，防火墻指標(biāo)通過SNMP協(xié)議獲取，該類設(shè)備廠商能夠提供完整的OID列表來收集數(shù)據(jù)。針對系統(tǒng)狀態(tài)數(shù)據(jù)，性能數(shù)據(jù)，固件數(shù)據(jù)分類存入ClickHouse和Mysql數(shù)據(jù)庫。交換機(jī)等網(wǎng)絡(luò)設(shè)備日志通過syslog發(fā)送到匯聚節(jié)點。需要關(guān)注的是SNMPwalk對交換機(jī)進(jìn)行數(shù)據(jù)采集的頻率，過于頻繁的采集指標(biāo)會影響交換機(jī)的性能，要在效率和數(shù)據(jù)之間做出平衡.

上述方式能夠采集大部分的指標(biāo)類型數(shù)據(jù)，而部分設(shè)備的標(biāo)準(zhǔn)信息無法實現(xiàn)OID或其他的獲取方式，我們通過腳本ssh到目標(biāo)設(shè)備實現(xiàn)登陸采集。

圖2 服務(wù)器指標(biāo)日志采集流程

3.3. 基礎(chǔ)設(shè)施日志數(shù)據(jù)采集

日志數(shù)據(jù)分為網(wǎng)絡(luò)設(shè)備日志和服務(wù)器帶外日志。 我們通過IPMI指令采集服務(wù)器BMC帶外日志到匯聚節(jié)點后，進(jìn)行日志數(shù)據(jù)的處理與豐富，為日志信息豐富主機(jī)，IP等信息統(tǒng)一寫入文件由flume采集通過kafka保存到ElasticSearch。因為BMC帶外日志有其特殊性，正常的服務(wù)器設(shè)備是不會產(chǎn)生BMC帶外日志的且日志內(nèi)容十分標(biāo)準(zhǔn)，所以我們在BMC日志入庫時即對其進(jìn)行告警。

網(wǎng)絡(luò)設(shè)備日志通過配置syslog服務(wù)，將設(shè)備日志轉(zhuǎn)發(fā)到flume匯聚節(jié)點指定端口后sink到ElasticSearch。期間對日志進(jìn)行簡單的解析，比如采集時間，入庫時間，日志內(nèi)容等字段進(jìn)行分類。

3.4 數(shù)據(jù)應(yīng)用場景

我們在本節(jié)主要介紹兩個在基礎(chǔ)設(shè)施運維中數(shù)據(jù)的應(yīng)用場景：交換機(jī)到服務(wù)器端口映射關(guān)系圖，服務(wù)器硬盤配置管理與故障預(yù)測。

交換機(jī)內(nèi)部系統(tǒng)使用的是閹割版本的定制化Linux系統(tǒng)，如圖3所示，我們借助expect腳本建立從交換機(jī)獲取到交換機(jī)物理端口描述→物理端口→邏輯端口→mac地址的映射關(guān)系，通過CMDB 獲取到服務(wù)器對應(yīng)網(wǎng)卡與mac地址的映射關(guān)系。如果交換機(jī)有做ae這類端口綁定，需要再采集ae與邏輯端口的映射管理。

圖3 服務(wù)器交換機(jī)拓?fù)潢P(guān)系采集流程

服務(wù)器的硬盤是日常運維過程中，出現(xiàn)問題概率較高的設(shè)備配件，目前普遍采用SAS接口的硬盤，使得以往通過采集S.M.A.R.T信息來進(jìn)行故障預(yù)測的方案不可行。我們選擇通過RAID卡廠商提供的命令行工具采集服務(wù)器RAID信息以及RAID與Slot的映射管理建立服務(wù)器操作系統(tǒng)邏輯磁盤與硬盤的對應(yīng)關(guān)系為硬盤故障定位提供數(shù)據(jù)支持。并采集各個slot的硬盤錯誤計數(shù)建立監(jiān)控指標(biāo)，監(jiān)測磁盤運行狀態(tài)。

然而僅僅依靠硬盤的錯誤計數(shù)來判斷硬盤的狀態(tài)是不準(zhǔn)確的。因此我們借助定期對系統(tǒng)內(nèi)的數(shù)據(jù)盤進(jìn)行性能測試來建立性能指標(biāo)基線。綜合硬盤性能和介質(zhì)錯誤計數(shù)來判斷硬盤故障。

3.5 數(shù)據(jù)可視化

數(shù)據(jù)可視化是基礎(chǔ)設(shè)施硬件監(jiān)控的重要組成部分，通過對指標(biāo)數(shù)據(jù)的可視化可以直觀的看到基礎(chǔ)設(shè)施在不同周期，不同維度的運行狀態(tài)，借此運維人員可以更好的響應(yīng)故障事件。

在本方案中我們采用Grafana來實現(xiàn)數(shù)據(jù)可視化，如圖4所示在界面中集中展示服務(wù)器的運行狀態(tài)、風(fēng)扇，溫度，功耗以及硬盤等設(shè)備的指標(biāo)。

圖4 服務(wù)器硬件監(jiān)控視圖

其中，服務(wù)器狀態(tài)，傳感器數(shù)量以及硬盤的介質(zhì)錯誤這類指標(biāo)是我們比較關(guān)注的。通過服務(wù)器狀態(tài)指標(biāo)可以反映服務(wù)器的通電狀態(tài)，傳感器指標(biāo)可以反應(yīng)服務(wù)器自監(jiān)控是否正常而硬盤的介質(zhì)錯誤可以看出硬盤的狀態(tài)，過多的介質(zhì)錯誤將導(dǎo)致硬盤的讀寫效率降低，影響業(yè)務(wù)運行。

四、總結(jié)

基礎(chǔ)設(shè)施的運維監(jiān)控在上線以來，填補了運維監(jiān)控的漏洞，解決了基礎(chǔ)設(shè)施運維的問題，提高了運維的效率。尤其是探索了基礎(chǔ)設(shè)施的數(shù)據(jù)應(yīng)用場景，進(jìn)一步提升了運維的穩(wěn)定性和效率。未來，隨著業(yè)務(wù)的不斷拓展需要，會有更多的不同類型的基礎(chǔ)設(shè)施需要加入到監(jiān)控中來，采集的數(shù)據(jù)規(guī)模也會越來越大，需要加強(qiáng)數(shù)據(jù)的治理，拓展數(shù)據(jù)的應(yīng)用場景，為全鏈路監(jiān)控，告警豐富，故障預(yù)測等場景提供數(shù)據(jù)支持。

在后續(xù)的工作中，我們將著重提高數(shù)據(jù)的利用效率，對業(yè)務(wù)、系統(tǒng)、基礎(chǔ)設(shè)施等多層次，多維度的數(shù)據(jù)進(jìn)行整合，向智能運維告警，故障根因分析等方面努力，進(jìn)一步提升自己在運維開發(fā)，安全運行的能力。

總結(jié)

以上是生活随笔為你收集整理的服务器定期监控数据_基础设施硬件监控探索与实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。