[ 
https://issues.apache.org/jira/browse/SCB-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16310667#comment-16310667
 ] 

ASF GitHub Bot commented on SCB-132:
------------------------------------

WillemJiang closed pull request #23: [SCB-132] User Guide and Quick Start for 
Metrics 1.0.0-m1
URL: https://github.com/apache/incubator-servicecomb-website/pull/23
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/_users/cn/metrics-in-0.5.0.md b/_users/cn/metrics-in-0.5.0.md
index 6c4e187..68a1ce2 100644
--- a/_users/cn/metrics-in-0.5.0.md
+++ b/_users/cn/metrics-in-0.5.0.md
@@ -1,9 +1,9 @@
 ---
-title: "Metrics监控"
+title: "0.5.0版本中的监控"
 lang: cn
 ref: metrics
-permalink: /cn/users/metrics/
-excerpt: "Metrics监控"
+permalink: /cn/users/metrics-in-0.5.0/
+excerpt: "0.5.0版本中的监控"
 last_modified_at: 2017-12-29T14:01:43-04:00
 redirect_from:
   - /theme-setup/
@@ -31,7 +31,7 @@ Logger名指的是LoggerFactory.getLogger后的第一个参数:
 static final Logger log = LoggerFactory.getLogger("${Logger名}");
 log.trace("${Metric数据}");
 ```
-*为不影响调试,log的输出级别为trace
+**为不影响调试,log的输出级别为trace**
 
 以下是我们的定向Logger名以及输出的Metrics含义:   
 
@@ -75,7 +75,7 @@ servicecomb:
 ```
 
 ## 注意事项
-* 需要在provider治理链中添加bizkeeper-provider,否则TPS和Latency无数据
+**需要在provider治理链中添加bizkeeper-provider,否则TPS和Latency无数据**
 ```yaml
 APPLICATION_ID: demo
 service_description:
diff --git a/_users/cn/metrics-in-1.0.0-m1.md b/_users/cn/metrics-in-1.0.0-m1.md
index 70e5ed1..75becf3 100644
--- a/_users/cn/metrics-in-1.0.0-m1.md
+++ b/_users/cn/metrics-in-1.0.0-m1.md
@@ -25,11 +25,11 @@ redirect_from:
 
 ## 1.0.00-m1版本原理
 在0.5.0版本的实现介绍[0.5.0版本中的监控](/cn/users/metrics-in-0.5.0/)中,存在一些问题:
-1.metrics在foundation-metrics模块中实现,并且包含了一些具体的定制代码;  
-2.使用ThreadLocal变量收集和汇总数据,虽然性能很高,但是存在内存泄漏的风险;  
-3.Metrics的输出为固定的文本,而不是独立的数值,数据使用起来很不方便;  
-4.没有提供通用数据发布接口,难以和更多的第三方监控系统做集成;  
-5.由于foundation-metrics模块过于底层,用户无法以可选的方式决定是否启用;  
+1. metrics在foundation-metrics模块中实现,并且包含了一些具体的定制代码;  
+2. 使用ThreadLocal变量收集和汇总数据,虽然性能很高,但是存在内存泄漏的风险;  
+3. Metrics的输出为固定的文本,而不是独立的数值,数据使用起来很不方便;  
+4. 没有提供通用数据发布接口,难以和更多的第三方监控系统做集成;  
+5. 由于foundation-metrics模块过于底层,用户无法以可选的方式决定是否启用;  
 
 因此,从0.5.0版本升级到1.0.0-m1版本,我们进行了一次全面的重构,重构后的Metrics将分为三个模块  
 
@@ -53,7 +53,7 @@ redirect_from:
 | InvocationStartProcessingEventListener | Producer从队列中取出调用开始处理      |
 | InvocationFinishedEventListener        | Consumer调用返回或Producer处理完毕 |
 
-*特别说明,Java 
Chassis的Reactor框架基于Vertx,微服务Producer端收到Invocation后,并不会马上同步处理请求,而是将它放入一个处理队列中,Invocation在队列中的时间称为LifeTimeInQueue,队列的长度称为waitInQueue,这是衡量微服务压力的两个重要指标,可以参考操作系统磁盘读写队列的概念;Consumer端并不会有队列,因此永远不会触发InvocationStartProcessingEvent。
+*特别说明,Java 
Chassis的Reactor框架基于Vertx,微服务Producer端收到Invocation后,并不会马上同步处理请求,而是将它放入一个处理队列中,Invocation在队列中的时间称为LifeTimeInQueue,队列的长度称为waitInQueue,这是衡量微服务压力的两个重要指标,可以参考操作系统磁盘读写队列的概念;Consumer端并不会有队列,因此永远不会触发InvocationStartProcessingEvent。*
 
 事件触发的代码广泛分布在Java 
Chassis的RestInvocation、HighwayServerInvoke、HighwayClient和VertxHttpMethod中,如果微服务没有启用Metrics,EventBus中不会注入事件监听处理类,因此对性能的影响微乎其微。
 
@@ -67,12 +67,12 @@ Netflix Servo具有性能极高的计数器(Monitor),我们使用了四种
 | MinGauge     | 周期最小值计数器      |
 | MaxGauge     | 周期最大值计数器      |
 
-*依赖的Servo版本为0.10.1
+*依赖的Servo版本为0.10.1*
 
 ### 周期设置
-总所周知,Metric可以分为两大类:  
-1.时间无关型:诸如调用总次数、资源使用状况等等,Consumer无论何时获取Metric,总返回当前最新值;
-2.时间相关型:只有经过一个固定的周期时间才能够获取结果值,例如最大、最小、平均值等等,固定周期一般可以称为“统计时间窗”,在Servo中,这个时间被称为[“Polling
 Intervals”](https://github.com/Netflix/servo/wiki/Getting-Started)。  
+Metric可以分为两大类:  
+1. 时间无关型(直接取值):诸如调用总次数、资源使用状况等等,Consumer无论何时获取Metric,总返回当前最新值;
+2. 
时间相关型(统计取值):只有经过一个固定的周期时间才能够获取结果值,例如最大、最小、平均值等等,固定周期一般可以称为“统计时间窗”,在Servo中,这个时间被称为[“Polling
 Intervals”](https://github.com/Netflix/servo/wiki/Getting-Started)。  
 从1.0.0-m1开始,通过servicecomb.metrics.window_time设置周期,效果与servo.pollers一致。
 
 ## Metric列表
@@ -108,7 +108,7 @@ Netflix Servo具有性能极高的计数器(Monitor),我们使用了四种
 | servicecomb | instance/operationName   | consumer | consumerCall    | total  
        |
 | servicecomb | instance/operationName   | consumer | consumerCall    | tps    
        |
 
-*operationName代表微服务Operation的全名,使用的是Java Chassis 
MicroserviceQualifiedName,它是微服务名.SchemaID.操作方法名的组合。
+*operationName代表微服务Operation的全名,使用的是Java Chassis 
MicroserviceQualifiedName,它是微服务名.SchemaID.操作方法名的组合。*
 
 ## 如何配置
 ### 全局配置
@@ -122,10 +122,11 @@ service_description:
 servicecomb:
   metrics:
     #时间窗间隔,与servo.pollers设置效果一致,单位毫秒
-    
#支持多个时间窗间隔,使用逗号(,)将多个分隔开,例如5000,10000,代表设置两个时间窗,第一个时间窗5000的windowTimeIndex为0,第二个时间窗10000的windowTimeIndex为1,依此类推
-    window_time: 5000
+    #支持多个时间窗间隔,使用逗号(,)将多个分隔开,例如5000,10000,代表设置两个时间窗
+    window_time: 5000,10000
 ```
-*时间窗设置对于统计结果获取的影响,附上代码中包含的一段注释如下:  
+*时间窗设置对于统计结果获取的影响,附上代码中包含的一段注释如下:*  
+
 ![TimeWindowComment.png](/assets/images/TimeWindowComment.png)
 
 ### 依赖配置
@@ -154,21 +155,27 @@ public class DefaultMetricsPublisher implements 
MetricsPublisher {
   }
 
   @RequestMapping(path = "/appliedWindowTime", method = RequestMethod.GET)
+  @CrossOrigin
   @Override
   public List<Long> getAppliedWindowTime() {
     return dataSource.getAppliedWindowTime();
   }
 
   @RequestMapping(path = "/", method = RequestMethod.GET)
+  @CrossOrigin
   @Override
   public RegistryMetric metrics() {
     return dataSource.getRegistryMetric();
   }
 
-  @RequestMapping(path = "/{windowTimeIndex}", method = RequestMethod.GET)
+  @ApiResponses({
+      @ApiResponse(code = 400, response = String.class, message = "illegal 
request content"),
+  })
+  @RequestMapping(path = "/{windowTime}", method = RequestMethod.GET)
+  @CrossOrigin
   @Override
-  public RegistryMetric metricsWithWindowTimeIndex(@PathVariable(name = 
"windowTimeIndex") int windowTimeIndex) {
-    return dataSource.getRegistryMetric(windowTimeIndex);
+  public RegistryMetric metricsWithWindowTime(@PathVariable(name = 
"windowTime") long windowTime) {
+    return dataSource.getRegistryMetric(windowTime);
   }
 }
 ```
@@ -188,7 +195,8 @@ cse:
 @Autowired
 private DataSource dataSource;
 ```
-*我们已经开发完成了两个使用场景可以作为参考:
-1.metrics-wirte-file:将Metrics数据写入文件,代码在metrics-extension中
-2.metrics-prometheus:将Metrics发布为prometheus Producer
 
+## 参考示例
+我们已经开发完成了两个使用场景可以作为参考:  
+1. metrics-wirte-file:将Metrics数据写入文件,代码在metrics-extension中;  
+2. metrics-prometheus:将Metrics发布为prometheus Producer。  
diff --git a/_users/cn/metrics-write-file-extension-and-sample-in-1.0.0-m1.md 
b/_users/cn/metrics-write-file-extension-and-sample-in-1.0.0-m1.md
index 39d8d0d..f7939fd 100644
--- a/_users/cn/metrics-write-file-extension-and-sample-in-1.0.0-m1.md
+++ b/_users/cn/metrics-write-file-extension-and-sample-in-1.0.0-m1.md
@@ -15,7 +15,7 @@ redirect_from:
 ## 背景
 
0.5.0版本的foundation-metrics实现了将采集到的Metrics数据写入文件,在1.0.0-m1中,此功能移动到metrics-extension中;
  
 
从1.0.0-m1版本开始支持输出Operation级别的Metric,因此无法通过固定配置的方式配置日志输出,将采用代码的方式在运行时为每一个Metric自动创建专用的RollingFileAppender。
-功能包含如下模块:
+功能包含如下模块:  
 
 | Module名                         | 描述                              |
 | :------------------------------- | :------------------------------   |
@@ -24,7 +24,7 @@ redirect_from:
 | metrics-write-file-config-log4j  | 使用Log4j的RollingFileAppender写文件     |
 | metrics-write-file-config-log4j2 | 使用Log4j2的RollingFileAppender写文件      |
 
-*暂未提供logback的metrics-write-file-config,参考Log4j和log4j2的例子可以很容易实现metrics-write-file-config-logback
+*暂未提供logback的metrics-write-file-config,参考Log4j和log4j2的例子可以很容易实现metrics-write-file-config-logback*
 
 ## 配置
 ### 全局配置
@@ -50,11 +50,11 @@ servicecomb:
         #文件最大大小,单位可以是KB,MB和GB
         max_file_size : 10MB
 ```
-*与0.5.0版本配置的比较:
-1.旧版本使用servicecomb.metrics.polltime(单位秒)配置文件输出间隔,1.0.0-m1版本中旧版本功能仍然存在;
-2.新版本添加依赖即启用,因此没有老版本类似servicecomb.metrics.file.enabled开关,这个开关可以用于关闭老版本输出(老版本预定在下一个版本1.0.0-m2中彻底移除);
-3.新版本无需配置servicecomb.metrics.filename_prefix,默认为微服务的appId.serviceName;
-4.新版本增加了对rolling file的设置,这些配置在老版本是配置在日志的xml或properties文件里的。
+与0.5.0版本配置的比较:
+1. 旧版本使用servicecomb.metrics.polltime(单位秒)配置文件输出间隔,1.0.0-m1版本中旧版本功能仍然存在;  
+2. 
新版本添加依赖即启用,因此没有老版本类似servicecomb.metrics.file.enabled开关,这个开关可以用于关闭老版本输出(老版本预定在下一个版本1.0.0-m2中彻底移除);
  
+3. 新版本无需配置servicecomb.metrics.filename_prefix,默认为微服务的appId.serviceName;  
+4. 新版本增加了对rolling file的设置,这些配置在老版本是配置在日志的xml或properties文件里的。  
 
 ### 依赖配置
 Java Chassis支持直接启动和Spring Boot Starter启动两种模式,两种模式下的配置详细描述如下:
@@ -161,13 +161,13 @@ spring boot starter中包含了log4j-over-slf4j,这个依赖会在运行态屏
 可以看到,spring boot starter默认使用的是log4j作为日志实现,无论你是否排除log4j的相关依赖,并不会对log4j2 write 
file造成任何影响,两者并存,因此依赖方面与直接启动是相同的。
 
 ## Q & A
-1.在新的1.0.0-m1版本里,我是否还需要在日志配置文件(例如log4j2.xml) 中追加任何修改吗?
+1. 在新的1.0.0-m1版本里,我是否还需要在日志配置文件(例如log4j2.xml) 中追加任何修改吗?  
 
不需要,metrics-write-file-config-xxx会在运行态自动为metric生成对应的RollingFileAppender,并且这个Appender与你日志配置的Appenders没有任何关系。
 
-2.我发现metrics-write-file-config-log4j2中创建RollingFileAppender是使用一个标记为过期的createAppender方法,为什么不使用新的的newBuilder
 ... build模式?
+2. 
我发现metrics-write-file-config-log4j2中创建RollingFileAppender是使用一个标记为过期的createAppender方法,为什么不使用新的的newBuilder
 ... build模式?  
 开发的时候发现newBuilder ... 
build与微服务框架存在某种冲突导致不可用,另外,官方文档的[示例代码](https://logging.apache.org/log4j/2.x/manual/customconfig.html)仍然使用的是createAppender,缺乏资料也给定位问题造成了一定的麻烦;我们将在下一个版本1.0.0-m2中去修复,已标记TODO。
 
-3.集成后出现RollingFileAppender抛ClassNotFoundException之类的错误?
+3. 集成后出现RollingFileAppender抛ClassNotFoundException之类的错误?  
 
众所周知,Java开发主流都使用slf4j或jcl做为日志框架,然后桥接具体的日志实现,例如log4j、log4j2和logback,通过配置文件初始化日志组件,达到随意更换弱绑定的效果,并不推荐编码方式创建日志组件。
 
但由于1.0.0-m1版本开始支持Operation级别的Metric输出,不同的微服务Operation不同,并且单Operation会有15+以上的Metric,因此手动配置已不具备可操作性,必须通过Coding的方式动态生成RollingFileAppender。
 如果你的项目中包含类似log4j-over-slf4j这样的Bridging依赖,就很可能会出现这样的问题,请使用mvn dependency:tree检查。
\ No newline at end of file
diff --git a/assets/images/TimeWindowComment.png 
b/assets/images/TimeWindowComment.png
index ac682f6..a2eda48 100644
Binary files a/assets/images/TimeWindowComment.png and 
b/assets/images/TimeWindowComment.png differ


 

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> User Guide and Quick Start for Metrics 1.0.0-m1
> -----------------------------------------------
>
>                 Key: SCB-132
>                 URL: https://issues.apache.org/jira/browse/SCB-132
>             Project: Apache ServiceComb
>          Issue Type: Sub-task
>          Components: Java-Chassis
>            Reporter: yangyongzheng
>            Assignee: yangyongzheng
>             Fix For: java-chassis-1.0.0-m1
>
>
> Write User Guide and Quick Start for Metrics 1.0.0-m1 :
> 1.User Guide : describe the Architecture and update change from 0.5.0
> 2.Quick Start : describe how to use metrics in java chassis , include 
> publish,consume and integration



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to