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 06:40:40 UTC
Reply： Desgin of Java Chassis Metrics Publish Interface
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!
Reply： Reply： Desgin of Java Chassis Metrics Publish Interface
Posted by 郑扬勇 <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!
Re: Reply： Desgin of Java Chassis Metrics Publish Interface
Posted by Willem Jiang <wi...@gmail.com>.
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!