1.背景

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

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

        针对这样的需求，为了完成Prometheus+Grafana的监控模块可视化系统轻量化替代方案，拟结合IoTDB workbench开发监控UI。IoTDB workbench又名IoTDB数据库管理系统，是一个能提供数据库信息查询、修改、删除、数据录入等功能的可视化数据库管理软件，支持对IoTDB数据库进行统一的管理和控制。

2.监控架构的选择

        IoTDB已经提供针对Prometheus的Http接口（端口号9091），动态更新指标采集数据。实现过程是，IoTDB提供采集指标的Http接口，由Prometheus向该Http接口进行数据的拉取和解析。

        当前目标是为了实现在workbench中增加IoTDB的监控和展示功能，提出以下四种方案：

2.1 方案一：直接解析IoTDB提供的9091端口字符串

        Workbench后台直接解析IotDB-9091端口中的字符串数据，并利用IoTDB进行指标采集数据的持久化存储。

  • 优点：
  1. IoTDB不需要针对监控模块可视化系统做任何改动，节省工作量。

  • 缺点：

  1. 实现过程死板，Workbench后台实际上就是复刻了一份Prometheus监控系统，没有达到轻量化的目的；
  2. 对端口提供的字符串解析过程存在难度。

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

        保留Prometheus监控系统，由Workbench前台对其发起请求进行数据的获取。

  • 优点：
  1. 利用Prometheus这一成熟的开源完整监控解决方案，省去解析IotDB-9091端口中的字符串数据的步骤；
  2. 监控指标的持久化存储由Prometheus解决，节省工作量。
  • 缺点：
  1. 扩展性欠佳。监控架构的功能完全限制在prometheus内，如果未来有功能的扩展和修改存在困难；
  2. Prometheus监控系统提供的数据持久化存储方案仅能存储15天内的内容，因此还需要额外配合使用iotDB实现监控指标的存储，没有达到轻量化的目的。

2.3 方案三：IoTDB设计监控指标查询接口，数据持久化保存在Workbench后端

        直接在IoTDB内设计一套接口，为运行监控指标提供单独请求查询功能，在Workbench端使用iotDB作为持久化存储。

  • 优点：
  1. 放弃了直接解析IotDB-9091端口中的字符串数据的方案，省去解析特殊格式字符串数据的步骤；
  2. 直接由Workbench向IoTDB的采集指标进行定时请求从而获取指标值，监控架构整体相对轻盈。
  • 缺点：
  1. Workbench后端需单独配置时序数据库实现监控指标存储；
  2. IoTDB内需要另设计指标查询接口。

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

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

  • 优点：
  1. 本质上监控数据也是时序数据的一种，所以获取监控数据和获取普通的时序数据的方式是完全一致，省去监控指标获取的接口设计；
  2. 将磁盘IO的开销提前到IOTDB内部，监控架构进一步轻量化。
  • 缺点：
  1. 监控指标数据在IoTDB时序数据库内将占用一定的空间。

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

  • No labels