【 使用环境 】生产环境
【 OB or 其他组件 】OBAgent
【 使用版本 】
oceanbase-ce-3.1.4-10000092022071511
obagent-1.1.2-9
【问题描述】
我们OB的监控从前段时间开始，突然没有数据了（prometheus那端的查询响应是 200，但是响应数据为空）。此前一直是正常的，期间没有做过配置上的变动，只是随着时间的推移，数据量的增长。
可能是obagent的性能问题？请问有什么办法恢复监控响应的数据吗？
【复现路径】问题出现前后相关操作
【附件及日志】
可以先手动请求下agent看是否有数据返回。顺便提供下agent的日志
可以获取下问题页面的url，进入ocp容器crul看看返回
用的是 obd 部署，没有使用 ocp。
看起来是有查询结果筛选后重复导致认为已经收集过所以返回结果为空。可以手动执行下对应sql看看结果，有哪些是重复项
select /*+ MONITOR_AGENT READ_CONSISTENCY(WEAK) */ tenant_id, mem_used, access_count, hit_count from v$plan_cache_stat
你好，谢谢支持！前些天比较忙，回复晚了。
SQL执行如下：
select /*+ MONITOR_AGENT READ_CONSISTENCY(WEAK) */ tenant_id, mem_used, access_count, hit_count from v$plan_cache_stat;
±----------±---------±-------------±----------+
| tenant_id | mem_used | access_count | hit_count |
±----------±---------±-------------±----------+
| 1 | 60744232 | 16881922 | 16647616 |
| 1001 | 1278576 | 474960 | 473492 |
| 1002 | 279328 | 15577 | 15185 |
| 1003 | 139632 | 7210 | 7028 |
±----------±---------±-------------±----------+
现在还是没有数据吗，之前看日志是查出来的记录有冲突，所以 prometheus exporter 的插件里直接报错没有数据，但是看查到的结果应该没问题，查询的这台observer就是 obagent 没有数据的那台吗
@chris-sun @阿绿 我们共有6台OB，只有一台 104 有数据（6台中，似乎只有这一台没有冲突的）：
101:
±----------±----------±-------------±------------+
| tenant_id | mem_used | access_count | hit_count |
±----------±----------±-------------±------------+
| 1 | 149385665 | 3755497526 | 3739643693 |
| 1001 | -26954752 | 39782044792 | 39769148408 |
| 1002 | 119104020 | 432581820 | 431903312 |
| 1003 | 3813572 | 7114405 | 7095649 |
| 1003 | 3813572 | 7114405 | 7095649 |
±----------±----------±-------------±------------+
5 rows in set (0.00 sec)
102:
±----------±----------±-------------±------------+
| tenant_id | mem_used | access_count | hit_count |
±----------±----------±-------------±------------+
| 1 | 57477408 | 1263543438 | 1259493154 |
| 1001 | -92542730 | 36086259062 | 36077138176 |
| 1002 | 8446624 | 762405610 | 761102088 |
| 1003 | 6112344 | 71224867 | 71023015 |
| 1003 | 6112344 | 71224867 | 71023015 |
| 1005 | 0 | 1 | 0 |
±----------±----------±-------------±------------+
6 rows in set (0.00 sec)
103:
±----------±---------±-------------±----------+
| tenant_id | mem_used | access_count | hit_count |
±----------±---------±-------------±----------+
| 1 | 47089168 | 349619691 | 346038520 |
| 1001 | 559136 | 7044338 | 7015624 |
| 1002 | 652912 | 249278 | 239606 |
| 1003 | 312512 | 133252 | 130672 |
| 1003 | 312512 | 133252 | 130672 |
±----------±---------±-------------±----------+
5 rows in set (0.00 sec)
104:
±----------±---------±-------------±----------+
| tenant_id | mem_used | access_count | hit_count |
±----------±---------±-------------±----------+
| 1 | 66111928 | 17543413 | 17300819 |
| 1001 | 3334416 | 488520 | 486984 |
| 1002 | 279328 | 15953 | 15549 |
| 1003 | 743136 | 7407 | 7216 |
±----------±---------±-------------±----------+
4 rows in set (0.01 sec)
105:
±----------±---------±-------------±----------+
| tenant_id | mem_used | access_count | hit_count |
±----------±---------±-------------±----------+
| 1 | 79722999 | 578887438 | 573043072 |
| 1001 | -534112 | 8129672 | 8095208 |
| 1002 | -409080 | 292622 | 281290 |
| 1003 | 217424 | 134206 | 131497 |
| 1003 | 217424 | 134206 | 131497 |
| 1005 | 3747208 | 15451915 | 15439943 |
±----------±---------±-------------±----------+
6 rows in set (0.00 sec)
106:
±----------±---------±-------------±----------+
| tenant_id | mem_used | access_count | hit_count |
±----------±---------±-------------±----------+
| 1 | 66304840 | 413937838 | 409771538 |
| 1001 | -923448 | 8086617 | 8050354 |
| 1002 | -528328 | 297346 | 286817 |
| 1003 | 312512 | 125981 | 123581 |
| 1003 | 312512 | 125981 | 123581 |
| 1005 | 0 | 2 | 1 |
±----------±---------±-------------±----------+
6 rows in set (0.00 sec)
请问下，这5台有冲突的，要如何处理？
这样的话，想避免这个问题只能修改一下 obagent 的采集语句了，加上 group by tenant_id
在 /home/admin/obagent/conf/module_config/monitor_ob.yaml, 修改之后需要重启一下 obagent
@June.Chen 你这个ob 版本太老了, 需要升级了, 现在我们3.x 的社区版内核已经不修bug, 问题只能在论坛上答疑
建议 赶紧升级到4.2.1.x 的版本, 4.2.1.x 是 推荐的稳定版
@chris-sun @longda 谢谢两位的支持，这个问题已经搞定了，修改了那句采集的SQL。
能否告知下，v$plan_cache_stat表中的重复记录可能是在什么情况下产生的？两条完全一样的记录，无法删除其中一条，如果两条都删除了，后面是否会再自动生成？
v$plan_cache_stat 这个是视图，OB 中 gv$ 或者 v$ 开头的表都是视图，一般都是基于 OB 内部表来展示出来的，不要进行修改，产生两个记录可能是老版本内核的问题，目前还是只能通过修改agent的配置来避免
