You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@servicecomb.apache.org by ni...@apache.org on 2018/01/12 09:42:01 UTC
[incubator-servicecomb-website] branch master updated: [SCB-132]
Metrics MD (#24)
This is an automated email from the ASF dual-hosted git repository.
ningjiang pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-servicecomb-website.git
The following commit(s) were added to refs/heads/master by this push:
new c6777e6 [SCB-132] Metrics MD (#24)
c6777e6 is described below
commit c6777e6d71a8693dc65b3710bc952e641120d184
Author: zhengyangyong <ya...@huawei.com>
AuthorDate: Fri Jan 12 17:41:59 2018 +0800
[SCB-132] Metrics MD (#24)
* SCB-132 add en version and fix cn version
Signed-off-by: zhengyangyong <ya...@huawei.com>
* SCB-132 fix style
Signed-off-by: zhengyangyong <ya...@huawei.com>
* SCB-132 fix content for pr
Signed-off-by: zhengyangyong <ya...@huawei.com>
* SCB-132 fix content
Signed-off-by: zhengyangyong <ya...@huawei.com>
* SCB-132 fix content
Signed-off-by: zhengyangyong <ya...@huawei.com>
---
_data/navigation.yml | 7 +
_users/cn/metrics-in-1.0.0-m1.md | 118 ++++++------
...rics-integration-with-prometheus-in-1.0.0-m1.md | 12 +-
...-write-file-extension-and-sample-in-1.0.0-m1.md | 124 +++---------
_users/metrics-in-1.0.0-m1.md | 208 +++++++++++++++++++++
...rics-integration-with-prometheus-in-1.0.0-m1.md | 73 ++++----
6 files changed, 346 insertions(+), 196 deletions(-)
diff --git a/_data/navigation.yml b/_data/navigation.yml
index bb6c190..9905397 100755
--- a/_data/navigation.yml
+++ b/_data/navigation.yml
@@ -92,6 +92,13 @@ t:
- title: Zuul
url: /users/edging-service/zuul/
+ - title: Monitor
+ children:
+ - title: Metrics-in-1.0.0-m1
+ url: /users/metrics-in-1.0.0-m1/
+ - title: Metrics-integration-with-prometheus-in-1.0.0-m1
+ url: /users/metrics-integration-with-prometheus-in-1.0.0-m1/
+
- title: Deployment
children:
- title: Run Mode
diff --git a/_users/cn/metrics-in-1.0.0-m1.md b/_users/cn/metrics-in-1.0.0-m1.md
index 75becf3..00c8781 100644
--- a/_users/cn/metrics-in-1.0.0-m1.md
+++ b/_users/cn/metrics-in-1.0.0-m1.md
@@ -10,7 +10,7 @@ redirect_from:
---
{% include toc %}
-微服务框架从0.5.0版本开始支持监控功能Metrics，1.0.0-m1版本正式发布，我们会继续追加新特性新功能，订阅ServiceComb邮件列表(dev-subscribe@servicecomb.incubator.apache.org)以持续获取最新信息。
+微服务框架从0.5.0版本开始支持监控功能Metrics，1.0.0-m1版本正式发布，请通过查看用户手册和[Release Note](https://github.com/apache/incubator-servicecomb-java-chassis/releases)获取更多信息，我们也会继续追加新特性新功能，欢迎订阅ServiceComb邮件列表(dev-subscribe@servicecomb.incubator.apache.org)参与讨论。
## 背景
将系统微服务化是技术潮流和趋势，但是它解决了很多问题的同时也带来了新的问题。
@@ -21,7 +21,7 @@ redirect_from:
-这是微服务化后的系统架构图，经过功能切分，开发人员得到解脱，拥有了极致的CI/CD，但是运维人员却需要维护海量的微服务实例，所以如果不进行性能监控，就无法定位时延高的微服务，也无法制定弹性伸缩策略。
+这是微服务化后的系统架构图，经过功能切分，开发人员获得了架构独立、快速迭代等诸多微服务带来的好处，但是运维人员却需要维护海量的微服务实例，所以如果不进行性能监控，当系统出现故障或用户体验下降时，就无法快速定位问题，也无法制定策略（例如弹性伸缩）来预防。
## 1.0.00-m1版本原理
在0.5.0版本的实现介绍[0.5.0版本中的监控](/cn/users/metrics-in-0.5.0/)中，存在一些问题：
@@ -31,84 +31,88 @@ redirect_from:
4. 没有提供通用数据发布接口，难以和更多的第三方监控系统做集成；
5. 由于foundation-metrics模块过于底层，用户无法以可选的方式决定是否启用；
-因此，从0.5.0版本升级到1.0.0-m1版本，我们进行了一次全面的重构，重构后的Metrics将分为三个模块
+因此，从0.5.0版本升级到1.0.0-m1版本，我们进行了一次全面的重构，重构后的Metrics将分为如下几个模块
-| Module名 | 描述 |
-| :------------------ | :------------------------------ |
-| metrics-core | Metric核心模块，引入后即启用Metrics数据收集功能 |
-| metrics-common | Metric通用模块，主要包含Metric DTO用于数据发布 |
-| metrics-extension | 包含Metric的一些扩展功能 |
-| metrics-integration | 包含Metric与其它三方系统集成 |
-| metrics-sample | 包含Metric的一些示例 |
+| Module名 | 描述 |
+| :------------------ | :------------------------------- |
+| metrics-core | Metrics核心模块，引入后即启用Metrics数据收集功能 |
+| metrics-common | Metrics通用模块，主要包含Metric DTO用于数据发布 |
+| metrics-extension | 包含Metrics的一些扩展功能 |
+| metrics-integration | 包含Metrics与其它三方系统集成 |
它们的依赖关系如下图所示：
### 数据采集不再依赖Hystrix（handler-bizkeeper），使用事件埋点收集与调用相关的所有数据
-1.0.0-m1版本不再从Hystrix获取调用的TPS和Latency，避免了不配置Java Chassis Bizkeeper Handler就不会输出这两项数据的问题；使用foundation-common中的EventBus作为事件总线，metrics-core中的DefaultEventListenerManager初始化后会立即注入三个事件监听处理类：
-
+1.0.0-m1版本不再从Hystrix获取调用的TPS和Latency，避免了不配置Java Chassis Bizkeeper Handler就不会输出这两项数据的问题；使用foundation-common中的EventBus作为事件总线，metrics-core中的DefaultEventListenerManager初始化后会立即注册三个事件监听处理类：
+
| 事件监听处理类名 | 功能 |
| :------------------------------------- | :------------------------ |
| InvocationStartedEventListener | Consumer调用或Producer接收开始 |
| InvocationStartProcessingEventListener | Producer从队列中取出调用开始处理 |
| InvocationFinishedEventListener | Consumer调用返回或Producer处理完毕 |
-*特别说明，Java Chassis的Reactor框架基于Vertx，微服务Producer端收到Invocation后，并不会马上同步处理请求，而是将它放入一个处理队列中，Invocation在队列中的时间称为LifeTimeInQueue，队列的长度称为waitInQueue，这是衡量微服务压力的两个重要指标，可以参考操作系统磁盘读写队列的概念；Consumer端并不会有队列，因此永远不会触发InvocationStartProcessingEvent。*
+*特别说明，Java Chassis的Reactor框架基于[Vertx](http://vertx.io/)，在同步调用模式下，微服务Producer端收到Invocation后，并不会马上同步处理请求，而是将它放入一个处理队列中，Invocation在队列中的时间称为**LifeTimeInQueue**，队列的长度称为**waitInQueue**，这是衡量微服务压力的两个重要指标，可以参考操作系统磁盘读写队列的概念；Consumer端并不会有队列，因此永远不会触发InvocationStartProcessingEvent。*
-事件触发的代码广泛分布在Java Chassis的RestInvocation、HighwayServerInvoke、HighwayClient和VertxHttpMethod中，如果微服务没有启用Metrics，EventBus中不会注入事件监听处理类，因此对性能的影响微乎其微。
+事件触发的代码分布在Java Chassis的RestInvocation、HighwayServerInvoke和InvokerUtils中，如果微服务没有启用Metrics，EventBus中就不会注册Metrics事件监听处理器，因此对性能的影响微乎其微。
### 使用Netflix Servo作为Metric的计数器
-Netflix Servo具有性能极高的计数器（Monitor），我们使用了四种：
+[Netflix Servo](https://github.com/Netflix/servo)具有性能极高的计数器（Monitor），我们使用了四种：
-| Monitor名 | 描述 |
-| :----------- | :------------ |
-| BasicCounter | 基本累积计数器（永续累加） |
-| StepCounter | 周期累加计数器 |
-| MinGauge | 周期最小值计数器 |
-| MaxGauge | 周期最大值计数器 |
+| Monitor名 | 描述 |
+| :----------- | :------------------------------- |
+| BasicCounter | 基本累积计数器（永续累加） |
+| StepCounter | 周期累加计数器（以前曾经称为ResettableCounter） |
+| MinGauge | 周期最小值计数器 |
+| MaxGauge | 周期最大值计数器 |
*依赖的Servo版本为0.10.1*
### 周期设置
-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一致。
-
+Metrics有很多种分类方式，在技术实现上我们偏向以取值方式区分为两种：
+1. 直接取值
+ 任何时候都能够立刻获取到最新值，例如资源使用率，包括CPU使用率，线程数，Heap使用数据等等，还有调用累加次数，当前队列长度等等。
+2. 统计取值
+ 经过一个特定的时间周期才能够统计出值，这个时间间隔我们可以称为窗口周期（Window Time）或统计周期，例如：
+ a) 多值取其一的，比如Max、Min、Median（中位值）;
+ b) 与时间相关的，比如TPS（transaction per second）；
+ c) 与个数相关的，比如累加平均值、方差等等；
+ 获取此类Metrics的值，返回的是上一个周期的统计结果，具有一定的延后性。在Servo中，这个时间被称为[“Polling Intervals”](https://github.com/Netflix/servo/wiki/Getting-Started)。
+ 从1.0.0-m1开始，可以通过microservice.yaml中的servicecomb.metrics.window_time配置设置周期，效果与servo.pollers一致。
## Metric列表
从1.0.0-m1开始，支持微服务Operation级别的Metric输出，列表如下：
-| Group | Level | Catalog | Metrics | Item |
-| :---------- | :----------------------- | :------- | :-------------- | :------------- |
-| servicecomb | instance | system | cpu | load |
-| servicecomb | instance | system | cpu | runningThreads |
-| servicecomb | instance | system | heap | init |
-| servicecomb | instance | system | heap | max |
-| servicecomb | instance | system | heap | commit |
-| servicecomb | instance | system | heap | used |
-| servicecomb | instance | system | nonHeap | init |
-| servicecomb | instance | system | nonHeap | max |
-| servicecomb | instance | system | nonHeap | commit |
-| servicecomb | instance | system | nonHeap | used |
-| servicecomb | instance/operationName | producer | waitInQueue | count |
-| servicecomb | instance/operationName | producer | lifeTimeInQueue | average |
-| servicecomb | instance/operationName | producer | lifeTimeInQueue | max |
-| servicecomb | instance/operationName | producer | lifeTimeInQueue | min |
-| servicecomb | instance/operationName | producer | executionTime | average |
-| servicecomb | instance/operationName | producer | executionTime | max |
-| servicecomb | instance/operationName | producer | executionTime | min |
-| servicecomb | instance/operationName | producer | producerLatency | average |
-| servicecomb | instance/operationName | producer | producerLatency | max |
-| servicecomb | instance/operationName | producer | producerLatency | min |
-| servicecomb | instance/operationName | producer | producerCall | total |
-| servicecomb | instance/operationName | producer | producerCall | tps |
-| servicecomb | instance/operationName | consumer | consumerLatency | average |
-| servicecomb | instance/operationName | consumer | consumerLatency | max |
-| servicecomb | instance/operationName | consumer | consumerLatency | min |
-| servicecomb | instance/operationName | consumer | consumerCall | total |
-| servicecomb | instance/operationName | consumer | consumerCall | tps |
-
-*operationName代表微服务Operation的全名，使用的是Java Chassis MicroserviceQualifiedName，它是微服务名.SchemaID.操作方法名的组合。*
+| Group | Level | Catalog | Metrics | Item |
+| :---------- | :--------------------- | :------- | :-------------- | :------------- |
+| servicecomb | instance | system | cpu | load |
+| servicecomb | instance | system | cpu | runningThreads |
+| servicecomb | instance | system | heap | init |
+| servicecomb | instance | system | heap | max |
+| servicecomb | instance | system | heap | commit |
+| servicecomb | instance | system | heap | used |
+| servicecomb | instance | system | nonHeap | init |
+| servicecomb | instance | system | nonHeap | max |
+| servicecomb | instance | system | nonHeap | commit |
+| servicecomb | instance | system | nonHeap | used |
+| servicecomb | instance | operationName | producer | waitInQueue | count |
+| servicecomb | instance | operationName | producer | lifeTimeInQueue | average |
+| servicecomb | instance | operationName | producer | lifeTimeInQueue | max |
+| servicecomb | instance | operationName | producer | lifeTimeInQueue | min |
+| servicecomb | instance | operationName | producer | executionTime | average |
+| servicecomb | instance | operationName | producer | executionTime | max |
+| servicecomb | instance | operationName | producer | executionTime | min |
+| servicecomb | instance | operationName | producer | producerLatency | average |
+| servicecomb | instance | operationName | producer | producerLatency | max |
+| servicecomb | instance | operationName | producer | producerLatency | min |
+| servicecomb | instance | operationName | producer | producerCall | total |
+| servicecomb | instance | operationName | producer | producerCall | tps |
+| servicecomb | instance | operationName | consumer | consumerLatency | average |
+| servicecomb | instance | operationName | consumer | consumerLatency | max |
+| servicecomb | instance | operationName | consumer | consumerLatency | min |
+| servicecomb | instance | operationName | consumer | consumerCall | total |
+| servicecomb | instance | operationName | consumer | consumerCall | tps |
+
+**当Level的值是“instance”的时候，代表微服务事例级别的Metric，否则代表微服务具体Operation的Metric，operationName使用的是Java Chassis MicroserviceQualifiedName，它是微服务名.SchemaID.操作方法名的组合。**
## 如何配置
### 全局配置
diff --git a/_users/cn/metrics-integration-with-prometheus-in-1.0.0-m1.md b/_users/cn/metrics-integration-with-prometheus-in-1.0.0-m1.md
index 8bbaf40..58809b2 100644
--- a/_users/cn/metrics-integration-with-prometheus-in-1.0.0-m1.md
+++ b/_users/cn/metrics-integration-with-prometheus-in-1.0.0-m1.md
@@ -10,14 +10,14 @@ redirect_from:
---
{% include toc %}
-微服务框架从0.5.0版本开始支持监控功能Metrics，1.0.0-m1版本正式发布，我们会继续追加新特性新功能，订阅ServiceComb邮件列表(dev-subscribe@servicecomb.incubator.apache.org)以持续获取最新信息。
+微服务框架从0.5.0版本开始支持监控功能Metrics，1.0.0-m1版本正式发布，请通过查看用户手册和[Release Note](https://github.com/apache/incubator-servicecomb-java-chassis/releases)获取更多信息，我们也会继续追加新特性新功能，欢迎订阅ServiceComb邮件列表(dev-subscribe@servicecomb.incubator.apache.org)参与讨论。
## 背景
[普罗米修斯](http://www.prometheus.io/)是相似于Google Borgmon的一个开源监控系统，也是[CNCF](https://www.cncf.io/)的成员之一，目前社区非常活跃，Java Chassis Metrics在1.0.0-m1中支持对接普罗米修斯，并进一步实现使用[Grafana](https://grafana.com/)查询Metrics数据。
## 对接原理
由于Java Chassis由Java语言开发，我们使用[prometheus java client](https://github.com/prometheus/client_java)中的Simple Client作为对接SDK，版本为0.1.0。
-Prometheus推荐Pull模式拉取Metrics数据，被监控微服务作为Producer发布数据provider接口，我们采用Simple Http Server发布微服务采集到的Metrics数据。
+Prometheus推荐Pull模式拉取Metrics数据，被监控微服务作为Producer发布数据provider接口，我们采用Simple HTTP Server发布微服务采集到的Metrics数据。
作为一个集成（可选）模块，代码在metrics-integration/metrics-prometheus中，你可以看到它依赖：
```xml
<dependency>
@@ -55,7 +55,7 @@ cse:
"producerMetrics":{"calculator.metricsEndpoint.metrics":{"operationName":"calculator.metricsEndpoint.metrics","prefix":"servicecomb.calculator.metricsEndpoint.metrics.producer","waitInQueue":0,"lifeTimeInQueue":{"total":0,"count":0,"min":0,"max":0,"average":0.0},"executionTime":{"total":0,"count":0,"min":0,"max":0,"average":0.0},"producerLatency":{"total":0,"count":0,"min":0,"max":0,"average":0.0},"producerCall":{"total":1,"tps":0.0}}
}}
```
-但使用Prometheus Simple Http Server接口发布的数据是Prometheus采集的标准格式：
+使用Prometheus Simple HTTP Server接口发布的数据是Prometheus采集的标准格式：
```text
# HELP Instance Level Instance Level Metrics
# TYPE Instance Level untyped
@@ -75,9 +75,9 @@ servicecomb_calculator_metricsEndpoint_metrics_producer_executionTime_total 0.0
servicecomb_calculator_metricsEndpoint_metrics_producer_waitInQueue_count 0.0
servicecomb_calculator_metricsEndpoint_metrics_producer_lifeTimeInQueue_count 0.0
```
-所以它们两个是完全独立各有用途的，取决你如何使用。
+所以它们两个是完全独立各有用途的。
-*Prometheus Simple Http Server同样使用/metrics作为默认URL，metrics-prometheus会使用9696作为默认端口，因此微服务启动后你可以使用http://localhost:9696/metrics 访问它。*
+*Prometheus Simple HTTP Server同样使用/metrics作为默认URL，metrics-prometheus会使用9696作为默认端口，因此微服务启动后你可以使用http://localhost:9696/metrics 访问它。*
我们可以看到在Prometheus的Metric命名统一使用下划线代替了点，因为需要遵守它的[命名规则](https://prometheus.io/docs/practices/naming/)。
@@ -132,7 +132,7 @@ scrape_configs:
### 配置Grafana（可选）
如何在Grafana中添加Prometheus作为数据源请参考[这篇文章](https://prometheus.io/docs/visualization/grafana/)。
## 运行效果
-配置好并启动了微服务、Prometheus之后，就可以打开Prometheus Web界面（默认地址是http://localhost:9090/ ），在Metrics列表中看到ServiceComb开头的Java Chassis Metrics，如下图所示：
+配置好Prometheus并启动了微服务之后，就可以打开Prometheus Web界面（默认地址是http://localhost:9090/ ），在Metrics列表中看到ServiceComb开头的Java Chassis Metrics，如下图所示：
为了能够达到更好的查询效果，在Grafana中添加Prometheus作为数据源，通过Grafana查询数据如下图示：
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 f7939fd..273e9f5 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
@@ -10,24 +10,22 @@ redirect_from:
---
{% include toc %}
-微服务框架从0.5.0版本开始支持监控功能Metrics，1.0.0-m1版本正式发布，我们会继续追加新特性新功能，订阅ServiceComb邮件列表(dev-subscribe@servicecomb.incubator.apache.org)以持续获取最新信息。
+微服务框架从0.5.0版本开始支持监控功能Metrics，1.0.0-m1版本正式发布，请通过查看用户手册和[Release Note](https://github.com/apache/incubator-servicecomb-java-chassis/releases)获取更多信息，我们也会继续追加新特性新功能，欢迎订阅ServiceComb邮件列表(dev-subscribe@servicecomb.incubator.apache.org)参与讨论。
## 背景
-0.5.0版本的foundation-metrics实现了将采集到的Metrics数据写入文件，在1.0.0-m1中，此功能移动到metrics-extension中；
+0.5.0版本的foundation-metrics实现了将采集到的Metrics数据写入文件，在1.0.0-m1中，此功能以Sample的形式移动到了samples/metrics-write-file-sample中；
从1.0.0-m1版本开始支持输出Operation级别的Metric，因此无法通过固定配置的方式配置日志输出，将采用代码的方式在运行时为每一个Metric自动创建专用的RollingFileAppender。
-功能包含如下模块：
+示例代码包含如下三个模块：
-| Module名 | 描述 |
-| :------------------------------- | :------------------------------ |
-| metrics-write-file | 定期获取Metrics数据写入文件主模块 |
-| metrics-write-file-config | 写文件方式配置模块 |
-| metrics-write-file-config-log4j | 使用Log4j的RollingFileAppender写文件 |
-| metrics-write-file-config-log4j2 | 使用Log4j2的RollingFileAppender写文件 |
+| Module名 | 描述 |
+| :--------------------------------------- | :------------------------------ |
+| metrics-write-file | 定期获取Metrics数据写入文件主模块 |
+| metrics-write-file-config-log4j-springboot | 使用Log4j的RollingFileAppender写文件 |
+| metrics-write-file-config-log4j2-springboot | 使用Log4j2的RollingFileAppender写文件 |
-*暂未提供logback的metrics-write-file-config，参考Log4j和log4j2的例子可以很容易实现metrics-write-file-config-logback*
+*暂未提供logback的示例，参考Log4j和Log4j2的例子可以很容易实现*
-## 配置
-### 全局配置
+## 全局配置
与0.5.0类似，需要在microservice.yaml中添加如下配置项：
```yaml
APPLICATION_ID: demo
@@ -56,46 +54,20 @@ servicecomb:
3. 新版本无需配置servicecomb.metrics.filename_prefix，默认为微服务的appId.serviceName；
4. 新版本增加了对rolling file的设置，这些配置在老版本是配置在日志的xml或properties文件里的。
-### 依赖配置
-Java Chassis支持直接启动和Spring Boot Starter启动两种模式，两种模式下的配置详细描述如下：
-#### 直接启动（不使用Spring Boot）依赖配置
-##### 项目使用log4j作为日志实现
-请参考samples/metrics-write-file-sample/metrics-write-file-log4j项目：
+## 依赖和代码使用
+1. 首先需要引入metrics-write-file模块，这个模块包括了获取Metrics数据并转化为指定格式后写文件的逻辑：
```xml
<dependency>
- <groupId>io.servicecomb</groupId>
- <artifactId>metrics-write-file-config</artifactId>
- </dependency>
- <dependency>
- <groupId>io.servicecomb</groupId>
- <artifactId>metrics-write-file-config-log4j</artifactId>
- </dependency>
- <dependency>
- <groupId>io.servicecomb</groupId>
- <artifactId>metrics-write-file</artifactId>
- </dependency>
-```
-依赖的log4j的版本为1.2.17。
-##### 项目使用log4j2作为日志实现
-请参考samples/metrics-write-file-sample/metrics-write-file-log4j2项目：
-```xml
- <dependency>
- <groupId>io.servicecomb</groupId>
- <artifactId>metrics-write-file-config</artifactId>
- </dependency>
- <dependency>
- <groupId>io.servicecomb</groupId>
- <artifactId>metrics-write-file-config-log4j2</artifactId>
- </dependency>
- <dependency>
- <groupId>io.servicecomb</groupId>
+ <groupId>io.servicecomb.samples</groupId>
<artifactId>metrics-write-file</artifactId>
</dependency>
```
-可以看到，与使用log4j唯一不同的是将metrics-write-file-config-log4j更换为metrics-write-file-config-log4j2，依赖的log4j2的版本为2.8.2。
-#### Spring Boot Starter启动依赖配置
-##### 项目使用log4j作为日志实现
-请参考samples/metrics-write-file-sample/metrics-write-file-log4j-springboot项目：
+*也可以参考其中的实现修改代码或复制代码到项目中。*
+2. metrics-write-file模块不包含动态生成写文件RollingFileAppender的代码，根据项目实际使用的日志实现，如果是log4j，拷贝metrics-write-file-log4j-springboot模块中的Log4JMetricsFileWriter，如果是log4j2，拷贝metrics-write-file-log4j2-springboot模块中的Log4J2MetricsFileWriter。
+ *也可以参考其中的实现修改代码或自己实现FileWriter。*
+
+## 使用Spring Boot Starter开发注意事项
+Java Chassis集成了Spring Boot Starter，如果使用Spring Boot Starter启动微服务同时又使用Log4j作为日志实现，则需要处理依赖问题，请参考samples/metrics-write-file-sample/metrics-write-file-log4j-springboot项目：
```xml
<!--need exclusion log4j-over-slf4j-->
<dependency>
@@ -114,60 +86,20 @@ Java Chassis支持直接启动和Spring Boot Starter启动两种模式，两种
<groupId>io.servicecomb</groupId>
<artifactId>spring-boot-starter-provider</artifactId>
</dependency>
-
- <!--metrics dependency-->
- <dependency>
- <groupId>io.servicecomb</groupId>
- <artifactId>metrics-write-file-config</artifactId>
- </dependency>
- <dependency>
- <groupId>io.servicecomb</groupId>
- <artifactId>metrics-write-file-config-log4j2</artifactId>
- </dependency>
- <dependency>
- <groupId>io.servicecomb</groupId>
- <artifactId>metrics-write-file</artifactId>
- </dependency>
```
-spring boot starter中包含了log4j-over-slf4j，这个依赖会在运行态屏蔽掉log4j的RollingFileAppender，使我们无法动态创建它，请确定这种排除对你的系统不会有影响，关于log4j-over-slf4j的更多信息可以参考[这篇文章](https://www.slf4j.org/legacy.html)。
-##### 项目使用log4j2作为日志实现
-请参考samples/metrics-write-file-sample/metrics-write-file-log4j2-springboot项目：
-```xml
- <dependency>
- <groupId>org.springframework.boot</groupId>
- <artifactId>spring-boot-starter</artifactId>
- </dependency>
+Spring Boot Starter中包含了log4j-over-slf4j，这个Log Bridge并没有完全实现log4j的所有接口，包括RollingFileAppender，所以我们需要排除它让slf4j直接调用log4j而不是这个Log Bridge，请确定这种排除对你的系统不会有影响，关于log4j-over-slf4j的更多信息可以参考[这篇文章](https://www.slf4j.org/legacy.html#log4j-over-slf4j)。
- <!--servicecomb spring boot starter-->
- <dependency>
- <groupId>io.servicecomb</groupId>
- <artifactId>spring-boot-starter-provider</artifactId>
- </dependency>
-
- <!--metrics dependency-->
- <dependency>
- <groupId>io.servicecomb</groupId>
- <artifactId>metrics-write-file-config</artifactId>
- </dependency>
- <dependency>
- <groupId>io.servicecomb</groupId>
- <artifactId>metrics-write-file-config-log4j2</artifactId>
- </dependency>
- <dependency>
- <groupId>io.servicecomb</groupId>
- <artifactId>metrics-write-file</artifactId>
- </dependency>
-```
-可以看到，spring boot starter默认使用的是log4j作为日志实现，无论你是否排除log4j的相关依赖，并不会对log4j2 write file造成任何影响，两者并存，因此依赖方面与直接启动是相同的。
+## 运行示例
+metrics-write-file-config-log4j-springboot和metrics-write-file-config-log4j2-springboot都是可以直接运行的示例项目，使用ServiceApplication启动完成后，观察输出目录target/metric/下会生成很多Metrics文件，如果在浏览器中刷新几下http://localhost:8080/f 请求，则可以看到对应的Operation级别的Metrics文件也会在目录下自动生成。
## Q & A
1. 在新的1.0.0-m1版本里，我是否还需要在日志配置文件（例如log4j2.xml） 中追加任何修改吗？
-不需要，metrics-write-file-config-xxx会在运行态自动为metric生成对应的RollingFileAppender，并且这个Appender与你日志配置的Appenders没有任何关系。
+ 不需要，会在运行态自动为metric生成对应的RollingFileAppender，并且这个Appender与你日志配置的Appenders没有任何关系。
-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。
+2. 我发现Log4J2MetricsFileWriter中创建RollingFileAppender是使用一个标记为过期的createAppender方法，为什么不使用新的的newBuilder ... build模式？
+ 开发的时候发现newBuilder ... build与微服务框架存在某种冲突导致不可用，另外，官方文档的[示例代码](https://logging.apache.org/log4j/2.x/manual/customconfig.html)仍然使用的是createAppender，缺乏资料也给定位问题造成了一定的麻烦；我们未来会去改进，已标记TODO。
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
+ 众所周知，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/_users/metrics-in-1.0.0-m1.md b/_users/metrics-in-1.0.0-m1.md
new file mode 100644
index 0000000..79cfb2e
--- /dev/null
+++ b/_users/metrics-in-1.0.0-m1.md
@@ -0,0 +1,208 @@
+---
+title: "Metrics in 1.0.0-m1"
+lang: en
+ref: metrics
+permalink: /users/metrics-in-1.0.0-m1/
+excerpt: "Metrics in 1.0.0-m1"
+last_modified_at: 2017-12-30T10:01:43-04:00
+redirect_from:
+ - /theme-setup/
+---
+
+{% include toc %}
+Metrics had supported from Java chassis version 0.5.0,in version 1.0.0-m1,we had reconstruction it and add some more features,please checkout the user guide and [release note](https://github.com/apache/incubator-servicecomb-java-chassis/releases) for more information.Also subscribe ServiceComb mail-list(dev-subscribe@servicecomb.incubator.apache.org) and join discussion is welcome.
+
+## Background
+Microservice is trend of technology,it resolve many problems also follows new problem.
+
+
+
+This is traditional software architecture always called 'Monolithic',it's difficult for developer maintain the code or add new feature because of tight coupling,but it's easy for operation engineer deploy and maintenance(only one system process).
+
+
+
+This is microservice system architecture,after split 'Monolithic' into many small services,developer obtain many benefits such as architecture independent and more agility etc,but operation engineer need to maintenance a whole lot of microservice instances.If don't import metrics,when system is abnormal or user experience getting worse,it's very difficult to dentifying where the problem is and make some strategy in order to prevent it.
+
+## 1.0.00-m1 Principles
+In previous version(0.5.0)，implementation of metrics had some imperfections:
+1. Metrics code written in foundation-metrics module,it's a low level module,and include some customized function;
+2. Use ThreadLocal variable collect and statistics data,performance hight but has memory leak risk;
+3. Output data of metrics is joined text not dependent number,difficult to reuse;
+4. Not support publish,unable integration with other monitor system;
+5. Because foundation-metrics is a low level module and certainly be loaded,user can't exclude it if unnecessary.
+
+So,upgrading from 0.5.0 to 1.0.0-m1,we had done a fully reconstruction,now it's include this modules:
+
+| Module Name | Description |
+| :------------------ | :--------------------------------------- |
+| metrics-core | Metrics core module,work immediately after imported |
+| metrics-common | Metrics common module,include DTO classes |
+| metrics-extension | Include some metrics extension module |
+| metrics-integration | Include metrics Integration with other monitor system |
+
+The dependency of this modules is:
+
+
+### Use event collect invocation data,not from Hystrix(handler-bizkeeper)any more
+From 1.0.0-m1 invocation data such as TPS and latency are collected from invocation event,not from Hystrix（handler-bizkeeper） any more,so you don't need add Java Chassis Bizkeeper Handler only for metrics.we use EventBus in foundation-common,when DefaultEventListenerManager in metrics-core had initialized,three event listener class will be auto registered:
+
+| Event Listener Name | Description |
+| :------------------------------------- | :--------------------------------------- |
+| InvocationStartedEventListener | Trigger when consumer or producer called |
+| InvocationStartProcessingEventListener | Trigger when producer fetch invocation from queue and start process |
+| InvocationFinishedEventListener | Trigger when consumer call returned or producer process finished |
+
+*ServiceComb java chassis had used [Vertx](http://vertx.io/) as Reactor framework,in synchronous call mode when producer received invocation from consumer,it won't start process immediately but put it into a queue,this queue called invocation queue(like disk queue in operation system),time waiting in the queue called **LifeTimeInQueue**,the length of the queue called **waitInQueue**,this two metrics are very important for measure stress of the microservice;consumer not has this queue,so [...]
+
+The code for trigger event write in RestInvocation,HighwayServerInvoke and InvokerUtils,if microservice don't import metrics,event listener of metrics won't be registered,the impact on performance is little.
+
+### Use Netflix Servo as Monitor of Metric
+[Netflix Servo](https://github.com/Netflix/servo) had implement a collection of high performance monitor,we had used four of them:
+
+| Monitor Name | Description |
+| :----------- | :-------------------------------- |
+| BasicCounter | As name of it,always increment |
+| StepCounter | Called 'ResettableCounter' before |
+| MinGauge | Mark min value in step |
+| MaxGauge | Mark max value in step |
+
+*The version of Servo we used is 0.10.1*
+
+### Window Time(also may called 'Polling Interval' or 'Step Cycle')
+Metrics had many classifications,we can divided them into two major types by how get value:
+1. Direct get
+ You can direct get newest value anytime,such as system resource usage include cpu load rate,running thread count,heap size and call count,queue length,etc.
+2. From statistics
+ After a 'certain time' passed can counting the value,this time we called 'Window Time',include:
+ a) Take one from many,like Max、Min、Median;
+ b) Time-related,like TPS(transaction per second);
+ c) Count-related,like average,variance.
+ If get value of this type,the result returned is the last 'Step Cycle' counted.in Servo,this time called ['Polling Intervals'](https://github.com/Netflix/servo/wiki/Getting-Started).
+ From 1.0.0-m1,can set **servicecomb.metrics.window_time** in microservice.yaml,it has same effect as set **servo.pollers**.
+
+## Metric List
+From 1.0.0-m1,start support output metrics of operation level:
+
+| Group | Level | Catalog | Metrics | Item |
+| :---------- | :--------------------- | :------- | :-------------- | :------------- |
+| servicecomb | instance | system | cpu | load |
+| servicecomb | instance | system | cpu | runningThreads |
+| servicecomb | instance | system | heap | init |
+| servicecomb | instance | system | heap | max |
+| servicecomb | instance | system | heap | commit |
+| servicecomb | instance | system | heap | used |
+| servicecomb | instance | system | nonHeap | init |
+| servicecomb | instance | system | nonHeap | max |
+| servicecomb | instance | system | nonHeap | commit |
+| servicecomb | instance | system | nonHeap | used |
+| servicecomb | instance | operationName | producer | waitInQueue | count |
+| servicecomb | instance | operationName | producer | lifeTimeInQueue | average |
+| servicecomb | instance | operationName | producer | lifeTimeInQueue | max |
+| servicecomb | instance | operationName | producer | lifeTimeInQueue | min |
+| servicecomb | instance | operationName | producer | executionTime | average |
+| servicecomb | instance | operationName | producer | executionTime | max |
+| servicecomb | instance | operationName | producer | executionTime | min |
+| servicecomb | instance | operationName | producer | producerLatency | average |
+| servicecomb | instance | operationName | producer | producerLatency | max |
+| servicecomb | instance | operationName | producer | producerLatency | min |
+| servicecomb | instance | operationName | producer | producerCall | total |
+| servicecomb | instance | operationName | producer | producerCall | tps |
+| servicecomb | instance | operationName | consumer | consumerLatency | average |
+| servicecomb | instance | operationName | consumer | consumerLatency | max |
+| servicecomb | instance | operationName | consumer | consumerLatency | min |
+| servicecomb | instance | operationName | consumer | consumerCall | total |
+| servicecomb | instance | operationName | consumer | consumerCall | tps |
+
+**When the value of Level is 'instance',it's means microservice instance metric,otherwise specific operation metric,operationName same as Java Chassis MicroserviceQualifiedName,it's joined with microservice appId.SchemaID.methodName.**
+
+## How Configuration
+### Global Configuration
+Please add window time config in microservice.yaml:
+```yaml
+APPLICATION_ID: demo
+service_description:
+ name: demoService
+ version: 0.0.1
+
+servicecomb:
+ metrics:
+ #window time,same as servo.pollers,unit is millisecond
+ #support multi window time and use ',' split them,like 5000,10000
+ window_time: 5000,10000
+```
+
+*The setting of window time is very important to getting value of metrics,here is a comment show how it effect*
+
+
+
+### Maven Configuration
+We just only need add metrics-core dependency:
+```xml
+ <dependency>
+ <groupId>io.servicecomb</groupId>
+ <artifactId>metrics-core</artifactId>
+ <version>1.0.0-m1</version>
+ </dependency>
+```
+
+## Metrics Publish
+After configuration completed,you can get collected metrics data via this method:
+### Embedded publish interface
+When microservice start-up,metrics-core will auto publish data service using Springmvc provider:
+```java
+@RestSchema(schemaId = "metricsEndpoint")
+@RequestMapping(path = "/metrics")
+public class DefaultMetricsPublisher implements MetricsPublisher {
+
+ private final DataSource dataSource;
+
+ public DefaultMetricsPublisher(DataSource dataSource) {
+ this.dataSource = dataSource;
+ }
+
+ @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();
+ }
+
+ @ApiResponses({
+ @ApiResponse(code = 400, response = String.class, message = "illegal request content"),
+ })
+ @RequestMapping(path = "/{windowTime}", method = RequestMethod.GET)
+ @CrossOrigin
+ @Override
+ public RegistryMetric metricsWithWindowTime(@PathVariable(name = "windowTime") long windowTime) {
+ return dataSource.getRegistryMetric(windowTime);
+ }
+}
+```
+So,if you had config rest provider in microservice.yaml,like:
+```yaml
+cse:
+ service:
+ registry:
+ address: http://127.0.0.1:30100
+ rest:
+ address: 0.0.0.0:8080
+```
+You can open a browser and input http://localhost:8080/metrics direct get metrics data.
+### Direct programming get
+From above code you can known,the interface of data provider bean is io.servicecomb.metrics.core.publish.DataSource,so if you want develop your own metrics publisher,autowired it is enough.
+```java
+@Autowired
+private DataSource dataSource;
+```
+
+## Other Reference
+We had developed two use case for reference:
+1. metrics-wirte-file:ouput metrics data into files,code is at metrics-extension;
+2. metrics-prometheus:integration with prometheus,publish metrics as prometheus producer.
\ No newline at end of file
diff --git a/_users/cn/metrics-integration-with-prometheus-in-1.0.0-m1.md b/_users/metrics-integration-with-prometheus-in-1.0.0-m1.md
similarity index 50%
copy from _users/cn/metrics-integration-with-prometheus-in-1.0.0-m1.md
copy to _users/metrics-integration-with-prometheus-in-1.0.0-m1.md
index 8bbaf40..10da41d 100644
--- a/_users/cn/metrics-integration-with-prometheus-in-1.0.0-m1.md
+++ b/_users/metrics-integration-with-prometheus-in-1.0.0-m1.md
@@ -1,24 +1,24 @@
---
-title: "1.0.0-m1版本中的监控如何集成普罗米修斯"
-lang: cn
+title: "Metrics how integration with prometheus in 1.0.0-m1"
+lang: en
ref: metrics
-permalink: /cn/users/metrics-integration-with-prometheus-in-1.0.0-m1/
-excerpt: "1.0.0-m1版本中的监控如何集成普罗米修斯"
+permalink: /users/metrics-integration-with-prometheus-in-1.0.0-m1/
+excerpt: "Metrics how integration with prometheus in 1.0.0-m1"
last_modified_at: 2018-1-2T10:01:43-04:00
redirect_from:
- /theme-setup/
---
{% include toc %}
-微服务框架从0.5.0版本开始支持监控功能Metrics，1.0.0-m1版本正式发布，我们会继续追加新特性新功能，订阅ServiceComb邮件列表(dev-subscribe@servicecomb.incubator.apache.org)以持续获取最新信息。
+Metrics had supported from Java chassis version 0.5.0,in version 1.0.0-m1,we had reconstruction it and add some more features,please checkout the user guide and [release note](https://github.com/apache/incubator-servicecomb-java-chassis/releases) for more information.Also subscribe ServiceComb mail-list(dev-subscribe@servicecomb.incubator.apache.org) and join discussion is welcome.
-## 背景
-[普罗米修斯](http://www.prometheus.io/)是相似于Google Borgmon的一个开源监控系统，也是[CNCF](https://www.cncf.io/)的成员之一，目前社区非常活跃，Java Chassis Metrics在1.0.0-m1中支持对接普罗米修斯，并进一步实现使用[Grafana](https://grafana.com/)查询Metrics数据。
+## Background
+[Prometheus](http://www.prometheus.io/) is a opensource open-source monitoring solution like Google Borgmon,also member of [CNCF](https://www.cncf.io/),community is very active.Java chassis metrics support integration with prometheus in 1.0.0-m1,and can use [Grafana](https://grafana.com/) to query metrics data further.
-## 对接原理
-由于Java Chassis由Java语言开发，我们使用[prometheus java client](https://github.com/prometheus/client_java)中的Simple Client作为对接SDK，版本为0.1.0。
-Prometheus推荐Pull模式拉取Metrics数据，被监控微服务作为Producer发布数据provider接口，我们采用Simple Http Server发布微服务采集到的Metrics数据。
-作为一个集成（可选）模块，代码在metrics-integration/metrics-prometheus中，你可以看到它依赖：
+## Integration Principles
+We known Java chassis developed by Java,so we use Simple Client in [prometheus java client](https://github.com/prometheus/client_java) as SDK,the version we use is 0.1.0.
+Prometheus use pull mode collect metrics data,microservice act as producer,we use Simple HTTP Server(also in client java SDK) publish them;
+As an integration(optional) module,the implementation code is in metrics-integration/metrics-prometheus,you can get it's dependency:
```xml
<dependency>
<groupId>io.prometheus</groupId>
@@ -34,9 +34,9 @@ Prometheus推荐Pull模式拉取Metrics数据，被监控微服务作为Producer
<artifactId>metrics-core</artifactId>
</dependency>
```
-因此一旦集成Prometheus引入了metrics-prometheus依赖后，不再需要添加metrics-core的依赖。
-### 与metrics-core Publish的关系
-文档[1.0.0-m1版本中的监控](/cn/users/metrics-in-1.0.0-m1/)中已经提到，metrics-core会伴随微服务启动内置的数据发布，如果你在microservice.yaml中配置了rest provider，例如：
+So if we import metrics-prometheus,no longer need to add metrics-core dependence.
+### Relation between metrics-core Publish
+[Metrics in 1.0.0-m1](/users/metrics-in-1.0.0-m1/) had already been mentioned,metrics-core will auto start up a embedded publish interface,so if you had configured rest provider in microservice.yaml like:
```yaml
cse:
service:
@@ -45,7 +45,7 @@ cse:
rest:
address: 0.0.0.0:8080
```
-你就可以通过http://localhost:8080/metrics 直接获取到Metrics数据，它返回的是io.servicecomb.metrics.common.RegistryMetric实体对象，输出格式为：
+You can direct get metrics data at http://localhost:8080/metrics ,it will return a entity of io.servicecomb.metrics.common.RegistryMetric,the output is:
```json
{"instanceMetric":{
"systemMetric":{"cpuLoad":10.0,"cpuRunningThreads":39,"heapInit":266338304,"heapMax":3786407936,"heapCommit":626524160,"heapUsed":338280024,"nonHeapInit":2555904,"nonHeapMax":-1,"nonHeapCommit":60342272,"nonHeapUsed":58673152},
@@ -55,7 +55,7 @@ cse:
"producerMetrics":{"calculator.metricsEndpoint.metrics":{"operationName":"calculator.metricsEndpoint.metrics","prefix":"servicecomb.calculator.metricsEndpoint.metrics.producer","waitInQueue":0,"lifeTimeInQueue":{"total":0,"count":0,"min":0,"max":0,"average":0.0},"executionTime":{"total":0,"count":0,"min":0,"max":0,"average":0.0},"producerLatency":{"total":0,"count":0,"min":0,"max":0,"average":0.0},"producerCall":{"total":1,"tps":0.0}}
}}
```
-但使用Prometheus Simple Http Server接口发布的数据是Prometheus采集的标准格式：
+But use Prometheus Simple HTTP Server provider interface will publish the standard format which prometheus needed:
```text
# HELP Instance Level Instance Level Metrics
# TYPE Instance Level untyped
@@ -75,16 +75,15 @@ servicecomb_calculator_metricsEndpoint_metrics_producer_executionTime_total 0.0
servicecomb_calculator_metricsEndpoint_metrics_producer_waitInQueue_count 0.0
servicecomb_calculator_metricsEndpoint_metrics_producer_lifeTimeInQueue_count 0.0
```
-所以它们两个是完全独立各有用途的，取决你如何使用。
+So they are two independent,different for use.
-*Prometheus Simple Http Server同样使用/metrics作为默认URL，metrics-prometheus会使用9696作为默认端口，因此微服务启动后你可以使用http://localhost:9696/metrics 访问它。*
+*Prometheus Simple HTTP Server also use /metrics as default URL,metrics-prometheus will use 9696 as default port,after microservice start up you can get metrics data at http://localhost:9696/metrics .*
+The metrics name in prometheus we replace all dot with underline,because we must follow its [naming rules](https://prometheus.io/docs/practices/naming/).
-我们可以看到在Prometheus的Metric命名统一使用下划线代替了点，因为需要遵守它的[命名规则](https://prometheus.io/docs/practices/naming/)。
-
-## 如何配置
-开启对接普罗米修斯非常简单：
-### 全局配置
-microservice.yaml中有如下配置项：
+## How Configuration
+Enable prometheus integration is very easy:
+### Global Configuration
+Please add prometheus port config in microservice.yaml:
```yaml
APPLICATION_ID: demo
service_description:
@@ -94,12 +93,12 @@ service_description:
servicecomb:
metrics:
prometheus:
- #prometheus provider的端口
+ #prometheus provider port
port: 9696
```
-*如果不做配置，默认端口为9696*
-### 依赖配置
-只需要添加metrics-prometheus依赖即可：
+*If do not config,default value is 9696*
+### Maven Configuration
+We just only need add metrics-prometheus dependency:
```xml
<dependency>
<groupId>io.servicecomb</groupId>
@@ -107,8 +106,8 @@ servicecomb:
<version>1.0.0-m1</version>
</dependency>
```
-### 配置Prometheus的prometheus.yml
-你需要在prometheus.yml中配置数据采集job，例如
+### Config prometheus.yml in Prometheus
+You need add job in prometheus.yml,like:
```yaml
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
@@ -128,13 +127,13 @@ scrape_configs:
static_configs:
- targets: ['localhost:9696']
```
-其中job_name: 'servicecomb'即自定义的job配置，目标是本地微服务localhost:9696，关于prometheus.yml的配置更多信息可以参考[这篇文章](https://prometheus.io/docs/prometheus/latest/configuration/configuration/)。
-### 配置Grafana（可选）
-如何在Grafana中添加Prometheus作为数据源请参考[这篇文章](https://prometheus.io/docs/visualization/grafana/)。
-## 运行效果
-配置好并启动了微服务、Prometheus之后，就可以打开Prometheus Web界面（默认地址是http://localhost:9090/ ），在Metrics列表中看到ServiceComb开头的Java Chassis Metrics，如下图所示：
-
+The job_name: 'servicecomb' is our custom job,it will collect metrics data from local microservice localhost:9696,more information about configuration of prometheus can found [here](https://prometheus.io/docs/prometheus/latest/configuration/configuration/).
-为了能够达到更好的查询效果，在Grafana中添加Prometheus作为数据源，通过Grafana查询数据如下图示：
+### Config Grafana(optional)
+How add prometheus as a datasource in grafana can found [here](https://prometheus.io/docs/visualization/grafana/).
+## Effect Show
+After complete prometheus config and start up microservice,we can open prometheus web site(default address is http://localhost:9090/),in metrics list java chassis metrics with prefix 'servicecomb' can be seen:
+
+For get more better data query experience,add prometheus as a datasource in grafana then query metrics data by it:
\ No newline at end of file
--
To stop receiving notification emails like this one, please contact
['"commits@servicecomb.apache.org" <co...@servicecomb.apache.org>'].