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

陳靖宇

深圳證券交易所 系統運行部

Email: jingyuchen@szse.cn

摘要：為了應對基礎設施規模不斷上升，數據中心兩地三中心帶來的運維挑戰，深交所結合現有基礎設施現狀，以通用性、靈活性為目標，實現對基礎設施的自動化監控和運維。本文從基礎設施運行的實際情況出發，借助IPMI，SNMPwalk，日志等多種方式采集數據，實現了基礎設施的運維監控以及可視化。目前，系統已經初步上線，運行穩定，為后續以數據為基礎的智能化基礎設施運維打下堅實的基礎

關鍵詞：基礎設施、硬件監控、數據可視化

一、背景

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

1、 基礎設施尤其是服務器的品牌眾多，難以有標準統一的監控指標。由于業務系統的不斷更新和上線，服務器的采購需求變更等原因，現有服務器的品牌不統一，同品牌服務器型號不相同，BMC管理系統版本不一致，導致運維的成本上升，復雜性提高。

2、 指標的種類繁多，卻難以準確的反映基礎設施的狀態。由于基礎設施的品牌、型號不同，設備的傳感器數量，指標的名稱、類型多樣，同時后續新增的設備同樣會有不同的指標，對于監控告警的設計要求兼顧數據完備性和靈活性的要求。

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

二、IAAS基礎設施監控方案選型

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

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

SNMPwalk通過主動發送設備定制的OID來獲取數據，可以實現高頻次的數據采集，時效性較好但數據的可讀性較差，需要進行數據的處理整合，并豐富基本信息來作為監控的指標。

IPMI是物理服務器BMC管理端實現的基礎協議，通過該方式可以實現對服務器狀態的完整監控，取得包括傳感器狀態，日志，固件信息，網絡配置，用戶管理等內容，并且不受服務器類型，種類，固件版本的限制，適配性較好。雖然不同的服務器傳感器數量有差異，但總體上的關鍵指標都有采集。

傳統的監控方式是通過在基礎設施的管理端配置SNMPTrap發包的告警對接到告警平臺實現硬件的故障感知和響應。這種方式存在以下缺點：

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

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

通過分析上述數據采集的方式，我們針對不同的基礎設施設計了相應的數據采集方案:

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

2、交換機，F5，防火墻日志數據量大難以提取有效信息，往往作為故障發生后的定位、自查的作用，因此選擇SNMPwalk 的方式采集指標并進行數據的整合來實現監控告警，而日志采集后作為故障定位的備查數據源，利用日志數據可讀性強的優點，借助告警時間準確查詢小范圍時間內的日志來豐富告警信息。

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

三、IAAS基礎設施監控方案實現

3.1 總體架構設計

圖1 基礎設施監控架構圖

整體的監控框架分為IAAS層，采集層，存儲層和應用層。如圖1所示，IAAS層包含服務器、交換機、F5、防火墻四類基礎設施，采集層實現IPMI、 SNMPwalk、日志，ssh登陸采集等數據收集端。

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

我們在存儲層針對不同的數據類型進行分類保存，指標類型數據經過標準化后存入時序數據庫ClickHouse，日志類文本型數據存入ElasticSearch數據庫，基礎設施標準靜態配置數據存入mysql數據庫。最后在應用層實現標準數據的展示、指標數據及基線計算、日志數據分析等功能。指標的采集和數據標準化和數據可視化是本文的重點，后續將就指標類型數據處理，日志數據處理以及數據可視化三方面介紹基礎設施監控設計方案。

3.2 指標數據采集

服務器方面主要包含HP、H3C、Inspur、Dell等品牌，基于IPMI協議通過lanplus接口獲取服務器的傳感器和日志信息。雖然不同品牌的服務器的傳感器數量差異，導致采集的數據粒度不同，但是采集的IPMI指令是通用的，我們將數據進行分類整合為功耗數據，風扇轉速數據，服務器狀態，溫度數據，從而實現對不同品牌服務器的指標進行標準化輸出。

首先，由于不同服務器的傳感器指標各不相同，我們采用借助輸出數據的單位字段進行分類過濾。比如watts這類單位屬于功耗數據，RPM這類單位屬于風扇轉速數據，degree這類單位屬于溫度數據，服務器狀態等數據統一指標名，然后將各種指標名打上類型標簽存入ClickHouse。

其次，在應用層我們借助Grafana按類型查詢各類型指標進行聚合查詢實現對各類指標的展示分析。比如各類服務器的有1U，2U，4U的，所包含的的風扇數量不同，通過聚合查詢取均值實現對數據的整合。

交換機，F5，防火墻指標通過SNMP協議獲取，該類設備廠商能夠提供完整的OID列表來收集數據。針對系統狀態數據，性能數據，固件數據分類存入ClickHouse和Mysql數據庫。交換機等網絡設備日志通過syslog發送到匯聚節點。需要關注的是SNMPwalk對交換機進行數據采集的頻率，過于頻繁的采集指標會影響交換機的性能，要在效率和數據之間做出平衡.

上述方式能夠采集大部分的指標類型數據，而部分設備的標準信息無法實現OID或其他的獲取方式，我們通過腳本ssh到目標設備實現登陸采集。

圖2 服務器指標日志采集流程

3.3. 基礎設施日志數據采集

日志數據分為網絡設備日志和服務器帶外日志。 我們通過IPMI指令采集服務器BMC帶外日志到匯聚節點后，進行日志數據的處理與豐富，為日志信息豐富主機，IP等信息統一寫入文件由flume采集通過kafka保存到ElasticSearch。因為BMC帶外日志有其特殊性，正常的服務器設備是不會產生BMC帶外日志的且日志內容十分標準，所以我們在BMC日志入庫時即對其進行告警。

網絡設備日志通過配置syslog服務，將設備日志轉發到flume匯聚節點指定端口后sink到ElasticSearch。期間對日志進行簡單的解析，比如采集時間，入庫時間，日志內容等字段進行分類。

3.4 數據應用場景

我們在本節主要介紹兩個在基礎設施運維中數據的應用場景：交換機到服務器端口映射關系圖，服務器硬盤配置管理與故障預測。

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

圖3 服務器交換機拓撲關系采集流程

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

然而僅僅依靠硬盤的錯誤計數來判斷硬盤的狀態是不準確的。因此我們借助定期對系統內的數據盤進行性能測試來建立性能指標基線。綜合硬盤性能和介質錯誤計數來判斷硬盤故障。

3.5 數據可視化

數據可視化是基礎設施硬件監控的重要組成部分，通過對指標數據的可視化可以直觀的看到基礎設施在不同周期，不同維度的運行狀態，借此運維人員可以更好的響應故障事件。

在本方案中我們采用Grafana來實現數據可視化，如圖4所示在界面中集中展示服務器的運行狀態、風扇，溫度，功耗以及硬盤等設備的指標。

圖4 服務器硬件監控視圖

其中，服務器狀態，傳感器數量以及硬盤的介質錯誤這類指標是我們比較關注的。通過服務器狀態指標可以反映服務器的通電狀態，傳感器指標可以反應服務器自監控是否正常而硬盤的介質錯誤可以看出硬盤的狀態，過多的介質錯誤將導致硬盤的讀寫效率降低，影響業務運行。

四、總結

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

在后續的工作中，我們將著重提高數據的利用效率，對業務、系統、基礎設施等多層次，多維度的數據進行整合，向智能運維告警，故障根因分析等方面努力，進一步提升自己在運維開發，安全運行的能力。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。