基于Kafka和Kubernetes的云平臺監控告警系統①

郝鵬海,徐成龍,劉一田

(南京南瑞信息通信科技有限公司,南京 210003)

隨著云計算技術的高速發展,新興的虛擬化技術Docker 容器憑借自身松耦合、分布式等優點,迅速被各大企業接受,越來越多的公司開始部署容器云并將之應用于實際生產中.在容器云環境中,存在著大量的容器,因而需要一個高效便捷的集群管理方案[1].在眾多容器編排系統中,Kubernetes 憑借其部署難可移動、可擴展、可修復等諸多優點,Kubernetes 也能讓開發者斬斷聯系著實體機或虛擬機的“鎖鏈”,從以主機為中心的架構躍至以容器為中心的架構,最終提供給開發者諸多內在的優勢和便利[2].因此成為各大公司部署開發容器云的首選.

在現有的業務系統中,主機上運行的各種業務程序承載了業務系統的采集、傳輸和展現,因此主機的安全防護尤其重要,一旦發生安全事故,必然會大范圍的影響業務系統的穩定運行.基于以上兩點,本文設計了一種基于Kafka和Kubernetes的云平臺實時監控系統,通過對容器和主機進行全面監視,可盡早識別主機的安全風險,當出現數據異常時,能夠及時發現、及時處理,從而達到保障操主機業務系統穩定的運行,全面提升監控系統安全防護能力.

1 相關技術

1.1 Kubernetes 技術

Kubernetes (以下簡稱K8s)是Google 開源的一款容器編排工具,它是誕生在Google 內部運行很多年的博格系統之上的產物,因此其成熟度從其誕生初期就廣泛受到業界的關注,并且迅速成為編排工具市場的主流,它的主要作用是對Docker 容器做編排工作[3].K8s 通過控制器實現容器狀態監控、容器自動重建,以及當容器處理能力不足時,根據用戶定義的擴展規則進行自動擴展等功能.

1.2 Kafka 技術

Kafka是一個基于分布式的消息發布-訂閱系統,Kafka 在主題中保存消息的信息.生產者向主題寫入數據,消費者從主題讀取數據,從而實現數據傳輸.同時主題也是可以在多個節點上被分區和覆蓋的[4].

Kafka 可以以分布式集群的方式存在,也可以單臺模式存在其內部數據傳輸,通過TCP 協議實現Kafka傳輸的消息內容保存在操作系統內核的頁面緩存中.具體的傳輸流程分為以下5 個步驟:

(1)生產者創建通信的“主題”并通知Kafka;

(2)消費者從Kafka 上訂閱其待接收的主題;

(3)生產者將其待發送的消息發布到Kafka 上;

(4)Kafka 將該主題的消息發送到訂閱該主題的消費者;

(5)消費者從Kafka 接收其訂閱主題的消息.

通過客戶端訪問數據庫總線的方式,如圖1所示.

圖1 通過客戶端訪問Kafka 集群示意圖

圖2描述了通過客戶端訪問Kafka的程序代碼流程.

圖2 客戶端訪問消息總線程序代碼流程示意圖

2 系統架構設計

云平臺監控系統采用分層架構設計實現,運行時從業務系統和各類基礎設施中采集數據,歷經數據存儲,分析處理等多個功能層次的交互,依次進行監控和告警數據采集、分析、上報、展示給終端用戶等多個階段,形成如圖3所示的分層結構.

云平臺監控系統系統自下而上可分成數據采集層、數據存儲層、數據分析層、展現層共4 層.第1層數據采集層,負責接收業務系統監控的數據,節點和容器的監控數據,告警數據,這些數據傳輸均采用JSON 格式,監控系統接收并進行相應的解析;第2 層為數據存儲層,負責將基礎設施監控數據,系統監控數據通過Redis 緩存[5]并轉發存儲到非關系型數據庫Elasticsearch 上,告警數據寫入本地的達夢數據庫中;第3 層為數據分析層,負責分析監控數據,統計分析業務系統運行情況,對監控數據進行分析,生成告警信息;第4 層為數據展現層,包括監控概覽,基礎設施運行狀況展示,業務系統運行狀況展示,告警信息的展示與處理.

圖3 云平臺業務系統架構圖

3 系統設計與實現

云平臺監控告警系統主要分為以下3 個主要的模塊:基礎設施監控模塊,業務系統監控模塊,告警模塊.

基礎設施監控模塊:對主機設備、服務器和Docker容器的CPU,內存,文件使用率等數據進行監控,并且對監控數據進行存儲、統計和展示.

業務系統監控模塊:對業務系統的Web 請求,SQL執行,JVM 等數據進行監控、存儲、分析和展示.

告警模塊:包括自定義告警規則,主動分析監控數據生成告警信息,接收由業務系統上報的告警信息,告警通知,告警處理和告警展示等功能.

3.1 基礎設施監控

基礎設施監控包括容器監控和主機設備監控,本文采用Kubernetes 來管理容器,采用cAdvisor 來采集服務器和容器的監控運行數據,cAdvisor是谷歌開發的容器監控工具,cAdvisor 用于采集一臺機器上運行的所有容器的信息,對節點機器上的資源及容器運行狀態信息進行采集,包括CPU 使用情況、內存使用情況、網絡吞吐量和文件系統使用情況.

主機信息采集方式為,由操作系統(凝思、麒麟)主動進行信息采集,通過Kafka 上報到監管平臺.信息采集分為周期上報(運行信息)和觸發上報2 種上報方式,以達到對主機運行狀態進行全面監視的目的.

表1為主機的靜態配置信息,操作系統主動采集如下信息(發送一次即可),通過Kafka 發送至采集服務器,最后在系統界面進行匯總展現.

表1 主機部分配置信息采集表

表1中內容的發送時機為操作系統采集模塊啟動時發送,以后周期性發送(每24 小時發送一次),通信方式為Kafka,消息格式為syslog.

除了表1中的配置信息、系統還會對主機的動態運行信息進行采集,包括僵尸進程數量、未釋放的TCP 連接數、內存和硬盤的使用狀態、網絡端口監情況、網卡狀態和主板溫度狀態等信息.

操作系統對監視內容使用Kafka 消息總線通過訂閱、發布不同的主題,實現操作系統與平臺的雙向交互通信.表2為傳輸內容說明表.

表2 傳輸內容說明表

表2中,syslog 格式信息定義如下:

<告警級別><空格>告警時間<空格>IP#主機名<空格>設備類型<空格>內容描述.例如:<0>2006-03-12 20:12:23 192.168.20.22#scada SVR 0 System EXCEPTION

告警級別依照采集信息對監控系統安全的影響,分為緊急(0)、重要(1)、普通(2)、監視(3)4 個級別.告警發生日期和時間格式YYYY-MM-DD HH:MM:SS,YYYY 表示年份,MM為月份,DD是日期.24 小時制,有效值為(00–23),MM和SS的值的范圍為(00–59).月、日、時、分、秒各2 個字符,小于10 時十位應補0.

告警發生日期和時間格式YYYY-MM-DD HH:MM:SS,YYYY 表示年份,MM為月份,DD是日期.24 小時制,有效值為(00–23),MM和SS的值的范圍為(00–59).月、日、時、分、秒各2 個字符,小于10 時十位應補0.

設備名稱為標識產生告警事件的主機IP 地址#主機名.設備類型為一個用來描述告警源的不超過32 個字符的字符集.

基礎設施監控的整體流程為:

第1 步.基礎設施監控模塊連接Kubenetes 管理機,獲取當前服務器節點信息,應用信息,服務信息,接收主機設備通過Kafka 傳來的報文信息,解析成需要的格式并將其記錄入庫.

第2 步.各個服務器中安裝cAdvisor 插件,該插件啟動會提供相關CPU,內存數據獲取接口.

第3 步.基礎設施監控模塊逐個連接服務器,從cAdvisor 插件中獲取CPU,內存等監控數據,并存儲入庫.

第4 步.基礎設施模塊逐個連接所知的Docker 容器,從cAdvisor 插件中獲取Docker 容器的CPU,內存等監控數據.

第5 步.基礎設施模塊獲取主機設備通過Kafka上報的報文信息,進行消息解析并存儲入庫.

第6 步.基礎模塊展示服務器和Docker 容器的實時CPU,內存等運行數據,支持查看Docker的日志,部署等情況.

3.2 業務系統監控

業務系統監控依賴于監控Agent 監控業務系統并上報監控信息.因為業務系統和云平臺監控系統是兩個相互獨立的系統,因此在設計中應當盡量減少業務系統對監控系統的感知,保證監控系統不會對業務系統的穩定、性能、安全造成影響,監控系統在保障系統安全穩定運行的同時能夠及時發現業務系統中的問題.業務系統監控的整體流程如下:

第1 步.業務系統集成監控Agent 包,配置監控系統訪問地址,監控項等信息.

第2 步.監控Agent 會根據配置,對HTTP,Servle,RESTful,Hessian 等Web 請求進行監控,并統計其請求次數,響應時間,異常等信息,定期向云平臺監控系統發送監控信息.

第3 步.云平臺監控系統會接收各個節點發送的監控信息,進行持久化存儲.

第4 步.云平臺監控系統統計和分析某業務系統各個節點的監控數據,得出當前系統的總體運行數據.

第5 步.云平臺監控系統支持展示系統總體的Web 請求次數,最大響應時間,平均響應時間,異常次數等數據,支持查詢某時間段的運行情況,支持查詢SQL 執行的次數,平均執行時間等.

第6 步.云平臺監控系統支持單節點的Web 請求,SQL 執行,JVM 運行情況等展示,支持單次請求服務鏈的跟蹤,該請求的SQL 調用展示及異常堆棧信息展示.

3.3 告警模塊

首先定義幾個名詞的概念:

(1)事件告警.本文中包括容器、節點、設備等3 種告警.包含發生時間、告警級別、告警對象、告警描述、告警類型、告警采樣值及處理狀態等屬性.

(2)告警采樣值.采樣值觸發告警時的容器狀態信息數據,包括CPU 使用率、內存使用率、磁盤使用率等.

(3)告警關聯規則.由多個告警指標抽象出的告警規則,由用戶自主設定針對容器、節點或者設備的告警規則,如對節點node1 設定規則“CPU 使用率6 小時內只要有一次大于95%”,這項規則中包含4 種判別條件,CPU 使用率、6 小時內、只要有一次、大于95%,通過監控節點node1的狀態信息數據、只要有滿足這4 個條件的數據,即會觸發告警.

云平臺告警通過@Scheduled(cron="40 0/1 * **?")注解啟動一個定時任務定時掃描告警規則,@Scheduled 由Spring 定義,用于將方法設置為調度任務.cron 參數接收一個cron 表達式,cron 表達式是一個字符串,“0 0/1 * * *?”即代表從每小時的第0 分0 秒開始,每分鐘觸發一次.

通過對告警規則的定期掃描,查詢Elasticsearch 中的數據判斷是否有滿足告警規則的數據,如果有的話,查詢當前是否已經告警,如果沒有告警,則把告警信息寫入數據庫中,并修改狀態為告警.圖4為告警分析流程圖.

4 實驗測試

4.1 系統平臺部署

系統平臺主要分為數據采集層,數據存儲層和Web 展示層.系統的開發環境部署如下,數據采集層由部署在同一個局域網內的Kubernetes 集群,一臺主機設備,一臺部署了業務系統的服務器和一臺Kafka 服務器組成,數據存儲層由Elasticsearch和Oracle 數據庫組成,Web 展示層由一臺部署了云平臺監控系統的服務器組成.

圖4 告警分析流程圖

4.2 實驗結果分析

圖5左上為資源監控概況,分別為K8s 管理的節點、應用、容器已經設備的個數,點開后有相應的詳情,如果有告警,會在右下方亮紅燈并顯示告警個數,可點開查看.圖5上中部分為實時K8s 事件信息,圖5右上為實時告警信息,點開后可看到詳情及處理流程.圖5下半部分依次為15 分鐘內監控的Web 事務訪問最慢的top5 請求、最慢的應用以及最慢的SQL 統計,點開后可看到詳情.圖6為容器、設備、服務的運行狀態信息.

圖7和圖8分別為告警規則管理界面和告警處理界面,實現對告警規則的增刪查改,支持節點告警、容器告警和設備告警.告警處理界面可以查看觸發告警的詳細數據,以及對告警進行處理.

圖5 監控主界面

圖6 監控系統監控詳情

圖7 告警規則管理界面

圖8 告警處理界面

5 結論與展望

本文設計了一套基于Kafka和Kubernetes的云平臺監控告警系統,為用戶管理容器、主機設備和業務系統提供了支持,可以實時監控容器、主機設備和業務系統的運行狀態,一旦出現故障,能夠迅速準確定位到故障根源,保障了主機設備的平穩運行.為了能夠進一步保障系統的安全狀態,下一步仍需要對告警觸發流程進行優化,并且通過多種安全機制和技術手段保證系統安全穩定運行.