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 <yangyong.zh...@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 <yangyong.zh...@huawei.com> * delete en Metrics because is cn and add write file md Signed-off-by: zhengyangyong <yangyong.zh...@huawei.com> * add metrics 1.0.0-m1 md Signed-off-by: zhengyangyong <yangyong.zh...@huawei.com> * minor update Signed-off-by: zhengyangyong <yangyong.zh...@huawei.com> * minor update Signed-off-by: zhengyangyong <yangyong.zh...@huawei.com> * minor update Signed-off-by: zhengyangyong <yangyong.zh...@huawei.com> * SCB-118 metrics-integration-with-prometheus cn md Signed-off-by: zhengyangyong <yangyong.zh...@huawei.com> * SCB-118 add navigation Signed-off-by: zhengyangyong <yangyong.zh...@huawei.com> * SCB-118 fix style Signed-off-by: zhengyangyong <yangyong.zh...@huawei.com> * SCB-118 fix style Signed-off-by: zhengyangyong <yangyong.zh...@huawei.com> * SCB-118 fix style Signed-off-by: zhengyangyong <yangyong.zh...@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-subscr...@servicecomb.incubator.apache.org)。 - -## 背景 -将系统微服务化是技术潮流和趋势,但是它解决了很多问题的同时也带来了新的问题。 - -![MonolithicArch](/assets/images/MonolithicArch.png) - -这是传统单体系统架构图,对运维人员友好,但是对开发人员不友好,系统维护升级困难。 - -![MicroserviceArch](/assets/images/MicroserviceArch.png) - -这是微服务化后的系统架构图,经过功能切分,开发人员得到解脱,拥有了极致的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输出: - -![Metrics图片](/assets/images/metrics-output.png) 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-subscr...@servicecomb.incubator.apache.org)以持续获取最新信息。 + +## 背景 +将系统微服务化是技术潮流和趋势,但是它解决了很多问题的同时也带来了新的问题。 + +![MonolithicArch](/assets/images/MonolithicArch.png) + +这是传统单体系统架构图,对运维人员友好,但是对开发人员不友好,系统维护升级困难。 + +![MicroserviceArch](/assets/images/MicroserviceArch.png) + +这是微服务化后的系统架构图,经过功能切分,开发人员得到解脱,拥有了极致的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的一些示例 | + +它们的依赖关系如下图所示: +![MetricsDependency.png](/assets/images/MetricsDependency.png) + +### 数据采集不再依赖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 +``` +*时间窗设置对于统计结果获取的影响,附上代码中包含的一段注释如下: +![TimeWindowComment.png](/assets/images/TimeWindowComment.png) + +### 依赖配置 +只需要添加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-subscr...@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,如下图所示: +![MetricsInPrometheus](/assets/images/MetricsInPrometheus.png) + +为了能够达到更好的查询效果,在Grafana中添加Prometheus作为数据源,通过Grafana查询数据如下图示: + +![MetricsInGrafana](/assets/images/MetricsInGrafana.png) \ 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-subscr...@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" <commits@servicecomb.apache.org>'].