基于Lens的空間多服務環境下SaaS監控分析與研究

包達爾罕，袁成軍，賀新樂

（西安微電子技術研究所，陜西 西安 710054）

0 引言

隨著空間技術的高速發展，空間任務的復雜性和空間資源的稀缺性使得傳統的軟件部署方式已經逐漸無法滿足空間探索的要求.空間探索帶來靈活多樣的軟件需求、短期快速的軟件研制周期、延后的軟件狀態固化和日益復雜的軟件架構框架等.

因此，空間技術需要一種新的軟件框架來降低服務的復雜度和縮短平臺的軟件開發周期，實現系統、平臺和服務的解耦合，提高系統的可靠性、安全性.微服務架構正是滿足上述要求而出現，它的核心是軟件開發與面向服務相結合，將復雜多樣的軟件程序架構變成一組或多組低耦合、單一性的服務.每個服務具有相對獨立性，互不影響，而且服務之間也可以通過一定的通信機制互相傳遞信息.

本文的微服務框架采用SaaS（Software as a Service）框架，把服務平臺演化成以網絡通信構建的模式，其中，軟件應用的研發平臺都是一種服務.SaaS能夠顯著提高軟件開發的速度，尤其是縮短軟件的研發周期.因此，對于空間軟件應用的要求，SaaS能夠顯著提升工程效率，并且有效整合當前空間資源，實現空間軟件服務部署的近似最優解.

SaaS的優點在于可以給用戶提供在空間環境下應用服務程序，并且可以通過輕量級的客戶端接口或程序接口使用戶可以直接訪問應用程序.用戶無需管理或控制底層SaaS 的基礎架構，包括網絡、服務器、操作系統、存儲甚至單獨的應用程序功能［1］.

在主流的SaaS解決方案中，筆者選用容器作為空間應用服務的最小細胞單元，因此選用docker作為SaaS關鍵技術層；Kubernetes作為當前docker容器管理的主流平臺，作為SaaS服務管理層.同時，當前主流的容器監控平臺主要以Kubernetes自帶的Dashboard為主，也有以Prometheus+Grafana的相對靈活的監控方式.

但是，根據空間應用的特點，筆者提出了一種基于Lens的信息化監控軟件模型，以滿足SaaS平臺中服務監控的要求，同時能夠解決對網絡與硬件信息實時獲取的要求.

1 信息化監控軟件模型介紹

主要介紹空間多平臺信息化監控軟件模型中可視化實時顯示工具Lens 與以流形式獲取信息工具Prometheus，并且介紹兩者技術特點和應用情況.

1.1 Lens介紹

Lens 是一個跨平臺的開源的度量分析和可視化工具，可以通過將采集的數據查詢然后可視化的展示，并及時通知.它近似于一種針對Kubernetes的IDE工具，可以獨立于SaaS框架之外作為監控使用，并且可以通過通信機制遠端查看Kubernetes的狀態信息［2］.

Lens可以實時查看Kubernetes集群狀態，比如Pod實時日志查看、集群Events實時查看、集群故障排查等.Lens，就不再需要敲打很長的kubectl命令，只要使用鼠標點擊幾下，非常便捷.它具有下面這些優點：（1）可多集群管理，能夠支持數百個集群；（2）它是相對獨立應用，無需在集群中安裝特殊組件；（3）集群狀態實時可視化，提供資源利用率圖表和歷史趨勢圖表；（4）提供終端訪問節點和容器；（5）完全支持Kubernetes RBAC.

同樣，Lens具有較好的可擴展性.因其屬于開源項目，主要使用的技術包括TypeScript作為前端與后端，ReactJS作為前端與UI，MobX作為狀態管理.Lens可以通過編寫擴展API的方式，來獲得定制化功能或增強性變化.

1.2 Prometheus介紹

Prometheus 屬于系統監控和警報工具，最初構建于SoundCloud［3］.自2012年成立以來，許多公司和組織都采用了Prometheus，該項目擁有非常活躍的開發者和用戶社區.它現在是一個獨立的開源項目，獨立于任何公司進行維護.為了強調這一點，并澄清項目的治理結構，Prometheus于2016年加入云原生計算基金會，作為繼Kubernetes之后的第二個托管項目［4］.

Prometheus 實質上是開源報警系統和時序列數據庫（TSDB）.因此，它的模型結構如圖1 所示.Prometheus 存儲數據是時序數據，即按相同時序進行數據排列，以時間維度存儲連續的數據.因此，它設定Metric類型，并建立相應的數據查詢DSL語言即PromQL.圖中Exporter負責數據搜集并匯報的程序［5］.

圖1 Prometheus結構模型圖Fig. 1 Structural model diagram of Prometheus

因此，Prometheus的核心組件構成主要有（1）Prometheus server：主要的核心組件，用來收集和存儲時間序列數據；（2）client libraries：提供客戶端，主要是用來幫助應用程序更容易生成滿足Prometheus 格式的監控數據，支持各種各樣的開發語言；（3）push gateway：對于那些生存時間很短的job 工作，采用Prometheus 的pull 模式可能來不及收集，可以部署這個組件，讓job 主動把監控指標push 到getway，Prometheus再從getway中拉取；（4）exports：各種各樣的集群信息；（5）alertmanager：警告組件［6］.

Prometheus作為Google發起的Linux基金會的開源項目有如下優點：

（1）提供時序性數據模型（時間流的key/value 數據組）；（2）自主開發的數據查詢DSL 語言.即PromQL；（3）支持系統節點存儲，也可以存儲到指定的數據庫中；（4）采用Http協議，具有默認的模式拉取數據，也可以通過中間工具轉發數據；（5）易于集成、可擴展.

2 信息化監控軟件模型架構

信息化監控的本質是，基于信息化系統中的服務，構建起獲取信息與傳遞信息的通路，其中可以涉及軟件資源、硬件資源和系統狀態信息等.信息化的數據記錄并承載服務的動態或靜態指標，并且獨立于運行平臺之外.監控軟件模型能夠通過不同的采集方法，減少空間應用軟件與多樣資源的差異，實現統一管理、統一規范、統一處理、統一展現，最終實現運維規范化、自動化、智能化的運維管理［7］.

監控的日志信息和數據展示是監控軟件模型的重要組成功能，SaaS服務監控模型的實現架構主要可以分為2個部分，其中包括日志信息和數據展示2個部分.由此可以再劃分為4個部分，分別為數據收集、數據展示、日志收集、日志展示.針對空間多平臺信息化系統的要求，數據收集主要通過Prometheus和Kubernetes的kubectl工具完成，數據展示和日志展示則主要通過Lens來實現，如圖2所示.

圖2 信息化監控軟件模型Fig. 2 Software model of information monitor

3 Lens監控系統的模塊功能及實現

Lens從根本上解決了Zabbix不能檢測Kubernetes集群中容器狀態的問題，通過kubectl遠程客戶端和kubelet配置文件組合，形成可以脫離集群范圍的以網絡通信為媒介的監控系統框架.并且，Lens支持多集群的監控，其Kubernetes系統資源數據收集，通過Prometheus完成，形成圖形化、可視化和動態化的功能模塊.

Lens 的系統有前端展示界面和后端數據收集，前端展示通過TypeScript 和Electron 完成界面.后端數據收集由2 個模塊共同構成，分別是kubectl構成k8s資源信息的收集和Prometheus組成的系統狀態信息.

3.1 前端界面模塊

前端界面模塊是一個窗口展示界面，主要是將數據收集層獲取到的數據進行統一展示，展示的方式可以是曲線圖、柱狀圖、餅狀圖等，通過將數據圖形化，可以幫助用戶了解一段時間內主機或網絡的運行狀態和運行趨勢，并幫助用戶來排查問題或解決問題.

Lens 是一個開源的管理Kubernetes 集群的IDE，支持MacOS，Windows 和Linux.當前演示環境使用Linux 的Ubuntu20.04 LTS 版本和Windows 10 版本，Lens 版本使用4.2.4，連接的Kubernetes 集群運行在本地環境，包括X86和ARM 64的樹莓派節點.

啟動Lens 后，通過點擊左上角的+圖標并選擇kube-config，將Lens 連接到Kubernetes 集群.連接上之后，Lens將顯示大量關于集群的信息，可以看到正在運行的工作負載，包括Pods、守護進程.

前端界面展示主要用來完成收集到的數據整理，并按照預先的分類進行處理，筆者對Lens進行了部分前端界面的修改使之能夠滿足空間應用的需求.

前端界面受限是系統整體的狀態圖，這部分的數據收集是通過Prometheus的時序數據實現，而下方的數據則是通過kubectl獲取的系統日志信息.前端界面的左側為預先定制好的Kubernetes系統對象資源分類.包括了主要Kubernetes信息，如Node信息、工作負載、Pod信息、調度信息、集群配置信息和網絡等.

節點主要包含kubectl執行kubectl get nodes命令后的信息，艙儲則是Pod的相關信息，還有相關的日志信息都在其中.

3.2 后端數據收集模塊

后端數據收集模塊主要包括了2個部分，分別是kubectl和Prometheus.這2個部分共同運作，才能夠在前端顯示出動態的、實時的數據.

3.2.1 kubectl 數據收集模塊 kubectl 數據收集模塊的構成主要通過Kubernetes 發布的應對不同系統的kubectl客戶端，和與之相對應的kubectl命令構成.

后端使用TypeScript 構建并生成數據收集所需的JS 文件，通過JS 文件執行kubectl 客戶端，實現對Kubernetes 的資源對象類型信息獲取的功能.但是，資源對象經過分類主要分為node、pod、kube-object 和log4類.這4類分別通過不同的數據模塊解決，即node-menu、pod-menu、kube-object-event-status和example-extension，其中，后兩者收集Kubernetes的大量信息.

3.2.2 Prometheus 數據收集模塊 Prometheus 數據收集模塊對于Kubernetes 也是容器的一種，與其他單一容器不同，它是由多個不同類型的容器組成，主要包含3種容器，即本體容器Prometheus、節點信息收集容器node-exporter 和數據收集處理的kube-state-metrics.Prometheus 具有2 種數據處理方式，kube-statemetrics 是其中一種，另一種為metric-server.在Lens 中，本文使用的是前者，更有利于收集集群的狀態信息，更偏向于Kubernetes相關的信息［8］.

Prometheus的部分相對復雜，因此，Lens則用單獨功能模塊實現這部分功能，并且也提供與之相對應的接口，用戶可自行修改Prometheus 的部署方式，使用不同的版本和組件.筆者使用的版本是能夠兼容x86和ARM64的容器架構，具有跨硬件平臺監控的能力.

筆者主要是修改功能模塊下的yaml文件，來修改Prometheus的功能規則和信息標準.Prometheus把收集到的數據通過kube-state-metrics保存統一格式的數據存儲到Prometheus自帶的時序數據庫，用于Lens調用.

Prometheus 的部署主要分成14 個相關yaml 文件，其中，關鍵文件為configmap 文件、service 文件、statefulset 文件和rules文件.這4種文件決定數據收集信息的內容和規則，并且將安全密鑰等級寫入Prometheus中，使之能夠正確運行在Kubernetes集群之上.

除了Prometheus的容器部署之外，還需要部分node-exporter和kube-state-metrics兩種容器.

Prometheus的工作流程相對固定，主要包含3個方面：Prometheus server定期從配置好的jobs或者exporters中拉取metrics，或者接收來自Push的gateway發送過來的metrics，或者從其他的Prometheusserver中拉metrics；Prometheus server在本地存儲收集到的metrics，并運行定義好的alerts.rules，記錄新的時間序列或者向Alert manager推送警報；Alertmanager根據配置文件，對接收到的警報進行處理，在圖形界面中發出警告，可視化采集數據.

4 結束語

筆者對Lens進行部分修改，使之更適應空間多平臺信息化應用，并且提升監控模塊的組成，更有利于對SaaS平臺服務的觀察與監控，能夠節省大量的人力成本，實現自動化且實時的監控軟件平臺.