【 使用环境 】生产环境
【 OB or 其他组件 】OB
【 使用版本 】4.2.1
【问题描述】
ocp集群没有监控，别的业务集群是好的，怎么排查问题？
13 个赞
查看一下监控配置部分是否配置正确。
4 个赞
1 OCP 无法从 Prometheus 拉取监控数据，导致页面空白。
2 排查点：检查 Prometheus 服务是否正常运行、OB 采集器（Exporter）是否正常采集数据。
4 个赞
我这里只能确认机器上ps -ef|grep ocp_monagent是有的，还能怎么排查为什么没有监控数据吗
4 个赞
确定ocp metadb是正常的就检查下ocp_agent是不是没把数据采集到，看看相关日志
4 个赞
666
5 个赞
具体是指哪里的日志呀？
4 个赞
– 各 OB 节点
ps -ef | grep ocp_agent
–OCP 主机管理 → 对应主机 → Agent 状态是否为「正常」
打开开发者模式 找到对应的api的traceid 提供一下 把ocp-server.log发一下
3 个赞
ps -ef | grep ocp_agent
确认都是有的
主机->对应主机->agent状态也都是正常的：
然后你这个租户监控top5的界面没找到在哪里点出来，我在集群监控里瞎点点到了个好像差不多的top?startxxx先截了个图
2 个赞
你都点一下访问的API看看状态是不是都是200 看着前端访问是成功的 看着返回 data: [] ，问题在采集或存储上 节点上查 ocp_agent 日志是否有 SQL 采集 / 写 Prometheus 报错
2 个赞
/home/admin/ocp_agent/log/monagent.log 里有这个报错，是否有关
2026-06-11T10:09:12.28149+08:00 ERROR [72471,] caller=mysql/table_input.go:547:doCollect: collect table err: Error 1146 (42S02): Table ‘oceanbase.V$OB_TENANT_RESOURCE_LIMIT’ doesn’t exist fields: name=ob_resource_limit, duration=“773.033µs”
2026-06-11T10:09:27.28114+08:00 WARN [72471,] caller=mysql/table_input.go:415:collectData: collect ob_resource_limit, sql: select tenant_id, svr_ip, resource_name, sum(current_utilization) as count from V$OB_TENANT_RESOURCE_LIMIT group by tenant_id,svr_ip,resource_name, err: Error 1146 (42S02): Table ‘oceanbase.V$OB_TENANT_RESOURCE_LIMIT’ doesn’t exist
3 个赞
整个日志信息 提供一下
2 个赞
想刚回复你。。你就找到了 
3 个赞
–在任意 OB 节点看 Agent 是否已有租户指标：
curl -s “http://obip地址:62889/metrics/ob/basic” | grep -E “sql_all_count|stat_id.*40000” | head
–在 OCP 查 exporter 注册（MetaDB）：
SELECT id, exporter_type, job_name, instance, scrape_interval, status
FROM ocp_exporter_address
WHERE instance LIKE ‘%62889%’
OR instance LIKE ‘%metrics/ob%’;
2 个赞
curl -s “http://172.20.85.118:62889/metrics/ob/basic” | grep -E “sql_all_count|stat_id.*40000” | head
这个没结果
SELECT id, exporter_type, job_name, instance, scrape_interval, status FROM ocp_exporter_address WHERE instance LIKE ‘%62889%’ or instance LIKE ‘%metrics/ob%’
这个数据有很多，我又加了个ocp自身集群的ip：
obclient(root@ocp_meta)[meta_database]> SELECT id, exporter_type, job_name, instance, scrape_interval, status FROM ocp_exporter_address WHERE (instance LIKE ‘%62889%’ or instance LIKE ‘%metrics/ob%’) and (instance like ‘%172.20.85.116%’ or instance like ‘%172.20.85.117%’ or instance like ‘%172.20.85.118%’);
±--------±--------------±---------±---------------------------------------------±----------------±-------+
| id | exporter_type | job_name | instance | scrape_interval | status |
±--------±--------------±---------±---------------------------------------------±----------------±-------+
| 4001283 | HOST_MONITOR | ob | http://172.20.85.116:62889/metrics/node/host | 1 | active |
| 4001285 | AGENT_MONITOR | ob | http://172.20.85.116:62889/metrics/stat | 5 | active |
| 4001286 | HOST_MONITOR | ob | http://172.20.85.117:62889/metrics/node/host | 1 | active |
| 4001287 | AGENT_MONITOR | ob | http://172.20.85.117:62889/metrics/stat | 5 | active |
| 4001289 | HOST_MONITOR | ob | http://172.20.85.118:62889/metrics/node/host | 1 | active |
| 4001291 | AGENT_MONITOR | ob | http://172.20.85.118:62889/metrics/stat | 5 | active |
±--------±--------------±---------±---------------------------------------------±----------------±-------+
6 rows in set (0.005 sec)
1 个赞
我对比了一台正常机器的有9条instance数据：
/metrics/node/host
/metrics/stat
/metrics/node/logproxy
/metrics/logproxy
/metrics/node/ob
/metrics/ob/basic
/metrics/ob/extra
/metrics/obproxy
/metrics/node/obproxy
但是我ocp机器上的只有2条：
/metrics/node/host
/metrics/stat
1 个赞
SELECT id, exporter_type, job_name, instance, scrape_interval, status FROM ocp_exporter_address WHERE instance LIKE ‘%62889%’ or instance LIKE ‘%metrics/ob%’
就按照这个查看 这个可以看到是否有ob集群ip地址的信息 是否有问题 查出来 保存在txt中 发出来
1 个赞
分析来看116/117/118/138 未能拉取/metrics/ob/basic数据 应该是注册有问题 116/117/118/138 只有前两类 exporter，说明这些主机在 OCP 里 很可能没有正确挂上 OB_CLUSTER 服务，或 Agent 接管/重装时 OB exporter 注册失败。
1 个赞