1.背景
针对这样的需求,为了更高定制化地完成IoTDB监控框架的监控和实时查询,拟结合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会话,进行数据的获取。
- 特点:
最后讨论决定,采取方案四。