Reply： Reply： Desgin of Java Chassis Metrics Publish Interface

[郑扬勇 <ya...@qq.com>]

OK~
  

 Best Regards and Thanks!

 ------------------ 原始邮件 ------------------
  发件人: "Willem Jiang";<wi...@gmail.com>;
 发送时间: 2017年12月22日(星期五) 下午3:51
 收件人: "dev"<de...@servicecomb.apache.org>;
 
 主题: Re: Reply： Desgin of Java Chassis Metrics Publish Interface

 

It could save us lot of time if we just provide a normal Restful service, I
don't think it's good idea to provider service contract (swagger file) for
it.
As lots of user could just use a simple http client to access the metrics
data.


Willem Jiang

Blog: http://willemjiang.blogspot.com (English)
          http://jnn.iteye.com  (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Dec 22, 2017 at 2:40 PM, 郑扬勇 <ya...@qq.com> wrote:

> So it seems we may return DTO for better ? like :
>    RegistryMetric metric();
>  Then user can call toMap() method in RegistryMetric convert to map if
> necessary.
>  In order to let metrics consumer import this DTO we must create a new
> Module named "metrics-common" and move it into ?
>
>   Best Regards and Thanks!
>   ------------------ 原始邮件 ------------------
>   发件人: "bismy";<bi...@qq.com>;
>  发送时间: 2017年12月22日(星期五) 下午2:18
>  收件人: "dev"<de...@servicecomb.apache.org>;
>
>  主题: Re: Desgin of Java Chassis Metrics Publish Interface
>
>
>
> From the point of view of the end user, any update is an schema change,
> and we need to inform them with the formal schema. I think use String will
> not reduce user’s work, but more uncertainties.
>
>
> ------------------ Original ------------------
> From: 郑扬勇 <ya...@qq.com>
> Date: 周五,12月 22,2017 11:31 上午
> To: dev <de...@servicecomb.apache.org>
> Subject: Re: Desgin of Java Chassis Metrics Publish Interface
>
>
>
> Dear All:
>     In our desgin,If user include metrics in dependency,the metrics
> service would auto publish with Java Chassis Producer,also use same
> transport and endpoint config.For example if user config rest address
> 0.0.0.0:8080 in microservice.yaml,then the metrics service will available
> at http://:8080/metrics/{pollerIndex}.
>    And in current architecture, the publish interface is : String
> metrics(int pollerIndex); the return type is String not RegistryMetric
> Entity,PR is here : https://github.com/apache/incubator-servicecomb-java-
> chassis/pull/453
>    WillemJiang had point out "It‘s not a good way to just return the
> string here.", indeed use Class would get more clear code,but I think use
> String can also get some advantage.
>
>    First we can extend more metrics result return style via config,like :
>  1.DTO style  (Entity):
>  {"instanceMetric":{"waitInQueue":0,"lifeTimeInQueue":{"total":0,"
> count":0,"average":0.0,"min":0,"max":0},"executionTime":{"
> total":0,"count":0,"average":0.0,"min":0,"max":0},"
> consumerLatency":{"total":0,"count":0,"average":0.0,"min":
> 0,"max":0},"producerLatency":{"total":0,"count":0,"average":
> 0.0,"min":0,"max":0}},"invocationMetrics":{}} ...
>  2.Map style (Map<String,Number>):
>  {"servicecomb.instance.producer.producerLatency.
> average":5.0,"servicecomb.fun1.producer.lifeTimeInQueue.
> total":400000000,"servicecomb.fun3.producer.producerLatency.average":0.0,
>  "servicecomb.fun1.producer.lifeTimeInQueue.min":
> 100000000,"servicecomb.fun1.producer.producerLatency.
> average":5.0,"servicecomb.fun2.consumer.consumerLatency.average":3.0,
>  "servicecomb.fun1.producer.executionTime.max":400000000,"
> servicecomb.fun1.producer.producerCall.tps":1.0,"
> servicecomb.instance.producer.producerLatency.count":2,
>  "servicecomb.fun3.producer.producerLatency.count":0,"
> servicecomb.instance.consumer.consumerCall.tps":0.5,"
> servicecomb.fun3.producer.executionTime.count":0,"servicecom...
>  3.Plain Line style (Properties):
>  servicecomb.instance.producer.producerLatency.average=5.0
>  servicecomb.fun1.producer.lifeTimeInQueue.total=400000
>  servicecomb.fun3.producer.producerLatency.average=0.0
>  ...
>
>    Also when RegistryMetric updated , we don't need update contract yaml
> file,is a trouble work ...
>    Last we can control output of RegistryMetric in order to hide some
> field user don't care.
>
>    More information is here : https://issues.apache.org/jira/browse/SCB-11
> and any suggestion is wellcome~
>
>  Best Regards and Thanks!