数据库监控作为数据库配套建设不可或缺的一环，能够实时或及时把握设备和系统的整体运行动态，提前、主动发现故障和隐患，缩短故障发现时间和解决时间，提高运维效率。与此同时，通过针对各项运行指标的统计分析报表，帮助管理员、运维人员、决策者多视角了解数据库的运行状态，从而更好的应对数据库的需求及规划。
openGemini借助ts-monitor对内核运行状态和机器进行监控，提供了260+项内核运行状态和设备运行监控指标，来满足我们日常的监控告警需求和帮助问题定位，本文主要介绍ts-monitor的工作流程以及监控指标分析案例，希望可以帮助大家更好的使用openGemini时序数据库。
ts-monitor是什么？
ts-monitor是openGemini开源的运维监控组件，核心目的就是要解决好两个数据库问题：其一，什么东西出故障了。其二，为什么它出故障了，根因在哪里。为此，openGemini在内部设计了大量监控项，例如磁盘IO、时间线数量、访问带宽、缓存空间使用率、缓存数据命中率等等（详细见官网文档），通过ts-monitor收集数据指标，可借助Grafana等显示并提供报警支持这些工作。
四个黄金指标
openGemini有大量监控指标，我们推荐Google监控系统的四个黄金指标，它们分别是：延迟、流量、错误和饱和度，其余指标可以根据实际需要，有选择性添加到看板即可。
延迟：访问openGemini的某个读写请求所需要的时间，可以通过表达式：difference(WriteReqDruationNs)/difference(PointsWriteOK)计算得到平均时延，待业务稳定后，预期为一个较为稳定的值。延迟长期过高，需要重点关注。
流量：是系统负载的度量方式，openGemini中可以是写入带宽，也可以是查询请求数（QueryReq）和写数据请求数(WriteReq)，可以通过如下表达式计算写入带宽：difference("fieldsWritten")/10（10s采集一次）。
错误：即客户端访问openGemini的请求失败数量，可分为ClientError（客户端错误数）、write400ErrReq（写数据发生400错误数）、和write500ErrReq（写数据发生500错误数）。
饱和度：它度量的是服务容量有多“满”，通常是系统中某受限资源的使用量，比如内存使用率，CPU使用率，磁盘空间使用率等等。
如何搭建监控看板？
如上图所示，每个节点需部署一个ts-monitor，可采集该节点上所有的openGemini组件日志中的监控指标，在生产环境中，为了避免与业务竞争资源，建议将指标数据转存到专门的存储节点，该节点上需运行openGemini单机版程序，监控系统/面板可以选择开源的Grafana或者Prometheus，二者openGemini均可支持。
ts-monitor的具体配置和安装部署，可以参考openGemini基础课程第一课的视频，在知乎、B站以及openGemini视频号均有发布。
如何从监控看板发现问题？
Case 1. Mutable（缓存）堆积，mutableSize长期处于高位
结合WriteReq、WriteDuration、WriteOkCount、WriteTotalBytes等监控指标分析：
-
Mutable堆积，WriteReq增大，Diskio时延无明显增加，可认为是业务写流量变大导致，例如流量导入、接入设备量增加等场景均会引起，可通过扩容解决。
-
Mutable堆积，WriteReq无明显增大，DiskIO时延增加，DiskIO带宽未满，可认为是磁盘IO存在瓶颈引起，如果DiskIO带宽已满，可能是磁盘带宽存在瓶颈。可更换SSD盘，或者通过扩容，分担写入流量。
内核指标说明：
WriteReq：数据写入请求
DiskIO时延（单次磁盘IO写时延）= difference(writeDuration)/difference(writeOkCount)
DiskIO带宽（数据写磁盘带宽）= difference(writeTotalBytes)/10 （字节/秒）
Case 2. 查询变慢
结合Source_length_count、Source_width_count、writeTotalBytes、Exec_scheduled、Exec_wait_time等相关指标分析：
-
如果执行引擎处理数据量很高，且DiskIO带宽高，可认为是大数据量查询引起，可通过优化查询语句或升级机器配置解决。
-
查看Exec_scheduled和Exec_wait_time指标，观察是否由于资源紧张，导致需要排队引起，可适当增加机器配置可解决。
-
查看慢日志或者执行Explain Analyze，分析现象原因。
内核指标说明：
执行引擎处理数据量=difference(source_length_count)* difference(source_width_count)
DiskIO带宽（数据写磁盘带宽）= difference(writeTotalBytes)/10 （字节/秒）
Case 3. 失败连接数指标FailedConnTotal持续增长，没有升级等部署操作
现象分析：
-
排查相关节点进程是否重启、意外退出、僵死等情况
-
排查相关网络是否故障
Case 4. 业务平均写时延出现激增
平均写数据时延，预期为一个较为稳定的值，当突然增大，可能是：
-
ts-store 负载变高，处理效率下降，可增加ts-store节点数量解决。
-
节点间网络延迟变高，传输效率下降，建议排查网络问题。
内核指标说明：
端到端平均写数据时延 = difference(WriteReqDruationNs)/difference(PointsWriteOK)
WriteReqDruationNs：写入请求耗费时间（累计值）
PointsWritenOK：写入成功的点数
结束
本文介绍了openGemini开源监控组件ts-monitor的功能，并分享了部分问题场景，讨论了如何通过内核监控指标判断问题，以及解决问题的办法。为了让更多人可以高效的找到问题的解决办法，欢迎大家到openGemini社区的讨论专区下参与问题分享！
更多资讯可关注openGemini公众号和视频号。如果您有好的意见或建议，欢迎到openGemini社区与我们一起讨论。
openGemini 官网：http://www.openGemini.org
openGemini 开源地址：https://github.com/openGemini
openGemini 公众号：
