1.背景

        本文的目的是讨论可视化系统的具体实现问题。经过调研，当前主流的数据库监控方案是搭建两个开源程序来实现，分别是Prometheus监控系统和Grafana时序数据展示工具，前者用以指标采集和数据存储，后者是用以大规模指标数据的可视化展现。Apache IoTDB当前已支持这种主流监控框架的实现方式，但存在以下缺点：

1. 配置过程相对复杂；
2. 监控数据类型相对受限；
3. 后期的维护和功能的扩展存在较大的局限性。

        针对这样的需求，为了完成Prometheus+Grafana的监控模块可视化系统轻量化替代方案，拟结合IoTDB workbench开发监控UI。其中IoTDB workbench是什么？。

2.监控架构的选择

        当前IoTDB已经提供了针对Prometheus的PushGateway模块的Http接口（端口号9091），去动态提供指标采集数据，但配置PushGateWay的方式官方已不推荐，因此已被移除。直接由Prometheus向IoTDB提供采集指标的Http接口进行数据的拉取和解析。当前目标是为了实现在workbench中增加IoTDB的监控和展示功能，提出以下四种方案：

2.1 方案一：直接解析9091端口字符串

        由Workbench后台直接解析9091端口提供的字符串数据，并利用IoTDB进行指标采集数据的持久化存储，最后由IoTDB发起请求，返回json格式的数据。

• 特点：

        实现过程死板，实际上就是再做了一个Prometheus监控系统的复刻版，没有达到轻量化的目的，且对端口提供的字符串解析过程存在难度。

2.2 方案二：保留Prometheus监控系统

        保留Prometheus监控系统，然后由Workbench前台对其发起请求进行数据的获取，主语同样以JSON的格式返回。

• 特点：

        扩展性欠佳。监控架构的功能完全限制在prometheus内，如果未来有功能的扩展和修改存在困难，且prometheus监控系统提供的数据持久化仅能存储15天内的内容，因此还需要额外配合使用iotDB来作为prometheus的后端存储，同样没有达到轻量化的目的。

2.3 方案三：IOTDB内设计接口，数据持久化保存在Workbench后端

        直接在IoTDB内设计一套接口，为每一个系统运行监控指标指标提供单独请求并以JSON格式返回的功能，然后在Workbench端使用iotDB作为后端存储实现监控指标持久化保存。

• 特点：

       放弃了针对9091端口提供的字符串进行解析的方案。直接由Workbench向IOTDB的采集指标进行定时请求获取指标值，监控架构整体相对轻盈，是理想的实现方案。

2.4 方案四：性能指标保存在IOTDB内，通过Session会话获取

        参考MySQL的方式，将IOTDB采集得到的监控指标数据单独以表的形式保存在IOTDB内部，由Workbench直接与IOTDB建立Session会话，进行数据的获取。

• 特点：

       将磁盘IO的开销提前到IOTDB内部，监控架构进一步轻量化，是最理想的实现方案。获取监控数据和获取普通的时序数据是一致的。本质上监控数据也是时序数据的一种。

        最后讨论决定，采取方案四。