错误日志
[2026-06-17 13:53:39.337401] WDIAG [PROXY] get_or_create_metric (ob_prometheus_processor.cpp:455) [28332][Y0-00007F9E88FF84D0] [lt=0] [dc=6] metric num reach limit, will discard and expire metric(metric_num=3001)
建议提问模板
【OBProxy】metric num reach limit 导致 CPU 持续偏高，如何调大 metric 上限？
环境：
- OBProxy 版本：4.3.5.0（CE）
- OB 版本：4.3.5.4
- 架构：3节点 OBProxy + Keepalived VIP
- 业务特征：单集群约 20+ 租户、数百个 schema（多站点 Web 业务）
现象：
OBProxy 运行约 158 天后，obproxy.log 持续刷以下警告，每分钟约 27 万条：
WDIAG [PROXY] get_or_create_metric (ob_prometheus_processor.cpp:455)
metric num reach limit, will discard and expire metric(metric_num=3000)
MASTER 节点 CPU 持续 350%+（80 核机器），PS Cache 条目数 3100 万+。
已尝试调整 sql_table_cache_expire_relative_time 为 30 分钟，无明显效果。
问题：
- metric_num_limit=3000 是否为硬编码？是否有参数可以调大？
- 后续版本是否已优化此问题？建议升级到哪个版本？
- 对于多 schema 场景，官方有什么最佳实践？
2 个赞
淇铭
#3
是ocp上的监控么？能具体截图看看监控的内容么？ocp的版本信息也发一下
– 在 proxysys 下执行
SHOW PROXYCONFIG LIKE ‘monitor_item%’;
SHOW PROXYCONFIG LIKE ‘enable_extra_prometheus_metric’;
SHOW PROXYCONFIG LIKE ‘enable_prometheus’;
- PROXYCONFIG 结果
– monitor_item 相关
monitor_item_max_idle_period = 30m (范围 [1m, 1d])
monitor_item_limit = 3000 (范围 [0, 10000])
– prometheus 相关
enable_extra_prometheus_metric = False
enable_prometheus = True
-
OBProxy 版本
obproxy (OceanBase 4.3.5.0)
5.7.25-OceanBase_CE-v4.3.5.4
-
OCP版本
版本号: 4.3.6-20250709105610
发布日期: 2025年7月9日
淇铭
#5
若确实需要细粒度监控，且内存可接受：
ALTER PROXYCONFIG SET monitor_item_limit = ‘5000’;
淇铭
#7
这是 OBProxy Prometheus 指标内存缓存满（默认 3000）的保护机制。若日志频繁出现，优先检查 enable_extra_prometheus_metric 是否开启、租户/schema 数量是否过多，再考虑调大 monitor_item_limit 或缩短 monitor_item_max_idle_period 。
