通过operator部署的promethues节点磁盘占用过多，10天数据占80G,麻烦各位大神帮忙解决下

🪐 TiDB 技术问题
1

【概述】场景+问题概述
线上一个集群的Prometheus的/data目录磁盘占用量大概80G上下，数据保存天数设置为10天。其他集群只有十几G
【背景】做过哪些操作
通过curl http://127.0.0.1:9090/api/v1/status/runtimeinfo得到
{“status”:“success”,“data”:{“startTime”:“2021-06-07T06:45:29.552027184Z”,“CWD”:"/prometheus",“reloadConfigSuccess”:true,“lastConfigTime”:“2021-06-07T06:50:23Z”,“chunkCount”:4317524,“timeSeriesCount”:1302162,“corruptionCount”:0,“goroutineCount”:88,“GOMAXPROCS”:92,“GOGC”:"",“GODEBUG”:"",“storageRetention”:“10d”}}

正常的集群:

{“status”:“success”,“data”:{“startTime”:“2021-04-27T08:02:17.539869483Z”,“CWD”:"/prometheus",“reloadConfigSuccess”:true,“lastConfigTime”:“2021-04-27T08:02:17Z”,“chunkCount”:838383,“timeSeriesCount”:209605,“corruptionCount”:0,“goroutineCount”:83,“GOMAXPROCS”:92,“GOGC”:"",“GODEBUG”:"",“storageRetention”:“15d”}}
【现象】业务和数据库现象

【业务影响】
监控磁盘占用量过高
【TiDB 版本】
4.0.8

麻烦帮忙定位一下，或者介绍下怎么看Prometheus里存了什么？哪些指标导致占用了多大空间。

1 个赞
2

prometheus 里面存储的是 tidb cluster 中的 metric。
看了一下是 Prometheus TSDB 中的 chunk 数量相差很多。
猜测这个可能是因为数据频繁变化导致压缩率不同导致的。
可以考考虑备份或者调小 retention 的时间。
或者咨询一下 prometheus 社区，个人建议可以尝试看一下 prometheus 的 storage.local.max-chunks-to-persist 参数。

1 个赞
3

还有如果 prometheus 里面的数据量是比较大的，超过了您这面的预期，是不是可以考虑降低一下 prometheus 的采样。scrape_interval 参数看一下。我觉得采样率不用那么频繁。

1 个赞
4

是tidb-operator创建的Prometheus，基本上两套环境都是标准化的，在那里配置导致的差距差很多？

1 个赞
5

两套环境都是 tidb-operator 吗

1 个赞
6

想了解的是同样数量的tidb、tikv、pd，然后为什么这两个的Prometheus的监控数据差别那么多。

1 个赞
7

对，都是operator部署的。采集频率应该也是一样的，我看了下配置好像是15秒。指标数按理说也应该是一样的

1 个赞
8

两套环境的结点数量是一样的吗

1 个赞
9

一样的

1 个赞
11

你这一条回答可能是问题的关键，Prometheus采集的指标和tidb表的结构有关吗?举例说下？

1 个赞
12

抱歉，和表结构没有关系。

1 个赞
13

哦~那两个集群的哪些方面的不同会影响到监控？
或者说Prometheus有没有办法看到哪些指标占用的磁盘空间较大?

1 个赞
14
  1. 可能是流量的问题。流量不同导致了两套集群的数据变化量是不一样的。这里会涉及到数据压缩的问题。
  2. 怀疑是 prometheus 的参数配置不同。需要对比一下 prometheus 的参数配置。
15

在 prometheus 里面看一下这个值吧
count by (name)({name=~“.+”}) > 10000

16

这个命令怎么执行？

/data/prometheus $ wget http://127.0.0.1:9090/query?query='count by (name)({name=~".+"}) > 10000'
Connecting to 127.0.0.1:9090 (127.0.0.1:9090)
wget: server returned error: HTTP/1.1 400 Bad Request
17

直接在 prometheus 的界面里面执行吧。

18

{“status”:“success”,“data”:{“resultType”:“vector”,“result”:[{“metric”:{“name”:“rocksdb:low3”},“value”:[1623140881.681,“10110”]},{“metric”:{“name”:“rocksdb:low2”},“value”:[1623140881.681,“10425”]},{“metric”:{“name”:“tokio_runtime_w”},“value”:[1623140881.681,“1163407”]},{“metric”:{“name”:“rocksdb:low5”},“value”:[1623140881.681,“10143”]}]}}

19

另外一个只有{“status”:“success”,“data”:{“resultType”:“vector”,“result”:[{“metric”:{“name”:“tokio_runtime_w”},“value”:[1623140881.681,“154568”]}]}}

所以说，问题出在rockdb:low3 roksdb:low2 rocksdb:low5 ?

这几个指标什么意思？什么情况下会大量上报？怎么解决?

20

@懂的都懂

21

这个是查看有哪些指标超过了 10000 条
是数据的采集量导致了 prometheus 条数不同。
这个可能是因为流量的变化导致了存储数据的压缩问提。
这两套集群的流量差距很大吗