tikv状态接口输出metric过多，请问如何优化呢？

[DBRE]

tikv状态接口输出metric过多，请问如何优化呢？

带来的问题：
1、prometheus数据存储量大
2、prometheus获取tikv metric超时，8个tikv实际上只有3个tikv有数据，详细说明可以见这个帖子：Grafana展示tikv数量不对，如何解决？

找了一个tikv输出到了文本，耗时22秒，文本186M, 共2534332行
其中
tikv_thread_nonvoluntary_context_switches有503907行
tikv_thread_voluntary_context_switches有503907行
tikv_threads_io_bytes_total有1007806行
tikv_thread_cpu_seconds_total有503911行

[WalterWj (王军 - PingCAP)]

理论上不应该这么多的，感觉有点问题啊。

[DBRE]

是的，其他tidb集群都没有这么多。

[buddyyuan]

这几个指标确实会有泄漏的问题。

workground：

metric_relabel_configs:

• source_labels: [name]
  separator: ;
  regex: tikv_thread_nonvoluntary_context_switches|tikv_thread_voluntary_context_switches|tikv_threads_io_bytes_total
  action: drop
• source_labels: [name,name]
  separator: ;
  regex: tikv_thread_cpu_seconds_total;(tokio|rocksdb).+
  action: drop

[buddyyuan]

修改 prometheus 的配置。 action 动作仅会对新数据有效果，老数据的删除可以配合 Prometheus 参数 --storage.tsdb.retention 来完全清理掉；

[DBRE]

这个我们已经添加了，但是仅能解决存储的问题，没有解决8个tikv实际只采集到3个tikv数据的问题

[buddyyuan]

你的那三个 tikv 有没有重启过。

[DBRE]

没有重启过，都运行很长时间了

[DBRE]

哪位大佬帮看下，感谢

[zzzzzz (Tz)]

https://docs.pingcap.com/zh/tidb/stable/tidb-monitoring-api#使用-metrics-接口

几个没有采到的节点有状态返回么？
node exporter 进程都正常么？

[DBRE]

1、curl -s “http://${tikv_ip}:${tikv_status_port}/metrics”是有输出的，但是返回时间在几十秒到分钟级，输出内容的描述见上面帖子描述。
2、node exporter正常的，但是tikv-server的metric采集，这个跟node-exporter没有关系吧, 是prometheus配置job采集的。

[DBRE]

curl -s “http://${tikv_ip}:${tikv_status_port}/metrics”输出内容多应该是导致prometheus job时间长的原因，但是为何输出多呢？这个集群与其他集群不同的地方就是多了分区表

[DBRE]

tikv重启后，获取metrics正常了，果然是重启大法好

[swino]

神功护体

[有猫万事足]

这问题我在7.3也碰到过。

你只是觉得tikv metrics慢，说明你的prometheus机器不错。
我这边有这个状况的时候，prometheus早就开始反复重启了。

后来把prometheus targets界面扫了一遍，才发现是有个pd 的metrics接口Scrape Duration是分钟级的，直接调用能返回1g数据。
最后也是重启这个出问题的pd解决的。

[DBRE]

跟prometheus机器没有关系，我们prometheus也只是8c16G的虚拟机。是因为读取tikv metrics多，prometheus已经读取metrics超时了，也就没有存储数据，prometheus自然也没有存储压力和性能压力了，这样带来的问题就是Grafana看不到对应tikv节点的监控数据了

[andone (Ti D Ber Lq Q Mt Rp V)]

重启包治百病