我正在学习DropWizard Metrics库(以前的Coda Hale指标),我不知道什么时候应该使用Meters
vsTimers
。根据文档:
仪表:仪表测量一组事件发生的速率
以及:
计时器:计时器基本上是一种事件持续时间的直方图和它发生的速率的度量
基于这些定义,我无法区分它们之间的区别。让我困惑的是,计时器的使用方式与我预期的不同。对我来说,计时器就是:计时器;它应该测量开始和停止之间的时间差。但计时器似乎也能捕捉到事件发生的速率,这感觉就像他们踩在了米的脚趾上。
如果我能看到每个组件输出的示例,这可能会帮助我理解何时/何地使用其中任何一个组件。
您之所以感到困惑,部分是因为DW度量计时器是DW度量计。
仪表专门关注速率,以Hz(每秒事件)为单位。每个仪表都会产生4个(?)不同的指标被发布:
您可以通过在代码中的不同点记录一个值来使用Meter——DW Metrics会自动记下每个调用的挂壁时间以及您给出的值,并使用这些来计算该值增加的速率:
Meter getRequests = registry.meter("some-operation.operations")
getRequests.mark() //resets the value, e.g. sets it to 0
int numberOfOps = doSomeNumberOfOperations() //takes 10 seconds, returns 333
getRequests.mark(numberOfOps) //sets the value to number of ops.
我们预计速率为33.3 Hz,因为发生了333次操作,对mark()的两次调用之间的时间为10秒。
计时器计算上述4个指标(将每个计时器.上下文视为一个事件),并向其添加许多其他指标:
每个计时器大约报告15个总指标。
简而言之:计时器报告了很多指标,它们可能很难理解,但一旦你这样做了,它们就是发现尖峰行为的一种非常有效的方法。
事实是,仅仅收集两点之间的时间并不是一个非常有用的指标。考虑一下:您有这样一个代码块:
Timer timer = registry.timer("costly-operation.service-time")
Timer.Context context = timer.time()
costlyOperation() //service time 10 ms
context.stop()
让我们假设costlyOperation()
具有恒定的成本、恒定的负载,并且在单个线程上运行。在1分钟的报告期内,我们预计此操作将计时6000次。显然,我们不会通过6000x线报告实际服务时间——相反,我们需要某种方法来总结所有这些操作,以适合我们所需的报告窗口。DW Metrics的计时器每分钟自动为我们执行一次(我们的报告期)。5分钟后,我们的指标注册中心将报告:
现在,让我们考虑一下,我们进入了一个阶段,在这个阶段中,我们的运营有时会完全偏离轨道,并在很长一段时间内受阻:
Timer timer = registry.timer("costly-operation.service-time")
Timer.Context context = timer.time()
costlyOperation() //takes 10 ms usually, but once every 1000 times spikes to 1000 ms
context.stop()
在1分钟的收集时间内,我们现在看到的执行次数不到6000次,因为每执行1000次需要更长的时间。计算到大约5505次。在第一分钟(6分钟的总系统时间)之后,我们现在会看到:
如果你用图表显示,你会发现大多数请求(p50、p75、p99等)在10毫秒内完成,但是1000个请求中的一个(p99)在1秒内完成。这也可以被视为平均速率的略微降低(约2%)和1分钟平均值的大幅降低(近9%)。
如果你只看一段时间内的平均值(速率或持续时间),你永远不会发现这些尖峰——当用许多成功的操作平均时,它们会被拖入背景噪声中。同样,仅仅知道最大值也没有帮助,因为它不能告诉你最大值出现的频率。这就是为什么直方图是跟踪性能的强大工具,也是为什么DW Metrics的计时器同时发布速率和直方图。
我想知道“计数器”和“米”类维护的计数之间是否有区别?我也了解仪表测量速率,但我很好奇,如果同时有一个计数器和一个仪表更新(为计数器递增),我会认为这两个数字是相同的。我这个假设是错的吗?
我想使用DropWizard中的Guage指标来监控我的线程池大小。 据我所知,这是在间隔时间内自动完成的。但似乎我没有获得注册指标的任何监控数据。虽然我的应用程序中的其他指标(如计数器和计时器)工作得很好。 有人能帮助我哪里做错了吗? 谢谢。
我使用Dropwizard计量器来监控一个方法被调用的次数。Dropwizard度量工具记录度量的计数。我假设计数只会上升,但在我的特定场景中,我注意到有几个实例,计数器实际下降,然后又上升。为什么会发生这种情况?谢谢!
ScheduledExecutorService的推荐用途之一是直接替代Timer类,如许多主题中所述: Java定时器与执行器服务 TimerTask和Executors之间的差异。newScheduledThreadPool(1) scheduleAtFixedRate和scheduleAtFixedRate之间有什么区别 Android计时器计划与scheduleAtFixedRate 但是
谈到与StatsD相关的计数器,它的工作方式是你不断发布计数器的值,例如。请求 每当应用程序收到对 StatsD 守护程序的请求时。守护程序设置了刷新间隔,当它将此计数器在该时间段内的聚合推送到外部后端时。此外,它还将计数器重置为 0。 试图将其映射到Flink计数器。 Flink计数器只有inc和dec方法,因此在报告时间到来之前,应用程序可以调用inc或dec来更改计数器的值。 在报告计数器的
问题内容: 如何使进度条随着时间限制缓慢下降? 问题答案: 抱歉,我仍然找不到真正阅读您的代码的动机,只是根据问题将这个示例组合在一起。看看它是否给您一些想法。 请注意,这是一个SSCCE,总共仅使用40行代码。