鐵路數據中心智能運維管理系統初步研究

趙 天，劉 宇，何欣玲，黃思煒

（中國鐵路信息科技集團有限公司，北京 100844）

隨著鐵路信息化的不斷發展，鐵路數據中心運維工作日趨復雜。當前，云計算已逐漸成為鐵路信息系統的主流技術架構，鐵路數據中心云化進程不斷加快，其運行與維護（簡稱：運維）環境的復雜化和異構特征越發突出，面對著更加多樣化的業務需求，鐵路數據中心的日常運維工作不得不投入更多的人力和時間，成本越來越高。

中國鐵路信息科技集團有限公司發布的《十四五戰略發展規劃》中指出，鐵路數據中心將形成兩地三中心架構，構建統一運維管理，形成彈性分配資源的技術與服務管理體系[1]。兩地三中心即同城雙活中心、主數據中心和異地數據中心，且遠期鐵路數據中心將朝著多地多中心方向發展。

為應對目前鐵路數據中心運維工作面對的壓力和挑戰，適應鐵路信息化未來發展要求，鐵路數據中心需要采用更為高效的運維模式，實現異地多中心的統一運維管理，能夠及時、準確地掌控各鐵路數據中心資源及業務應用系統的運行情況，實現鐵路數據中心運維人力資源的統一調配，保障鐵路信息系統安全、穩定地持續運行。

近年來，智能運維在信息技術領域受到廣泛關注，隨著大數據分析、云應用性能管理（APM，Application Performance Management）、智能異常檢測、機器學習等技術的興起和逐漸成熟，數據中心運維逐漸轉向數字化和智能化[2]，由傳統模式向智能運維管理（AIOps，Artificial Intelligence for IT Operations）演進。

本文結合鐵路數據中心云化趨勢和多地多中心發展要求，為實現全路鐵路數據中心的集中運維管理，提出鐵路數據中心智能運維管理系統方案，重點對運維數據采集、運維監控指標體系及運維數據存儲展開研究。

1 鐵路數據中心智能運維目標

（1）實現全路鐵路數據中心集中運維管理：建立鐵路運維管理中心，可采集和匯總異地多鐵路數據中心的運維數據（日志、監控信息、應用信息等），通過大數據處理和智能分析，全面掌控各鐵路數據中心整體運行狀況，包括網絡設備、物理服務器、存儲設備、虛擬服務器、操作系統、數據庫、應用系統等運行狀況。

（2）統一鐵路數據中心運維管理服務水平：規范各類監控對象的監控數據采集，建立標準的運維管理指標體系，以統一各鐵路數據中心運維管理服務水平。

（3）提高鐵路數據中心運維效率：通過海量運維數據有效采集、存儲、自動處理和智能分析，提供異常檢測、故障分析、運維輔助決策等運維應用，支持階梯式運維團隊協同工作，確保鐵路數據中心安全穩定運行和資源配置持續優化。

2 鐵路數據中心智能運維管理系統方案

2.1 總體架構

構建鐵路數據中心智能運維管理系統，實現對多個異地鐵路數據中心的統一運維管理，兼容跨區域復雜網絡，從各鐵路數據中心采集各類監控對象的運維數據，并匯集到運維管理中心。

鐵路數據中心運維管理系統包括數據采集層、數據存儲層和業務服務層，總體架構如圖1 所示。

圖1 鐵路數據中心運維管理系統總體架構示意

（1）監控對象層：涉及各鐵路數據中心的各類監控對象實體，包括供電、空調、溫濕度傳感器、UPS 等基礎環境設施，PC 服務器、存儲、以及路由器、交換機等IT 硬件設備，云平臺服務、虛擬機、操作系統、數據庫、中間件等系統軟件，以及各業務應用系統等。

（2）數據采集層：包括代理和采集控制平臺；代理從鐵路數據中心收集各類監控對象的運行狀態數據（即原始的運維監控數據），按照統一口徑進行統計分析，生成運維監控指標數據，與原始的運維監控數據一起上傳給采集控制平臺；采集控制平臺負責接收代理上傳的數據，同時對代理進行調度管理。

（3）數據存儲層：存儲從監控對象采集得到的原始運維數據，以及經分析處理后的運維監控指標數據。

（4）業務服務層：完成運維指標數據的關聯分析和智能分析，為運維管理中心階梯式運維團隊（包括運維管理人員及一線、二線、三線的運維人員）提供運維數據可視化展示、統計報表、自動告警通知，為異常檢測、故障分析、運維輔助決策等運維業務提供強有力支持，建立起7x24 h 的應急響應機制。

2.2 數據采集層

數據采集層主要由部署在鐵路數據中心一側的代理和運維管理中心一側的采集控制平臺構成。

（1）代理是部署在各個鐵路數據中心不同網絡區域內的各類專用程序，可采用拉和推2 種的工作模式，收集各類監控對象的運維數據。代理程序還會對運維數據進行預處理[3]，剔除重復數據、空值數據和異常數據等，然后按照統一口徑進行統計分析，生成運維監控指標數據，將原始的運維數據與監控指標數據一起上傳至采集控制平臺。

（2）采集控制平臺是鐵路數據中心運維管理系統的核心，負責接收代理上傳的數據，并對代理進行調度管理，控制代理采集和上報數據的周期；設置有插件庫，可按需向代理下發插件，完成代理程序的升級更新。采集控制平臺主要由數據服務網關、數據緩存隊列和大數據處理組件3 個組件來完成。

數據服務網關由LVS+Keepalive+Nginx 組成；其中，LVS 負責接入代理數據流，可提供4 層高效負載均衡；Keepalive 保障LVS 具有高可用性，避免LVS 出現單點故障；Nginx 負責將數據均衡傳輸至數據緩存隊列，可支持7 層應用數據傳輸負載均衡。

數據緩存隊列采用Kafka 實現，將接收的運維監控數據緩存起來，并通知采集控制平臺盡快將其存入數據庫。Kafka 是一個分布式、多分區、多訂閱者模式的日志和消息系統，支持冗余備份，具有處理速度快、高吞吐、支持分布式部署等特點。

大數據處理組件Spark 用于海量運維監控數據的大數據處理。通過流式計算，采用ETL 技術對運維監控指標數據進行清理、過濾、轉換定義，實現數據標準化、規范化。Spark 可以采用圖形化和表格的形式進行快捷配置，對運維監控指標數據進行解析、提取、清洗、替換、分類、加注標簽、添加信息項、歸并等處理，并將海量運維數據快速存入數據庫中。

2.3 數據存儲層

在云計算環境下，鐵路數據中心每年會產生高達數以百TB 的運維數據，傳統關系型數據庫難以滿足其存儲要求。運維監控數據存儲需要考慮海量數據的寫入性能[4]、查詢效率、按時聚合等數據處理要求[5]；此外，鑒于不同類型監控對象間關聯關系是數據分析的關鍵[6]，數據存儲還應為關聯分析提供高效的數據訪問支持。

數據存儲層使用ElasticSearch、 MongoDB、MySQL、Redis 等多種類型的數據庫，滿足異構的海量原始運維數據的不同存儲要求；采用集群部署方式，滿足數據量快速增加時橫向擴容的需求。

2.4 業務服務層

提供統一運維門戶，采用微服務技術架構，實現數據分析、報表和可視化功能模塊的組件化和服務化，每個服務可獨立開發、部署和發布，具有較好的可擴展性，便于系統維護與升級。

3 運維數據采集需求及運維管理指標體系

3.1 鐵路數據中心運維數據采集需求

在云計算架構下，鐵路數據中心的資源種類更多，運維監控對象構成更為復雜。鐵路數據中心運維監控對象可劃分為基礎環境設施、IT 硬件設備、系統軟件、業務應用系統4 大類。基礎環境設施包括供電、空調、UPS 等；IT 硬件設備包括PC 服務器、存儲、以及路由器、交換機、防火墻等；系統軟件包括云平臺服務、操作系統、數據庫、中間件、虛擬服務器等；業務應用系統是部署在鐵路數據中心的各類鐵路信息系統。

為此，需要采集的鐵路數據中心運維數據主要包括以下4 類：

（1）基礎環境設施數據：包括機房溫度、濕度、供電、紅外等機房動環數據。

（2）IT 硬件設備數據：支撐整個業務、應用系統的基礎設施運行環境產生的數據，包含對服務器、網絡設備、存儲設備的運行日志數據，指示燈報警數據等。

（3）系統軟件數據：包括操作系統、中間件、數據庫、大數據組件的運行狀態數據，系統軟件日志數據。

（4）業務應用系統數據：包括應用系統的整體性能指標，系統運行狀態、響應時間、系統運行日志等；還包括應用系統中各個具體業務應用的性能指標，如當前請求的響應時間、請求量、運行狀態等。

這些數據能夠表征鐵路數據中心的整體運行狀況，運維人員可利用這些數據，了解系統運行健康狀態和資源占用情況，分析和判斷業務應用系統是否需要擴容或縮容。

3.2 運維數據分類

數據中心智能運維管理系統應能對每一種監控對象采集動作抽象，實現基礎環境設施、IT 硬件設備、系統軟件、業務應用系統的統一管理。運維指標數據可分為4 類：配置數據、監測數據、日志數據和事件數據。

（1）配置數據：描述資源對象的配置屬性，包含資源對象本身的屬性，以及資源對象間關聯關系，這類數據僅在資源對象的屬性或資源對象間關聯關系發生變更時才有變化。

（2）監控數據：主要是各類資源對象運行過程中產生時序指標數據，隨著時間積累很快，例如：CPU、內存、磁盤、網絡狀態、流量、響應時間等，主要用于反映業務和系統的運行情況及狀態；這類指標數據必須采用相同的統計口徑，具有可比性。

（3）日志數據：日志數據一般是文本類型數據，主要包括資源對象的運行日志和業務應用的運行日志；可通過關鍵字或正則匹配，在日志數據中發現關鍵信息。

（4）事件數據：是運維過程中，由監控數據或日志數據產生的一類特殊數據，用來記錄發生的特定事件的相關信息，例如報警、異常、上線變更、任務調度等事件；事件分為一般事件和告警事件。

其中，監控數據量最大，主要記錄每時每刻主機、業務服務請求的性能指標，這類指標的樣本抽樣數據的采集需要做到秒級。日志數據占用的存儲空間最多。事件數據主要是各類業務應用系統推送給監控系統的郵件，數據中心基礎設施管理（DCIM，Data Center Infrastructure Management）系統監測的溫濕度、報警指示燈等消息事件等，這類數據需要由監控系統進行分析，并生成標準事件格式；告警是一種特殊的事件，告警數據包括監控系統生成的告警信息，以及來自于業務應用系統的告警信息。

3.3 鐵路數據中心運維管理指標體系

基于上述運維數據，構建鐵路數據中心運維管理指標體系，如表1 所示。

表1 鐵路數據中心運維管理指標體系

各指標數據項由指標元數據定義，如表2 所示。

表2 鐵路數據中心運維指標元數據定義

鐵路數據中心資源種類繁多，需要根據不同種類資源定義其配置數據的數據模型，且配置數據的數據模型還會因資源屬性變更而發生變化。而監控數據、日志數據、事件數據這3 類運維指標數據，則可以定義相對固定的數據模型。表3 描述5 種數據模型：配置模型、指標模型、日志模型、事件模型、告警模型。

表3 運維指標數據的數據模型（數據定義）

4 運維監控數據采集與存儲

4.1 運維監控數據采集

在云計算和異地多數據中心的架構下，運維監控對象種類及數量急劇增加，涉及硬件層、云平臺服務層及應用系統層，運維數據采集方式存在諸多不同。針對不同類別監控對象，可靈活采用多種數據采集方式。

（1）基礎環境設施：對于機房空調、供水、供電、防火設備等設備設施，通過巡檢機器人[7]獲得動環報警器、設備指示燈的聲光電告警事件信息，通過嵌入式傳感器（如溫濕度傳感器）等獲取環境信息。

（2）IT 硬件設備：對于云平臺的主控節點、計算節點、網絡節點等物理服務器和存儲設備，一般通過IPMI 協議獲取機柜、機箱或服務器的報警事件數據，通過巡檢機器人檢查硬件報警指示燈信息，通過SNMP 協議主動獲得網絡設備性能指標數據；對于支持RESTful 協議的IT 硬件設備，可通過RESTful 主動采集其CPU、內存等性能數據。

（3）系統軟件：對于操作系統以及在其上運行的KVM、Libvirt、QEMU 等基礎系統軟件，通常通過遠程連接（RPC）獲取性能指標和運行日志；對于Keystone、Nova、Glance 等云服務，通過RESTful的方式獲得其監控數據；對于虛擬機，可通過內部虛擬機守護代理（QGA，QEMU Guest Agent）程序獲得其性能指標和日志數據。

（4）業務應用系統：可通過Syslog 獲得業務應用系統的運行日志，通過HTTP/HTTPS 協議獲得其服務響應狀態和響應時間等性能指標。

代理程序通過本機或遠程等方式執行運維數據采集任務，并可采用分布式級聯的形式，對數據逐級匯聚后傳輸至采集控制平臺。針對不同的監控對象，代理程序定制了不同的采控插件，擁有面向監控對象的采控能力服務化封裝，以腳本或插件方式按需擴展，實現大規模節點數據采集任務秒級調度，以及跨數據中心、多網絡環境下運維數據采集的統一控制。

4.2 運維監控數據存儲

所采集的運維監控數據經過預處理后，先寫入消息隊列中，采集控制平臺調度流式任務，從消息隊列件里讀取數據，根據數據的用途和訪問頻次進行分類存儲[8]。根據重要程度/時間等要素，對運維監控數據進行分類，不同類別數據采用不同的數據生命周期管理策略，實現數據的快速查詢匯聚，滿足多種數據使用需求。

4.2.1 即時訪問的熱數據

對于時序指標數據、告警數據等查詢類數據，可采用 ElasticSearch 進行存儲；ElasticSearch 具有列數據庫的水平擴展能力，支持吞吐量線性擴展，特別適用于保存與時間有關的指標數據。

另外，在指標閾值分析和儀表盤操作時，均需要高頻訪問最近24 h 的熱數據。使用Redis 內存數據庫，將這類熱數據存儲在內存，在出現高并發請求時，能大幅度減少磁盤IO，提高數據處理響應速度，保證高效的數據查詢檢索和分析處理。

4.2.2 無需即時訪問的溫數據

資源配置數據和資源對象間關聯關系數據一般不需要即時訪問，但也會經常被使用到，對于這類溫數據可以使用關系型數據庫進行存儲。

關系型數據庫能夠保證數據強一致性，適用于存儲系統配置信息、功能策略、管理參數、管理任務等數據量不大的關鍵數據，并且還可采用反范式設計來平衡數據庫存取效率和事務完整性。

資源對象間關聯關系數據涉及到的大量資源實體之間錯綜復雜的關系，可采用關系型數據庫MySQL 進行存儲。MySQL 提供圖形數據存儲模式，能非常自然地映射資源間關系，可支持圖形數據高效檢索和拓撲關系分析。此外，MySQL 也具備事務一致性和一定水平擴展能力，也適于應用在資源配置數據分析方面。

4.2.3 長期存檔的冷數據

對于配置管理信息、運維日志等使用頻次較低，但又需要長期存儲的冷數據，采用文檔型數據庫MongoDB[9]進行存儲。

MongoDB 在海量數據存儲方面具備明顯優勢[10]，存儲模式靈活自由，檢索能力強，讀寫性能均衡，可支持主備、分片式集群，在性能和擴展能力也超過關系型SQL 數據庫。

5 典型應用場景

目前，主要面向異常檢測、故障分析、運維輔助決策3 類運維業務，進行了初步應用開發。

5.1 異常檢測

為實現精準的監控指標異常檢測，除了常規的靜態閾值檢測外，還使用動態閾值、周期性分析等技術。相比傳統的靜態閾值檢測，動態閾值考慮了監控數據的周期性變化、歷史趨勢變化以及波動幅度變化規律，通過對此對象的監控數據走勢進行數字建模，可計算得到監控值在將來一段時間里的合理范圍。

動態閾值技術主要有線性回歸、時間序列分解、長短期記憶網絡網絡（LSTM，Long Short-Term Memory）。時間序列分解的計算速度最快，LSTM具有理論上最優分析精度，線性回歸處于中間水平。考慮到數據中心監控指標異常檢測計算量極大，采用時間序列分解進行動態閾值預測，效果如圖2 所示。

圖2 基于動態閾值的異常檢測效果圖示例

5.2 故障分析

當鐵路數據中心出現故障時，若故障排查完全由運維人員的分析判斷，運維人員需要登錄多臺設備，逐一檢查監控對象的各項指標，依據經驗判斷故障，故障排查過程耗時費力。

為此，匯總歷史異常數據，挖掘和分析與各類問題現象相關的運維監控數據項，確定相關性較高的數據項范圍，以此確定故障排查頁面所需要展示的數據項。通過對大量運維監控數據的關聯分析，故障分析功能可為運維人員提供與故障診斷相關的重點關注數據，并可自動分析可能的故障原因[11]，便于運維人員確定問題類型，快速定位問題，幫助其提高工作效率。圖3 為單機故障排查頁面，集中顯示CPU、內存、磁盤等資源的消耗變化情況、設備近期工作強度變化情況、以及對應集群和存儲等硬件環境的工作狀況。依據該頁面提供的綜合信息，運維人員可快速判斷故障產生的位置和時間范圍，無需逐一查看各項指標。

圖3 單機故障排查頁面

5.3 運維輔助決策

通過統計和預測各個鐵路數據中心資源的使用情況，為運維人員提供資源負載清單，并對資源消耗情況進行預測，便于運維人員全面掌握每個鐵路數據中心各類資源的使用狀況（閑置、高負荷、使用率等）和趨勢，及時制定性能調優方案，進行合理調度管理；并根據各類資源的預計耗盡時間，提前進行資源擴容準備，避免因資源耗盡而宕機的風險。對于鐵路數據中心資源消耗預測，也可使用時間序列預測方法，對未來資源耗盡的時間進行預測，如圖4 所示。

圖4 運維輔助決策支持應用示例

6 結束語

結合鐵路數據中心云化趨勢和多地多中心發展要求，本文提出鐵路數據中心智能運維管理系統方案。鐵路數據中心智能運維管理系統劃分為監控對象層、數據采集層、數據存儲層和業務服務層，兼容跨區域復雜網絡環境，從各個鐵路數據中心采集運維數據，匯集到運維管理中心，實現對異地多數據中心的統一運維管理。在全面分析鐵路數據中心運維數據采集需求的基礎上，建立鐵路數據中心運維管理指標體系，深入探討運維監控數據采集與存儲技術，為鐵路數據中心智能運維管理系統的開發奠定了基礎；此外，還初步開發了異常檢測、故障分析、運維輔助決策典型運維業務應用。

在實現鐵路數據中心運維監控數據采集與存儲的基礎上，下一步將聚焦于智能分析算法模型的研究，并基于此推進運維業務應用的迭代開發，提升鐵路數據中心運維業務的自動化、智能化水平，促進鐵路數據中心運維業務模式創新，為形成彈性分配資源的技術與服務管理體系提供強有力支持。