metrics

metrics copied to clipboard

CachedMetricSet refreshIfNecessary 这个方法的前提条件是lastCollectTime 永远小于clock，但对于异常情况会出现lastCollectTime 大于clock，那么在这段时间内数据不会收集  比如初始化的时候时间是2022/04/06 17:40 ,但是经过时间同步后时间变为 2022/04/06 09:40,那么 09:40~17:40这段时间数据不会被收集

yuexc1235

metrics时是一套打点规范吗？以http的方式到处指标之后，会有想prometheus类似的组件去抓群存储，以供用户查看吗 ？

3

weenxin

.travis.yml does not cache dependencies

5

Travis CI can cache content that does not often change, to speed up your build process.

chenzhang22

revert >> issues: #17

2

under windows operating system error path like : file:/C:/xx....

taneg

revert >> issues: #17

3

under windows operating system error path like : file:/C:/xx....

taneg

Metrics命名规范：“不要使用太多的tag， 一般而言4-5个已经足够”，假设我想根据某个应用指标比如A，根据值进行统计，这个A指标有几十个不同的值，例如值为1-100，想统计调用里1的调用qps,2的统计qps.....，如果使用tag的话，则为*.qps{A=1,A=2...}，这个是否支持呢，是否有其它比较好方式呢？

dpcdpf

线上使用fastcompass 统计cache命中率时出现很多统计错误

3

线上使用fastcompass 统计cache命中率时出现很多统计错误，相应的测试代码如下： public void execute() { long startTime = System.currentTimeMillis(); boolean isSuccess = false; try { TimeUnit.MICROSECONDS.sleep(1000); //do business staff...... //isSuccess = true; } catch (Exception e) { //....... }...

bjo2008cnx

关于线程池监控的一个PR

4

线程池指标监控采集的Timer内置的HistogramImpl的Reservoir类型为EXPONENTIALLY_DECAYING 如果强制要求Reservoir类型为EXPONENTIALLY_DECAYING感觉不太合理，因为作为指标采集方来说我可能更加关注的是线程池每分钟处理业务的耗时峰值，最小值，平均值等，所以希望通过重载Timer的构造方法实现由业务方决定Reservoir的类型。并且我希望在采集线程池的时候修改指标级别或者添加一些自定义TAG，所以新加了个重载的构造方法

RobertoHuang

Counter是一直不停累加，如果需要按period累加，如何实现呢？

2

Counter是一直不停累加，如果需要按period累加，如何实现呢？比始，对每分钟的数据进行sum，再在每分钟上sum的基础上，对每小时的数据sum。

bjo2008cnx

CollectLevel is invalid in FileMetricManagerReporter

2

public Builder withCollectLevel(CollectLevel level) { this.collectLevel = collectLevel; return this; } CollectLevel is invalid in FileMetricManagerReporter

dawn2zhang