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/03 13:59:41 UTC
[incubator-servicecomb-website] branch master updated: [SCB-118] CN
Prometheus Integration MD (#22)
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 6c9b4f9 [SCB-118] CN Prometheus Integration MD (#22)
6c9b4f9 is described below
commit 6c9b4f910aaf1f69307919953b2f0945eb49b6fb
Author: zhengyangyong <ya...@huawei.com>
AuthorDate: Wed Jan 3 21:59:39 2018 +0800
[SCB-118] CN Prometheus Integration MD (#22)
* delete en Metrics because is cn and add write file md
Signed-off-by: zhengyangyong <ya...@huawei.com>
* delete en Metrics because is cn and add write file md
Signed-off-by: zhengyangyong <ya...@huawei.com>
* add metrics 1.0.0-m1 md
Signed-off-by: zhengyangyong <ya...@huawei.com>
* minor update
Signed-off-by: zhengyangyong <ya...@huawei.com>
* minor update
Signed-off-by: zhengyangyong <ya...@huawei.com>
* minor update
Signed-off-by: zhengyangyong <ya...@huawei.com>
* SCB-118 metrics-integration-with-prometheus cn md
Signed-off-by: zhengyangyong <ya...@huawei.com>
* SCB-118 add navigation
Signed-off-by: zhengyangyong <ya...@huawei.com>
* SCB-118 fix style
Signed-off-by: zhengyangyong <ya...@huawei.com>
* SCB-118 fix style
Signed-off-by: zhengyangyong <ya...@huawei.com>
* SCB-118 fix style
Signed-off-by: zhengyangyong <ya...@huawei.com>
---
_data/navigation.yml | 13 +-
_users/Metrics.md | 140 ---------------
_users/cn/{Metrics.md => metrics-in-0.5.0.md} | 0
_users/cn/metrics-in-1.0.0-m1.md | 194 +++++++++++++++++++++
...rics-integration-with-prometheus-in-1.0.0-m1.md | 140 +++++++++++++++
...-write-file-extension-and-sample-in-1.0.0-m1.md | 173 ++++++++++++++++++
assets/images/MetricsDependency.png | Bin 0 -> 10921 bytes
assets/images/MetricsInGrafana.png | Bin 0 -> 35400 bytes
assets/images/MetricsInPrometheus.png | Bin 0 -> 60061 bytes
assets/images/TimeWindowComment.png | Bin 0 -> 45282 bytes
10 files changed, 516 insertions(+), 144 deletions(-)
diff --git a/_data/navigation.yml b/_data/navigation.yml
index 848a0d2..bb6c190 100755
--- a/_data/navigation.yml
+++ b/_data/navigation.yml
@@ -92,9 +92,6 @@ t:
- title: Zuul
url: /users/edging-service/zuul/
- - title: Metrics
- url: /users/metrics/
-
- title: Deployment
children:
- title: Run Mode
@@ -214,7 +211,15 @@ t:
url: /cn/users/edging-service/zuul/
- title: 监控
- url: /cn/users/metrics/
+ children:
+ - title: 0.5.0版本中的监控
+ url: /cn/users/metrics-in-0.5.0/
+ - title: 1.0.0-m1版本中的监控
+ url: /cn/users/metrics-in-1.0.0-m1/
+ - title: 1.0.0-m1版本写文件扩展和示例
+ url: /cn/users/metrics-write-file-extension-and-sample-in-1.0.0-m1/
+ - title: 1.0.0-m1版本中的监控如何集成普罗米修斯
+ url: /cn/users/metrics-integration-with-prometheus-in-1.0.0-m1/
- title: 部署
children:
diff --git a/_users/Metrics.md b/_users/Metrics.md
deleted file mode 100644
index d1257e9..0000000
--- a/_users/Metrics.md
+++ /dev/null
@@ -1,140 +0,0 @@
----
-title: "Metrics Monitor in 0.5.0"
-lang: en
-ref: metrics
-permalink: /users/metrics/
-excerpt: "Metrics Monitor in 0.5.0"
-last_modified_at: 2017-12-29T14:01:43-04:00
-redirect_from:
- - /theme-setup/
----
-
-{% include toc %}
-微服务框架从0.5.0版本开始支持监控功能Metrics，请注意这个功能还处于开发（Preview）阶段，并且我们未来会做较大的调整，更多讨论请订阅ServiceComb邮件列表(dev-subscribe@servicecomb.incubator.apache.org)。
-
-## 背景
-将系统微服务化是技术潮流和趋势，但是它解决了很多问题的同时也带来了新的问题。
-
-
-
-这是传统单体系统架构图，对运维人员友好，但是对开发人员不友好，系统维护升级困难。
-
-
-
-这是微服务化后的系统架构图，经过功能切分，开发人员得到解脱，拥有了极致的CI/CD，但是运维人员却需要维护海量的微服务实例，所以如果不进行性能监控，就无法定位时延高的微服务，也无法制定弹性伸缩策略。
-
-## 原理
-0.5.0版本的Metrics会在Java Chassis的Invocation中埋入计数器，也会使用Hystrix收集TPS和Latency，同时收集微服务实例的CPU使用率和内存使用量，最终通过输出日志的方式输出收集到的Metrics数据。
-输入日志使用的是SLF4J作为日志框架，未与任何具体的日志框架绑定，我们会通过定向Logger名输出的方式将不同的Metrics输出为一个个独立的文件，因此需要在你的日志配置中添加对应的配置项，[这篇文章](https://stackoverflow.com/questions/9652032/how-can-i-create-2-separate-log-files-with-one-log4j-config-file)详细说明了如果使用Log4j作为日志实现如何配置，而[这篇文章](https://stackoverflow.com/questions/36643692/log4j2-multiple-appenders-the-same-output-is-written-to-multiple-files)则详细介绍了如果使用Log4j2作为日志需要如何配置。
-Logger名指的是LoggerFactory.getLogger后的第一个参数：
-```java
-static final Logger log = LoggerFactory.getLogger("${Logger名}");
-log.trace("${Metric数据}");
-```
-*为不影响调试，log的输出级别为trace
-
-以下是我们的定向Logger名以及输出的Metrics含义：
-
-| Logger名 | Metric含义 |
-| :--------------------------------------- | :-------------------- |
-| averageServiceExecutionTime | Producer端调用平均执行时间 |
-| averageTimeInQueue | Producer端调用在队列中的平均时间 |
-| countInQueue | Producer端在队列中等待的调用的数量 |
-| cpuLoad | 实例CPU使用率 |
-| cpuRunningThreads | 实例运行线程数量 |
-| heapCommit，heapInit，heapMax，heapUsed | 内存Heap使用状况 |
-| nonHeapCommit，nonHeapInit，nonHeapMax，nonHeapUsed | 内存NonHeap使用状况 |
-| latency | 调用平均时延 |
-| tps | 每秒调用数（Transaction per seconds） |
-| maxLifeTimeInQueue | Producer端调用在队列中最大等待时间 |
-| minLifeTimeInQueue | Producer端调用在队列中最小等待时间 |
-| totalRequestsPerProvider | Producer总请求数 |
-| totalRequestsPerConsumer | Consumer总请求数 |
-| totalFailedRequestsPerProvider | Producer失败总请求数 |
-| totalFailRequestsPerConsumer | Consumer失败总请求数 |
-
-## 如何配置
-请在microservice.yaml中添加如下配置项：
-```yaml
-APPLICATION_ID: demo
-service_description:
- name: demoService
- version: 0.0.1
-
-servicecomb:
- metrics:
- #metrics数据采集时间（同样是写文件间隔），单位秒
- polltime: 5
- #如果metric是浮点数，输出结果保留几位小数，默认为1
- round_places: 1
- file:
- #是否启用文件输出
- enabled: true
- #会体现为输出内容中的plugin_id
- name_prefix: bmi.calculator
-```
-
-## 注意事项
-* 需要在provider治理链中添加bizkeeper-provider，否则TPS和Latency无数据
-```yaml
-APPLICATION_ID: demo
-service_description:
- name: demoService
- version: 0.0.1
-cse:
- handler:
- chain:
- Provider:
- default: bizkeeper-provider
-```
-
-## 配置示例
-
-以设置averageServiceExecutionTime为例，如果是Log4j，配置如下：
-```properties
-#指定Logger名为averageServiceExecutionTime
-log4j.category.averageServiceExecutionTime=TRACE, averageServiceExecutionTimeLogger
-#定向日志，不扩散到别的Logger中
-log4j.additivity.averageServiceExecutionTime=false
-#使用RollingFileAppender
-log4j.appender.averageServiceExecutionTimeLogger=org.apache.log4j.RollingFileAppender
-log4j.appender.averageServiceExecutionTimeLogger.File=/target/averageServiceExecutionTime.log
-log4j.appender.averageServiceExecutionTimeLogger.MaxFileSize=10MB
-log4j.appender.averageServiceExecutionTimeLogger.MaxBackupIndex=10
-log4j.appender.averageServiceExecutionTimeLogger.layout=org.apache.log4j.PatternLayout
-log4j.appender.averageServiceExecutionTimeLogger.layout.ConversionPattern=%m%n
-log4j.appender.averageServiceExecutionTimeLogger.append=true
-```
-
-如果是Log4j2，配置如下：
-```xml
-<!--Log4j2配置支持全局配置-->
-<Properties>
- <Property name="maxFileSize">10MB</Property>
- <Property name="maxFileCount">10</Property>
- <Property name="filePath">/target</Property>
- <Property name="filePrefix">bmi.calculator</Property>
-</Properties>
-
-<Appenders>
- <RollingFile name="averageServiceExecutionTime" fileName="${filePath}${filePrefix}.averageServiceExecutionTime.dat"
- filePattern="${filePath}${filePrefix}.averageServiceExecutionTime-%i.dat">
- <PatternLayout pattern="%m%n"/>
- <SizeBasedTriggeringPolicy size="${maxFileSize}"/>
- <DefaultRolloverStrategy max="${maxFileCount}"/>
- </RollingFile>
-</Appenders>
-
-<Loggers>
- <Logger name="averageServiceExecutionTime" level="trace" additivity="false">
- <AppenderRef ref="averageServiceExecutionTime"/>
- </Logger>
-</Loggers>
-```
-
-剩余Metric（参见原理章节中的表格）按照上面的例子重复替换即可。
-
-## 输出效果
-每一个文件就是一个微服务示例级别的metrics数据输出，0.5.0版本还不支持Operation级别的Metrics输出：
-
-
diff --git a/_users/cn/Metrics.md b/_users/cn/metrics-in-0.5.0.md
similarity index 100%
rename from _users/cn/Metrics.md
rename to _users/cn/metrics-in-0.5.0.md
diff --git a/_users/cn/metrics-in-1.0.0-m1.md b/_users/cn/metrics-in-1.0.0-m1.md
new file mode 100644
index 0000000..70e5ed1
--- /dev/null
+++ b/_users/cn/metrics-in-1.0.0-m1.md
@@ -0,0 +1,194 @@
+---
+title: "1.0.0-m1版本中的监控"
+lang: cn
+ref: metrics
+permalink: /cn/users/metrics-in-1.0.0-m1/
+excerpt: "1.0.0-m1版本中的监控"
+last_modified_at: 2017-12-30T10: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)以持续获取最新信息。
+
+## 背景
+将系统微服务化是技术潮流和趋势，但是它解决了很多问题的同时也带来了新的问题。
+
+
+
+这是传统单体系统架构图，对运维人员友好，但是对开发人员不友好，系统维护升级困难。
+
+
+
+这是微服务化后的系统架构图，经过功能切分，开发人员得到解脱，拥有了极致的CI/CD，但是运维人员却需要维护海量的微服务实例，所以如果不进行性能监控，就无法定位时延高的微服务，也无法制定弹性伸缩策略。
+
+## 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模块过于底层，用户无法以可选的方式决定是否启用；
+
+因此，从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的一些示例 |
+
+它们的依赖关系如下图所示：
+
+
+### 数据采集不再依赖Hystrix（handler-bizkeeper），使用事件埋点收集与调用相关的所有数据
+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的RestInvocation、HighwayServerInvoke、HighwayClient和VertxHttpMethod中，如果微服务没有启用Metrics，EventBus中不会注入事件监听处理类，因此对性能的影响微乎其微。
+
+### 使用Netflix Servo作为Metric的计数器
+Netflix Servo具有性能极高的计数器（Monitor），我们使用了四种：
+
+| Monitor名 | 描述 |
+| :----------- | :------------ |
+| BasicCounter | 基本累积计数器（永续累加） |
+| StepCounter | 周期累加计数器 |
+| 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一致。
+
+## 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.操作方法名的组合。
+
+## 如何配置
+### 全局配置
+请在microservice.yaml中添加如下配置项：
+```yaml
+APPLICATION_ID: demo
+service_description:
+ name: demoService
+ version: 0.0.1
+
+servicecomb:
+ metrics:
+ #时间窗间隔，与servo.pollers设置效果一致，单位毫秒
+ #支持多个时间窗间隔，使用逗号（,）将多个分隔开，例如5000,10000，代表设置两个时间窗，第一个时间窗5000的windowTimeIndex为0，第二个时间窗10000的windowTimeIndex为1，依此类推
+ window_time: 5000
+```
+*时间窗设置对于统计结果获取的影响，附上代码中包含的一段注释如下：
+
+
+### 依赖配置
+只需要添加metrics-core依赖即可：
+```xml
+ <dependency>
+ <groupId>io.servicecomb</groupId>
+ <artifactId>metrics-core</artifactId>
+ <version>1.0.0-m1</version>
+ </dependency>
+```
+
+## 数据发布
+配置好Metrics后，你可以通过如下两种方式获取Metrics数据：
+### 内置的发布接口
+当微服务启动后，metrics-core会自动以Springmvc的方式发布服务：
+```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)
+ @Override
+ public List<Long> getAppliedWindowTime() {
+ return dataSource.getAppliedWindowTime();
+ }
+
+ @RequestMapping(path = "/", method = RequestMethod.GET)
+ @Override
+ public RegistryMetric metrics() {
+ return dataSource.getRegistryMetric();
+ }
+
+ @RequestMapping(path = "/{windowTimeIndex}", method = RequestMethod.GET)
+ @Override
+ public RegistryMetric metricsWithWindowTimeIndex(@PathVariable(name = "windowTimeIndex") int windowTimeIndex) {
+ return dataSource.getRegistryMetric(windowTimeIndex);
+ }
+}
+```
+因此，如果你在microservice.yaml中配置了rest provider，例如：
+```yaml
+cse:
+ service:
+ registry:
+ address: http://127.0.0.1:30100
+ rest:
+ address: 0.0.0.0:8080
+```
+你就可以通过http://localhost:8080/metrics 直接获取到数据，打开浏览器输入此URL就可以看到返回结果。
+### 直接代码获取
+从上面的代码可以看到，数据提供Bean接口是io.servicecomb.metrics.core.publish.DataSource，因此如果你希望自己开发数据发布程序，只需要注入它即可。
+```java
+@Autowired
+private DataSource dataSource;
+```
+*我们已经开发完成了两个使用场景可以作为参考：
+1.metrics-wirte-file：将Metrics数据写入文件，代码在metrics-extension中
+2.metrics-prometheus：将Metrics发布为prometheus Producer
+
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
new file mode 100644
index 0000000..8bbaf40
--- /dev/null
+++ b/_users/cn/metrics-integration-with-prometheus-in-1.0.0-m1.md
@@ -0,0 +1,140 @@
+---
+title: "1.0.0-m1版本中的监控如何集成普罗米修斯"
+lang: cn
+ref: metrics
+permalink: /cn/users/metrics-integration-with-prometheus-in-1.0.0-m1/
+excerpt: "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)以持续获取最新信息。
+
+## 背景
+[普罗米修斯](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数据。
+作为一个集成（可选）模块，代码在metrics-integration/metrics-prometheus中，你可以看到它依赖：
+```xml
+ <dependency>
+ <groupId>io.prometheus</groupId>
+ <artifactId>simpleclient</artifactId>
+ </dependency>
+ <dependency>
+ <groupId>io.prometheus</groupId>
+ <artifactId>simpleclient_httpserver</artifactId>
+ </dependency>
+
+ <dependency>
+ <groupId>io.servicecomb</groupId>
+ <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，例如：
+```yaml
+cse:
+ service:
+ registry:
+ address: http://127.0.0.1:30100
+ rest:
+ address: 0.0.0.0:8080
+```
+你就可以通过http://localhost:8080/metrics 直接获取到Metrics数据，它返回的是io.servicecomb.metrics.common.RegistryMetric实体对象，输出格式为：
+```json
+{"instanceMetric":{
+"systemMetric":{"cpuLoad":10.0,"cpuRunningThreads":39,"heapInit":266338304,"heapMax":3786407936,"heapCommit":626524160,"heapUsed":338280024,"nonHeapInit":2555904,"nonHeapMax":-1,"nonHeapCommit":60342272,"nonHeapUsed":58673152},
+"consumerMetric":{"operationName":"instance","prefix":"servicecomb.instance.consumer","consumerLatency":{"total":0,"count":0,"min":0,"max":0,"average":0.0},"consumerCall":{"total":0,"tps":0.0}},
+"producerMetric":{"operationName":"instance","prefix":"servicecomb.instance.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}}},
+"consumerMetrics":{},
+"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采集的标准格式：
+```text
+# HELP Instance Level Instance Level Metrics
+# TYPE Instance Level untyped
+servicecomb_instance_producer_producerLatency_average 0.0
+servicecomb_instance_producer_producerLatency_total 0.0
+servicecomb_instance_consumer_producerLatency_count 0.0
+...
+servicecomb_instance_producer_producerLatency_min 0.0
+servicecomb_instance_producer_lifeTimeInQueue_average 0.0
+servicecomb_instance_producer_lifeTimeInQueue_count 0.0
+servicecomb_instance_system_heap_init 2.66338304E8
+# HELP calculator.metricsEndpoint.metrics Producer Side calculator.metricsEndpoint.metrics Producer Side Metrics
+# TYPE calculator.metricsEndpoint.metrics Producer Side untyped
+servicecomb_calculator_metricsEndpoint_metrics_producer_lifeTimeInQueue_average 0.0
+...
+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的Metric命名统一使用下划线代替了点，因为需要遵守它的[命名规则](https://prometheus.io/docs/practices/naming/)。
+
+## 如何配置
+开启对接普罗米修斯非常简单：
+### 全局配置
+microservice.yaml中有如下配置项：
+```yaml
+APPLICATION_ID: demo
+service_description:
+ name: demoService
+ version: 0.0.1
+
+servicecomb:
+ metrics:
+ prometheus:
+ #prometheus provider的端口
+ port: 9696
+```
+*如果不做配置，默认端口为9696*
+### 依赖配置
+只需要添加metrics-prometheus依赖即可：
+```xml
+ <dependency>
+ <groupId>io.servicecomb</groupId>
+ <artifactId>metrics-prometheus</artifactId>
+ <version>1.0.0-m1</version>
+ </dependency>
+```
+### 配置Prometheus的prometheus.yml
+你需要在prometheus.yml中配置数据采集job，例如
+```yaml
+scrape_configs:
+ # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
+ - job_name: 'prometheus'
+
+ # metrics_path defaults to '/metrics'
+ # scheme defaults to 'http'.
+
+ static_configs:
+ - targets: ['localhost:9090']
+
+ - job_name: 'servicecomb'
+
+ # metrics_path defaults to '/metrics'
+ # scheme defaults to 'http'.
+
+ 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，如下图所示：
+
+
+为了能够达到更好的查询效果，在Grafana中添加Prometheus作为数据源，通过Grafana查询数据如下图示：
+
+
\ No newline at end of file
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
new file mode 100644
index 0000000..39d8d0d
--- /dev/null
+++ b/_users/cn/metrics-write-file-extension-and-sample-in-1.0.0-m1.md
@@ -0,0 +1,173 @@
+---
+title: "1.0.0-m1版本写文件扩展和示例"
+lang: cn
+ref: metrics
+permalink: /cn/users/metrics-write-file-extension-and-sample-in-1.0.0-m1/
+excerpt: "1.0.0-m1版本写文件扩展和示例"
+last_modified_at: 2017-12-29T10: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)以持续获取最新信息。
+
+## 背景
+0.5.0版本的foundation-metrics实现了将采集到的Metrics数据写入文件，在1.0.0-m1中，此功能移动到metrics-extension中；
+从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写文件 |
+
+*暂未提供logback的metrics-write-file-config，参考Log4j和log4j2的例子可以很容易实现metrics-write-file-config-logback
+
+## 配置
+### 全局配置
+与0.5.0类似，需要在microservice.yaml中添加如下配置项：
+```yaml
+APPLICATION_ID: demo
+service_description:
+ name: demoService
+ version: 0.0.1
+
+servicecomb:
+ metrics:
+ #1.0.0-m1日志输出间隔配置项，单位毫秒
+ window_time: 5000
+ #如果metric是浮点数，输出结果保留几位小数，默认为1
+ round_places: 1
+ file:
+ #日志根目录
+ root_path: ./log/metric/
+ rolling:
+ #最大保留文件数
+ max_file_count: 10
+ #文件最大大小，单位可以是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文件里的。
+
+### 依赖配置
+Java Chassis支持直接启动和Spring Boot Starter启动两种模式，两种模式下的配置详细描述如下：
+#### 直接启动（不使用Spring Boot）依赖配置
+##### 项目使用log4j作为日志实现
+请参考samples/metrics-write-file-sample/metrics-write-file-log4j项目：
+```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>
+ <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项目：
+```xml
+ <!--need exclusion log4j-over-slf4j-->
+ <dependency>
+ <groupId>org.springframework.boot</groupId>
+ <artifactId>spring-boot-starter</artifactId>
+ <exclusions>
+ <exclusion>
+ <groupId>org.slf4j</groupId>
+ <artifactId>log4j-over-slf4j</artifactId>
+ </exclusion>
+ </exclusions>
+ </dependency>
+
+ <!--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-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>
+
+ <!--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造成任何影响，两者并存，因此依赖方面与直接启动是相同的。
+
+## Q & A
+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模式？
+开发的时候发现newBuilder ... build与微服务框架存在某种冲突导致不可用，另外，官方文档的[示例代码](https://logging.apache.org/log4j/2.x/manual/customconfig.html)仍然使用的是createAppender，缺乏资料也给定位问题造成了一定的麻烦；我们将在下一个版本1.0.0-m2中去修复，已标记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
diff --git a/assets/images/MetricsDependency.png b/assets/images/MetricsDependency.png
new file mode 100644
index 0000000..8133e13
Binary files /dev/null and b/assets/images/MetricsDependency.png differ
diff --git a/assets/images/MetricsInGrafana.png b/assets/images/MetricsInGrafana.png
new file mode 100644
index 0000000..99d381c
Binary files /dev/null and b/assets/images/MetricsInGrafana.png differ
diff --git a/assets/images/MetricsInPrometheus.png b/assets/images/MetricsInPrometheus.png
new file mode 100644
index 0000000..136eb1f
Binary files /dev/null and b/assets/images/MetricsInPrometheus.png differ
diff --git a/assets/images/TimeWindowComment.png b/assets/images/TimeWindowComment.png
new file mode 100644
index 0000000..ac682f6
Binary files /dev/null and b/assets/images/TimeWindowComment.png differ
--
To stop receiving notification emails like this one, please contact
['"commits@servicecomb.apache.org" <co...@servicecomb.apache.org>'].