We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
请问MicroMeterCollector为何自己维护监控数据(GAUGE_CACHE),这样设计,我认为有两点小瑕疵: 1、需要创建定时任务(DtpMonitor#run),来更新GAUGE_CACHE。 2、如果定时任务的刷新时间monitorInterval与promethues配置的拉取时间不一致,可能会产生数据误差。
我的想法是,注册gauge的时候,直接传入线程池(或其监控数据获取包装类),这样,每当MetricRegistry想要获取监控数据时(触发线程池监控数据包装类::getCorePoolSize等操作),可以获取到最新的数据。
本人水平尚浅,可能思考不到位,还请大佬们赐教,谢谢。
The text was updated successfully, but these errors were encountered:
这是个好问题,原因是这样的,MetricRegistry内部维护gauge对象是用的WeakReference,当发生gc后就没了,就获取不到指标数据了,所以需要在外部有个StrongReference指向该对象。你说的数据误差肯定是有的,所有跑定时任务获取数据的,误差肯定也是避免不了,所以这个误差还好,可以接受。 希望能解答你的疑问!
Sorry, something went wrong.
No branches or pull requests
请问MicroMeterCollector为何自己维护监控数据(GAUGE_CACHE),这样设计,我认为有两点小瑕疵:
1、需要创建定时任务(DtpMonitor#run),来更新GAUGE_CACHE。
2、如果定时任务的刷新时间monitorInterval与promethues配置的拉取时间不一致,可能会产生数据误差。
我的想法是,注册gauge的时候,直接传入线程池(或其监控数据获取包装类),这样,每当MetricRegistry想要获取监控数据时(触发线程池监控数据包装类::getCorePoolSize等操作),可以获取到最新的数据。
本人水平尚浅,可能思考不到位,还请大佬们赐教,谢谢。
The text was updated successfully, but these errors were encountered: