基于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平台服务的观察与监控，能够节省大量的人力成本，实现自动化且实时的监控软件平台.