You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicecomb.apache.org by 郑扬勇 <ya...@qq.com> on 2017/12/22 09:55:17 UTC
[Discussion]Java Chassis Metrics Data Collection and Provide Strategy
Hi All：
We all know there are two major type of metric :
1.Time-unrelated,you can get the latest value any time immediately:
Counter -> increase or decrease
Guage -> set a certain one value
2.Time-related,only after a centain time pass you can compute the right value,"a centain time" may can called SampleTime or WindowTime
Max & Min -> the max value or min value in a centain time
Average -> average value, the simplest algorithm is f = sum / count
Rate -> like TPS,algorithm is f = sum / second
In current version (0.6.0-SNAPSHOT),we had integrated with netflix servo (0.10.1),about servo more information can be found here : https://github.com/Netflix/servo/wiki/Getting-Started
There are two strategy to provider finnal collected metrics data to end user :
1.Direct correct metrics data per Call and return
Use this strategy,user will always get latest Time-unrelated type metric (Counter and Guage) value and correct time-related type metric value,THE ONLY PROBLEM IS, if end user stop polling over a one WindowTime ,the next polling will return all metrics value with 0 ,because servo monitor can't know the precise value of previous step and only thing can do is "reset".
for example in this case if user close Front UI and reopen later for a moment,the first polling will get all value of 0 (but will recovery to correct after one WindowTime)
2.Setup a Thread in producer for polling metrics and cache latest in memory,let user get the cache value when called
Use this strategy, the problem of the first strategy will be resolved,but NEW PROBLE IS,end user only can get previous step collect Time-unrelated type metrics (Counter and Guage) value,not latest value,this data may delayed.
Which one is better ? also we can mix two of them : get cached ,then update Time-unrelated type metrics value ,then return,but this way the cost will be highest.
Best Regards & Thanks!
回复： Reply：[Discussion]Java Chassis Metrics Data Collection and Provide Strategy
Posted by 郑扬勇 <ya...@qq.com>.
OK,I will try to complete this work in https://issues.apache.org/jira/browse/SCB-11
------------------ 原始邮件 ------------------
发件人: "willem.jiang";<wi...@gmail.com>;
发送时间: 2017年12月23日(星期六) 中午11:41
收件人: "dev"<de...@servicecomb.apache.org>;
主题: Re: Reply：[Discussion]Java Chassis Metrics Data Collection and Provide Strategy
Hi Yangyong,
We could treat the webpublisher as a Poller, but it could be challenge for
us to resolve the "Polling interval" issue as you mentioned.
Willem Jiang
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Sat, Dec 23, 2017 at 10:59 AM, 郑扬勇 <ya...@qq.com> wrote:
> Servo monitors don't setup any thread for statics at backend,only record
> data and time,"Polling Intervals" is only a setting let monitor know
> whether in right time window when polling and calculate.
> So "metric can be only updated by the poller" is right, we may let
> consumer act as poller ,first time poll result is not so precise may not a
> big problem.
> Current we can't know user exactly scenario so may make it simple and
> can improve it further.
>
>
>
> ------------------ 原始邮件 ------------------
> 发件人: "willem.jiang";<wi...@gmail.com>;
> 发送时间: 2017年12月23日(星期六) 上午10:37
> 收件人: "dev"<de...@servicecomb.apache.org>;
>
> 主题: Re: Reply：[Discussion]Java Chassis Metrics Data Collection and
> Provide Strategy
>
>
>
> If the metric can access the monitor data (Counter or Guage) directly. we
> could get a real time counter result.
> But if the metric can be only updated by the poller, you have to bear with
> first round 0 metrics value.
>
> We cannot count on the client side work, so we still need to keep polling
> the metric ourselves
>
> I just found something interesting from the servo document. It look like
> Servo's metric is used to send the data to the back end, not for the
> Restful service client which is keeping pulling . We should find a way to
> export the Counter data directly here.
>
> "Some policies determine the set of metrics (potentially aggregated using
> some function like sum or count) that will be sent to our backend. The fast
> polling interval will only send a very small number of metrics per machine
> (what we consider critical metrics) and usually all the metrics collected
> during the slow polling interval will be sent to a different set of
> backends. "
>
>
> Willem Jiang
>
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.iteye.com (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Sat, Dec 23, 2017 at 9:17 AM, 郑扬勇 <ya...@qq.com> wrote:
>
> > Hi all:
> > I'll use first Strategy "Direct correct metrics data per Call and
> > return" current,because is simple and act same as Servo original.
> > any question or good idea is wellcome
> >
> > Best Regards & Thanks
> > zhengyangyong
> > ------------------ 原始邮件 ------------------
> > 发件人: "郑扬勇";<ya...@qq.com>;
> > 发送时间: 2017年12月22日(星期五) 下午5:55
> > 收件人: "dev"<de...@servicecomb.apache.org>;
> >
> > 主题: [Discussion]Java Chassis Metrics Data Collection and Provide
> Strategy
> >
> >
> >
> > Hi All：
> > We all know there are two major type of metric :
> > 1.Time-unrelated,you can get the latest value any time immediately:
> > Counter -> increase or decrease
> > Guage -> set a certain one value
> > 2.Time-related,only after a centain time pass you can compute the right
> > value,"a centain time" may can called SampleTime or WindowTime
> > Max & Min -> the max value or min value in a centain time
> > Average -> average value, the simplest algorithm is f = sum / count
> > Rate -> like TPS,algorithm is f = sum / second
> >
> > In current version (0.6.0-SNAPSHOT),we had integrated with netflix
> > servo (0.10.1),about servo more information can be found here :
> > https://github.com/Netflix/servo/wiki/Getting-Started
> >
> > There are two strategy to provider finnal collected metrics data to
> end
> > user :
> > 1.Direct correct metrics data per Call and return
> > Use this strategy,user will always get latest Time-unrelated type metric
> > (Counter and Guage) value and correct time-related type metric value,THE
> > ONLY PROBLEM IS, if end user stop polling over a one WindowTime ,the next
> > polling will return all metrics value with 0 ,because servo monitor can't
> > know the precise value of previous step and only thing can do is "reset".
> > for example in this case if user close Front UI and reopen later for a
> > moment,the first polling will get all value of 0 (but will recovery to
> > correct after one WindowTime)
> > 2.Setup a Thread in producer for polling metrics and cache latest in
> > memory,let user get the cache value when called
> > Use this strategy, the problem of the first strategy will be
> resolved,but
> > NEW PROBLE IS,end user only can get previous step collect Time-unrelated
> > type metrics (Counter and Guage) value,not latest value,this data may
> > delayed.
> >
> > Which one is better ? also we can mix two of them : get cached ,then
> > update Time-unrelated type metrics value ,then return,but this way the
> cost
> > will be highest.
> >
> > Best Regards & Thanks!
>
Re: Reply：[Discussion]Java Chassis Metrics Data Collection and Provide Strategy
Posted by Willem Jiang <wi...@gmail.com>.
Hi Yangyong,
We could treat the webpublisher as a Poller, but it could be challenge for
us to resolve the "Polling interval" issue as you mentioned.
Willem Jiang
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Sat, Dec 23, 2017 at 10:59 AM, 郑扬勇 <ya...@qq.com> wrote:
> Servo monitors don't setup any thread for statics at backend,only record
> data and time,"Polling Intervals" is only a setting let monitor know
> whether in right time window when polling and calculate.
> So "metric can be only updated by the poller" is right, we may let
> consumer act as poller ,first time poll result is not so precise may not a
> big problem.
> Current we can't know user exactly scenario so may make it simple and
> can improve it further.
>
>
>
> ------------------ 原始邮件 ------------------
> 发件人: "willem.jiang";<wi...@gmail.com>;
> 发送时间: 2017年12月23日(星期六) 上午10:37
> 收件人: "dev"<de...@servicecomb.apache.org>;
>
> 主题: Re: Reply：[Discussion]Java Chassis Metrics Data Collection and
> Provide Strategy
>
>
>
> If the metric can access the monitor data (Counter or Guage) directly. we
> could get a real time counter result.
> But if the metric can be only updated by the poller, you have to bear with
> first round 0 metrics value.
>
> We cannot count on the client side work, so we still need to keep polling
> the metric ourselves
>
> I just found something interesting from the servo document. It look like
> Servo's metric is used to send the data to the back end, not for the
> Restful service client which is keeping pulling . We should find a way to
> export the Counter data directly here.
>
> "Some policies determine the set of metrics (potentially aggregated using
> some function like sum or count) that will be sent to our backend. The fast
> polling interval will only send a very small number of metrics per machine
> (what we consider critical metrics) and usually all the metrics collected
> during the slow polling interval will be sent to a different set of
> backends. "
>
>
> Willem Jiang
>
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.iteye.com (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Sat, Dec 23, 2017 at 9:17 AM, 郑扬勇 <ya...@qq.com> wrote:
>
> > Hi all:
> > I'll use first Strategy "Direct correct metrics data per Call and
> > return" current,because is simple and act same as Servo original.
> > any question or good idea is wellcome
> >
> > Best Regards & Thanks
> > zhengyangyong
> > ------------------ 原始邮件 ------------------
> > 发件人: "郑扬勇";<ya...@qq.com>;
> > 发送时间: 2017年12月22日(星期五) 下午5:55
> > 收件人: "dev"<de...@servicecomb.apache.org>;
> >
> > 主题: [Discussion]Java Chassis Metrics Data Collection and Provide
> Strategy
> >
> >
> >
> > Hi All：
> > We all know there are two major type of metric :
> > 1.Time-unrelated,you can get the latest value any time immediately:
> > Counter -> increase or decrease
> > Guage -> set a certain one value
> > 2.Time-related,only after a centain time pass you can compute the right
> > value,"a centain time" may can called SampleTime or WindowTime
> > Max & Min -> the max value or min value in a centain time
> > Average -> average value, the simplest algorithm is f = sum / count
> > Rate -> like TPS,algorithm is f = sum / second
> >
> > In current version (0.6.0-SNAPSHOT),we had integrated with netflix
> > servo (0.10.1),about servo more information can be found here :
> > https://github.com/Netflix/servo/wiki/Getting-Started
> >
> > There are two strategy to provider finnal collected metrics data to
> end
> > user :
> > 1.Direct correct metrics data per Call and return
> > Use this strategy,user will always get latest Time-unrelated type metric
> > (Counter and Guage) value and correct time-related type metric value,THE
> > ONLY PROBLEM IS, if end user stop polling over a one WindowTime ,the next
> > polling will return all metrics value with 0 ,because servo monitor can't
> > know the precise value of previous step and only thing can do is "reset".
> > for example in this case if user close Front UI and reopen later for a
> > moment,the first polling will get all value of 0 (but will recovery to
> > correct after one WindowTime)
> > 2.Setup a Thread in producer for polling metrics and cache latest in
> > memory,let user get the cache value when called
> > Use this strategy, the problem of the first strategy will be
> resolved,but
> > NEW PROBLE IS,end user only can get previous step collect Time-unrelated
> > type metrics (Counter and Guage) value,not latest value,this data may
> > delayed.
> >
> > Which one is better ? also we can mix two of them : get cached ,then
> > update Time-unrelated type metrics value ,then return,but this way the
> cost
> > will be highest.
> >
> > Best Regards & Thanks!
>
回复： Reply：[Discussion]Java Chassis Metrics Data Collection and Provide Strategy
Posted by 郑扬勇 <ya...@qq.com>.
I had delete my Producer side poller and cache code in PR : https://github.com/apache/incubator-servicecomb-java-chassis/pull/451
- long minPollingTime = DynamicPropertyFactory.getInstance().getLongProperty(METRICS_POLLING_MIN, 100).get();
System.getProperties().setProperty("servo.pollers", pollingSettings);
-
- List<Long> intervals = Pollers.getPollingIntervals();
- List<Long> appliedIntervals = new ArrayList<>();
- for (int index = 0; index < intervals.size(); index++) {
- int finalIndex = index;
- long finalInterval = intervals.get(finalIndex) < minPollingTime ? minPollingTime : intervals.get(finalIndex);
- long pollerInterval = (long) (finalInterval * 0.5);
- final Runnable poller = () -> reloadRegistryMetric(finalIndex);
- Executors.newScheduledThreadPool(1)
- //for step counter correct work we need poll in time ,otherwise current step will return Datapoint.UNKNOWN (missing last sample)
- .scheduleWithFixedDelay(poller, pollerInterval, pollerInterval, MILLISECONDS);
- appliedIntervals.add(finalInterval);
- }
- this.appliedPollingIntervals = appliedIntervals;
because Servo is push mode ,now metric Consumer will act as Poller and push data to it's target such as UI or log system
Best Regards & Thanks!
------------------ 原始邮件 ------------------
发件人: "郑扬勇";<ya...@qq.com>;
发送时间: 2017年12月23日(星期六) 上午10:59
收件人: "dev"<de...@servicecomb.apache.org>;
主题: 回复： Reply：[Discussion]Java Chassis Metrics Data Collection and Provide Strategy
Servo monitors don't setup any thread for statics at backend,only record data and time,"Polling Intervals" is only a setting let monitor know whether in right time window when polling and calculate.
So "metric can be only updated by the poller" is right, we may let consumer act as poller ,first time poll result is not so precise may not a big problem.
Current we can't know user exactly scenario so may make it simple and can improve it further.
------------------ 原始邮件 ------------------
发件人: "willem.jiang";<wi...@gmail.com>;
发送时间: 2017年12月23日(星期六) 上午10:37
收件人: "dev"<de...@servicecomb.apache.org>;
主题: Re: Reply：[Discussion]Java Chassis Metrics Data Collection and Provide Strategy
If the metric can access the monitor data (Counter or Guage) directly. we
could get a real time counter result.
But if the metric can be only updated by the poller, you have to bear with
first round 0 metrics value.
We cannot count on the client side work, so we still need to keep polling
the metric ourselves
I just found something interesting from the servo document. It look like
Servo's metric is used to send the data to the back end, not for the
Restful service client which is keeping pulling . We should find a way to
export the Counter data directly here.
"Some policies determine the set of metrics (potentially aggregated using
some function like sum or count) that will be sent to our backend. The fast
polling interval will only send a very small number of metrics per machine
(what we consider critical metrics) and usually all the metrics collected
during the slow polling interval will be sent to a different set of
backends. "
Willem Jiang
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Sat, Dec 23, 2017 at 9:17 AM, 郑扬勇 <ya...@qq.com> wrote:
> Hi all:
> I'll use first Strategy "Direct correct metrics data per Call and
> return" current,because is simple and act same as Servo original.
> any question or good idea is wellcome
>
> Best Regards & Thanks
> zhengyangyong
> ------------------ 原始邮件 ------------------
> 发件人: "郑扬勇";<ya...@qq.com>;
> 发送时间: 2017年12月22日(星期五) 下午5:55
> 收件人: "dev"<de...@servicecomb.apache.org>;
>
> 主题: [Discussion]Java Chassis Metrics Data Collection and Provide Strategy
>
>
>
> Hi All：
> We all know there are two major type of metric :
> 1.Time-unrelated,you can get the latest value any time immediately:
> Counter -> increase or decrease
> Guage -> set a certain one value
> 2.Time-related,only after a centain time pass you can compute the right
> value,"a centain time" may can called SampleTime or WindowTime
> Max & Min -> the max value or min value in a centain time
> Average -> average value, the simplest algorithm is f = sum / count
> Rate -> like TPS,algorithm is f = sum / second
>
> In current version (0.6.0-SNAPSHOT),we had integrated with netflix
> servo (0.10.1),about servo more information can be found here :
> https://github.com/Netflix/servo/wiki/Getting-Started
>
> There are two strategy to provider finnal collected metrics data to end
> user :
> 1.Direct correct metrics data per Call and return
> Use this strategy,user will always get latest Time-unrelated type metric
> (Counter and Guage) value and correct time-related type metric value,THE
> ONLY PROBLEM IS, if end user stop polling over a one WindowTime ,the next
> polling will return all metrics value with 0 ,because servo monitor can't
> know the precise value of previous step and only thing can do is "reset".
> for example in this case if user close Front UI and reopen later for a
> moment,the first polling will get all value of 0 (but will recovery to
> correct after one WindowTime)
> 2.Setup a Thread in producer for polling metrics and cache latest in
> memory,let user get the cache value when called
> Use this strategy, the problem of the first strategy will be resolved,but
> NEW PROBLE IS,end user only can get previous step collect Time-unrelated
> type metrics (Counter and Guage) value,not latest value,this data may
> delayed.
>
> Which one is better ? also we can mix two of them : get cached ,then
> update Time-unrelated type metrics value ,then return,but this way the cost
> will be highest.
>
> Best Regards & Thanks!
回复： Reply：[Discussion]Java Chassis Metrics Data Collection and Provide Strategy
Posted by 郑扬勇 <ya...@qq.com>.
Servo monitors don't setup any thread for statics at backend,only record data and time,"Polling Intervals" is only a setting let monitor know whether in right time window when polling and calculate.
So "metric can be only updated by the poller" is right, we may let consumer act as poller ,first time poll result is not so precise may not a big problem.
Current we can't know user exactly scenario so may make it simple and can improve it further.
------------------ 原始邮件 ------------------
发件人: "willem.jiang";<wi...@gmail.com>;
发送时间: 2017年12月23日(星期六) 上午10:37
收件人: "dev"<de...@servicecomb.apache.org>;
主题: Re: Reply：[Discussion]Java Chassis Metrics Data Collection and Provide Strategy
If the metric can access the monitor data (Counter or Guage) directly. we
could get a real time counter result.
But if the metric can be only updated by the poller, you have to bear with
first round 0 metrics value.
We cannot count on the client side work, so we still need to keep polling
the metric ourselves
I just found something interesting from the servo document. It look like
Servo's metric is used to send the data to the back end, not for the
Restful service client which is keeping pulling . We should find a way to
export the Counter data directly here.
"Some policies determine the set of metrics (potentially aggregated using
some function like sum or count) that will be sent to our backend. The fast
polling interval will only send a very small number of metrics per machine
(what we consider critical metrics) and usually all the metrics collected
during the slow polling interval will be sent to a different set of
backends. "
Willem Jiang
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Sat, Dec 23, 2017 at 9:17 AM, 郑扬勇 <ya...@qq.com> wrote:
> Hi all:
> I'll use first Strategy "Direct correct metrics data per Call and
> return" current,because is simple and act same as Servo original.
> any question or good idea is wellcome
>
> Best Regards & Thanks
> zhengyangyong
> ------------------ 原始邮件 ------------------
> 发件人: "郑扬勇";<ya...@qq.com>;
> 发送时间: 2017年12月22日(星期五) 下午5:55
> 收件人: "dev"<de...@servicecomb.apache.org>;
>
> 主题: [Discussion]Java Chassis Metrics Data Collection and Provide Strategy
>
>
>
> Hi All：
> We all know there are two major type of metric :
> 1.Time-unrelated,you can get the latest value any time immediately:
> Counter -> increase or decrease
> Guage -> set a certain one value
> 2.Time-related,only after a centain time pass you can compute the right
> value,"a centain time" may can called SampleTime or WindowTime
> Max & Min -> the max value or min value in a centain time
> Average -> average value, the simplest algorithm is f = sum / count
> Rate -> like TPS,algorithm is f = sum / second
>
> In current version (0.6.0-SNAPSHOT),we had integrated with netflix
> servo (0.10.1),about servo more information can be found here :
> https://github.com/Netflix/servo/wiki/Getting-Started
>
> There are two strategy to provider finnal collected metrics data to end
> user :
> 1.Direct correct metrics data per Call and return
> Use this strategy,user will always get latest Time-unrelated type metric
> (Counter and Guage) value and correct time-related type metric value,THE
> ONLY PROBLEM IS, if end user stop polling over a one WindowTime ,the next
> polling will return all metrics value with 0 ,because servo monitor can't
> know the precise value of previous step and only thing can do is "reset".
> for example in this case if user close Front UI and reopen later for a
> moment,the first polling will get all value of 0 (but will recovery to
> correct after one WindowTime)
> 2.Setup a Thread in producer for polling metrics and cache latest in
> memory,let user get the cache value when called
> Use this strategy, the problem of the first strategy will be resolved,but
> NEW PROBLE IS,end user only can get previous step collect Time-unrelated
> type metrics (Counter and Guage) value,not latest value,this data may
> delayed.
>
> Which one is better ? also we can mix two of them : get cached ,then
> update Time-unrelated type metrics value ,then return,but this way the cost
> will be highest.
>
> Best Regards & Thanks!
Re: Reply：[Discussion]Java Chassis Metrics Data Collection and Provide Strategy
Posted by Willem Jiang <wi...@gmail.com>.
If the metric can access the monitor data (Counter or Guage) directly. we
could get a real time counter result.
But if the metric can be only updated by the poller, you have to bear with
first round 0 metrics value.
We cannot count on the client side work, so we still need to keep polling
the metric ourselves
I just found something interesting from the servo document. It look like
Servo's metric is used to send the data to the back end, not for the
Restful service client which is keeping pulling . We should find a way to
export the Counter data directly here.
"Some policies determine the set of metrics (potentially aggregated using
some function like sum or count) that will be sent to our backend. The fast
polling interval will only send a very small number of metrics per machine
(what we consider critical metrics) and usually all the metrics collected
during the slow polling interval will be sent to a different set of
backends. "
Willem Jiang
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Sat, Dec 23, 2017 at 9:17 AM, 郑扬勇 <ya...@qq.com> wrote:
> Hi all:
> I'll use first Strategy "Direct correct metrics data per Call and
> return" current,because is simple and act same as Servo original.
> any question or good idea is wellcome
>
> Best Regards & Thanks
> zhengyangyong
> ------------------ 原始邮件 ------------------
> 发件人: "郑扬勇";<ya...@qq.com>;
> 发送时间: 2017年12月22日(星期五) 下午5:55
> 收件人: "dev"<de...@servicecomb.apache.org>;
>
> 主题: [Discussion]Java Chassis Metrics Data Collection and Provide Strategy
>
>
>
> Hi All：
> We all know there are two major type of metric :
> 1.Time-unrelated,you can get the latest value any time immediately:
> Counter -> increase or decrease
> Guage -> set a certain one value
> 2.Time-related,only after a centain time pass you can compute the right
> value,"a centain time" may can called SampleTime or WindowTime
> Max & Min -> the max value or min value in a centain time
> Average -> average value, the simplest algorithm is f = sum / count
> Rate -> like TPS,algorithm is f = sum / second
>
> In current version (0.6.0-SNAPSHOT),we had integrated with netflix
> servo (0.10.1),about servo more information can be found here :
> https://github.com/Netflix/servo/wiki/Getting-Started
>
> There are two strategy to provider finnal collected metrics data to end
> user :
> 1.Direct correct metrics data per Call and return
> Use this strategy,user will always get latest Time-unrelated type metric
> (Counter and Guage) value and correct time-related type metric value,THE
> ONLY PROBLEM IS, if end user stop polling over a one WindowTime ,the next
> polling will return all metrics value with 0 ,because servo monitor can't
> know the precise value of previous step and only thing can do is "reset".
> for example in this case if user close Front UI and reopen later for a
> moment,the first polling will get all value of 0 (but will recovery to
> correct after one WindowTime)
> 2.Setup a Thread in producer for polling metrics and cache latest in
> memory,let user get the cache value when called
> Use this strategy, the problem of the first strategy will be resolved,but
> NEW PROBLE IS,end user only can get previous step collect Time-unrelated
> type metrics (Counter and Guage) value,not latest value,this data may
> delayed.
>
> Which one is better ? also we can mix two of them : get cached ,then
> update Time-unrelated type metrics value ,then return,but this way the cost
> will be highest.
>
> Best Regards & Thanks!
Reply：[Discussion]Java Chassis Metrics Data Collection and Provide Strategy
Posted by 郑扬勇 <ya...@qq.com>.
Hi all:
I'll use first Strategy "Direct correct metrics data per Call and return" current,because is simple and act same as Servo original.
any question or good idea is wellcome
Best Regards & Thanks
zhengyangyong
------------------ 原始邮件 ------------------
发件人: "郑扬勇";<ya...@qq.com>;
发送时间: 2017年12月22日(星期五) 下午5:55
收件人: "dev"<de...@servicecomb.apache.org>;
主题: [Discussion]Java Chassis Metrics Data Collection and Provide Strategy
Hi All：
We all know there are two major type of metric :
1.Time-unrelated,you can get the latest value any time immediately:
Counter -> increase or decrease
Guage -> set a certain one value
2.Time-related,only after a centain time pass you can compute the right value,"a centain time" may can called SampleTime or WindowTime
Max & Min -> the max value or min value in a centain time
Average -> average value, the simplest algorithm is f = sum / count
Rate -> like TPS,algorithm is f = sum / second
In current version (0.6.0-SNAPSHOT),we had integrated with netflix servo (0.10.1),about servo more information can be found here : https://github.com/Netflix/servo/wiki/Getting-Started
There are two strategy to provider finnal collected metrics data to end user :
1.Direct correct metrics data per Call and return
Use this strategy,user will always get latest Time-unrelated type metric (Counter and Guage) value and correct time-related type metric value,THE ONLY PROBLEM IS, if end user stop polling over a one WindowTime ,the next polling will return all metrics value with 0 ,because servo monitor can't know the precise value of previous step and only thing can do is "reset".
for example in this case if user close Front UI and reopen later for a moment,the first polling will get all value of 0 (but will recovery to correct after one WindowTime)
2.Setup a Thread in producer for polling metrics and cache latest in memory,let user get the cache value when called
Use this strategy, the problem of the first strategy will be resolved,but NEW PROBLE IS,end user only can get previous step collect Time-unrelated type metrics (Counter and Guage) value,not latest value,this data may delayed.
Which one is better ? also we can mix two of them : get cached ,then update Time-unrelated type metrics value ,then return,but this way the cost will be highest.
Best Regards & Thanks!