应用性能监控(metrics)
应用性能监控通过周期性的统计数据,帮助开发者分析业务性能瓶颈,在性能优化、故障定位的时候非常有帮助。应用性能监控的指标包括 请求各个环节的时延、线程池使用情况、连接池使用情况、CPU和网络使用情况等。
统计数据是一个周期性时效数据,只在统计周期内具有意义。可以选择通过 REST
接口查询实时的统计数据,也可以通过日志开关,将
统计数据输出到日志文件里面,帮助分析性能问题。
使用方法
使用应用性能监控非常简单, 只需要在应用中包含相关的依赖包,通过配置项开启和关闭相关功能。
- 开启应用性能监控功能, 需要引入下面的依赖:
``` <dependency> <groupId>org.apache.servicecomb</groupId> <artifactId>metrics-core</artifactId> </dependency> ```
通过在 microservice.yaml
中增加下面的配置项,就可以将性能统计数据输出到日志文件中。
```
servicecomb:
metrics:
window_time: 60000
invocation:
latencyDistribution: 0,1,10,100,1000
Consumer.invocation.slow:
enabled: true
msTime: 1000
Provider.invocation.slow:
enabled: true
msTime: 1000
publisher.defaultLog:
enabled: true
endpoints.client.detail.enabled: true
```
上述配置开启了慢调用检测,如果存在慢调用,则会立即输出相应日志:
```
2019-04-02 23:01:09,103\[WARN]\[pool-7-thread-74]\[5ca37935c00ff2c7-350076] - slow(40 ms) invocation, CONSUMER highway perf1.impl.syncQuery
http method: GET
url : /v1/syncQuery/{id}/
server : highway://192.168.0.152:7070?login=true
status code: 200
total : 50.760 ms
prepare : 0.0 ms
handlers request : 0.0 ms
client filters request : 0.0 ms
send request : 0.5 ms
get connection : 0.0 ms
write to buf : 0.5 ms
wait response : 50.727 ms
wake consumer : 0.23 ms
client filters response: 0.2 ms
handlers response : 0.0 ms (SlowInvocationLogger.java:121)
```
其中 5ca37935c00ff2c7-350076 是 ${traceId}-${invocationId}
的结构,在log4j2 或 logback 的输出格式中通过 %marker 引用。
也可以通过 REST
接口查询性能统数据。使用浏览器访问http://ip:port/metrics 即可,将会得到类似下面格式的json数据:
```
{
"servicecomb.vertx.endpoints(address=192.168.0.124:7070,statistic=connectCount,type=client)": 0.0,
"servicecomb.vertx.endpoints(address=192.168.0.124:7070,statistic=disconnectCount,type=client)": 0.0,
"servicecomb.vertx.endpoints(address=192.168.0.124:7070,statistic=connections,type=client)": 1.0,
"servicecomb.vertx.endpoints(address=192.168.0.124:7070,statistic=bytesRead,type=client)": 508011.0,
"servicecomb.vertx.endpoints(address=192.168.0.124:7070,statistic=bytesWritten,type=client)": 542163.0,
"servicecomb.vertx.endpoints(address=192.168.0.124:7070,statistic=queueCount,type=client)": 0.0,
"servicecomb.vertx.endpoints(address=0.0.0.0:7070,statistic=connectCount,type=server)": 0.0,
"servicecomb.vertx.endpoints(address=0.0.0.0:7070,statistic=disconnectCount,type=server)": 0.0,
"servicecomb.vertx.endpoints(address=0.0.0.0:7070,statistic=connections,type=server)": 1.0,
"servicecomb.vertx.endpoints(address=0.0.0.0:7070,statistic=bytesRead,type=server)": 542163.0
... ...
}
```
集成Prometheus
Prometheus (普罗米修斯)是一个名字非常酷的开源监控系统。
它支持多维度的指标数据模型,服务端通过HTTP协议定时拉取数据后,通过灵活的查询语言,实现监控的目的。
servicecomb的应用性能监控功能支持对接Prometheus,首先需要在您的业务项目中加入如下依赖:
```
<dependency>
<groupId>org.apache.servicecomb</groupId>
<artifactId>metrics-prometheus</artifactId>
</dependency>
```
然后在 microservice.yaml 中增加下面的配置项:
```
servicecomb:
metrics:
prometheus:
address: ${ip}:${port}
```
该配置项是设置普罗米修斯框架监听的端口,您只需使用浏览器访问对应的ip地址加该端口即http://ip:port/metrics 就可以获得如下格式的监控数据:
```
# HELP ServiceComb_Metrics ServiceComb Metrics
# TYPE ServiceComb_Metrics untyped
threadpool_rejectedCount{appId="springmvctest",id="cse.executor.groupThreadPool-group0",} 0.0
threadpool_rejectedCount{appId="springmvctest",id="cse.executor.groupThreadPool-group1",} 0.0
threadpool_taskCount{appId="springmvctest",id="cse.executor.groupThreadPool-group1",} 0.0
threadpool_currentThreadsBusy{appId="springmvctest",id="cse.executor.groupThreadPool-group1",} NaN
threadpool_taskCount{appId="springmvctest",id="cse.executor.groupThreadPool-group0",} 0.0
threadpool_currentThreadsBusy{appId="springmvctest",id="cse.executor.groupThreadPool-group0",} NaN
threadpool_poolSize{appId="springmvctest",id="cse.executor.groupThreadPool-group0",} NaN
threadpool_poolSize{appId="springmvctest",id="cse.executor.groupThreadPool-group1",} NaN
threadpool_completedTaskCount{appId="springmvctest",id="cse.executor.groupThreadPool-group0",} 0.0
servicecomb_vertx_endpoints{appId="springmvctest",address="0.0.0.0:7070",statistic="connectCount",type="server",} 0.0
servicecomb_vertx_endpoints{appId="springmvctest",address="0.0.0.0:7070",statistic="disconnectCount",type="server",} 0.0
servicecomb_vertx_endpoints{appId="springmvctest",address="0.0.0.0:7070",statistic="connections",type="server",} 0.0
servicecomb_vertx_endpoints{appId="springmvctest",address="0.0.0.0:7070",statistic="bytesRead",type="server",} 0.0
servicecomb_vertx_endpoints{appId="springmvctest",address="0.0.0.0:7070",statistic="bytesWritten",type="server",} 0.0
servicecomb_vertx_endpoints{appId="springmvctest",address="0.0.0.0:7070",statistic="requests",type="server",} 0.0
servicecomb_vertx_endpoints{appId="springmvctest",address="0.0.0.0:7070",statistic="latency",type="server",} 0.0
servicecomb_vertx_endpoints{appId="springmvctest",address="0.0.0.0:7070",statistic="rejectByConnectionLimit",type="server",} 0.0
servicecomb_vertx_endpoints{appId="springmvctest",address="0.0.0.0:8080",statistic="connectCount",type="server",} 0.0
servicecomb_vertx_endpoints{appId="springmvctest",address="0.0.0.0:8080",statistic="disconnectCount",type="server",} 0.0
servicecomb_vertx_endpoints{appId="springmvctest",address="0.0.0.0:8080",statistic="connections",type="server",} 0.0
servicecomb_vertx_endpoints{appId="springmvctest",address="0.0.0.0:8080",statistic="bytesRead",type="server",} 0.0
servicecomb_vertx_endpoints{appId="springmvctest",address="0.0.0.0:8080",statistic="bytesWritten",type="server",} 0.0
servicecomb_vertx_endpoints{appId="springmvctest",address="0.0.0.0:8080",statistic="requests",type="server",} 0.0
servicecomb_vertx_endpoints{appId="springmvctest",address="0.0.0.0:8080",statistic="latency",type="server",} 0.0
servicecomb_vertx_endpoints{appId="springmvctest",address="0.0.0.0:8080",statistic="rejectByConnectionLimit",type="server",} 0.0
threadpool_completedTaskCount{appId="springmvctest",id="cse.executor.groupThreadPool-group1",} 0.0
threadpool_maxThreads{appId="springmvctest",id="cse.executor.groupThreadPool-group0",} NaN
threadpool_maxThreads{appId="springmvctest",id="cse.executor.groupThreadPool-group1",} NaN
threadpool_queueSize{appId="springmvctest",id="cse.executor.groupThreadPool-group0",} NaN
threadpool_queueSize{appId="springmvctest",id="cse.executor.groupThreadPool-group1",} NaN
threadpool_corePoolSize{appId="springmvctest",id="cse.executor.groupThreadPool-group0",} NaN
threadpool_corePoolSize{appId="springmvctest",id="cse.executor.groupThreadPool-group1",} NaN
```
注:默认端口是9696,您也可以根据实际业务要求进行修改。
配置说明
配置项 | 默认值 | 含义 |
---|---|---|
servicecomb.metrics.window_time | 60000 | 统计周期,单位为毫秒 TPS、时延等等周期性的数据,每周期更新一次,在周期内获取到的值,实际是上一周期的值 |
servicecomb.metrics .invocation.latencyDistribution |
时延分布时间段定义,单位为毫秒 例如:0,1,10,100,1000 表示定义了下列时延段[0, 1),[1, 10),[10, 100),[100, 1000),[1000, ) |
|
servicecomb.metrics .Consumer.invocation.slow.enabled |
false | 是否开启Consumer端的慢调用检测 通过增加后缀.${service}.${schema}.${operation},可以支持4级优先级定义 |
servicecomb.metrics .Consumer.invocation.slow.msTime |
1000 | 时延超过配置值,则会立即输出日志,记录本次调用的stage耗时信息 通过增加后缀.${service}.${schema}.${operation},可以支持4级优先级定义 |
servicecomb.metrics .Provider.invocation.slow.enabled |
false | 是否开启Provide端的慢调用检测 通过增加后缀.${service}.${schema}.${operation},可以支持4级优先级定义 |
servicecomb.metrics .Provider.invocation.slow.msTime |
1000 | 时延超过配置值,则会立即输出日志,记录本次调用的stage耗时信息 通过增加后缀.${service}.${schema}.${operation},可以支持4级优先级定义 |
servicecomb.metrics .prometheus.address |
0.0.0.0:9696 | prometheus监听地址 |
servicecomb.metrics.publisher.defaultLog .enabled |
false | 是否输出默认的统计日志 |
servicecomb.metrics.publisher.defaultLog .endpoints.client.detail.enabled |
false | 是否输出每一条client endpoint统计日志,因为跟目标的ip:port数有关,可能会有很多数据,所以默认不输出 |
统计指标含义说明
- CPU 统计信息
Name | Tag keys | Tag values | 含义 |
---|---|---|---|
os | type | cpu | 当前周期内系统CPU使用率,Solaris模式 |
processCpu | 当前周期内微服务进程CPU使用率,IRIX模式 processCpu除以cpu近似等于系统CPU数 |
- 网络统计信息
Name | Tag keys | Tag values | 含义 |
---|---|---|---|
os | type | net | |
statistic | send | 当前周期内平均每秒发送的字节数(Bps) | |
receive | 当前周期内平均每秒接收的字节数(Bps) | ||
sendPackets | 当前周期内平均每秒发送的包数(pps) | ||
receivePackets | 当前周期内平均每秒接收的包数(pps) | ||
interface | 网卡设备名 |
- vertx client endpoints 统计信息
Name | Tag keys | Tag values | 含义 |
---|---|---|---|
servicecomb .vertx .endpoints |
type | client | |
address | ${ip}:${port} | 服务端的ip:port | |
statistic | connectCount | 当前周期内共发起多少次连接 | |
disconnectCount | 当前周期内断连的次数 | ||
queueCount | http连接池中正在等待获取连接的请求数 | ||
connections | 当前时刻的连接数 | ||
bytesRead | 当前周期内平均每秒接收的字节数(Bps) 业务层的统计,相对从网卡获取的数据,这里的数据不包括包头的大小 对于http消息,不包括http header大小 |
||
bytesWritten | 当前周期内平均每秒发送的字节数(Bps) 业务层的统计,相对从网卡获取的数据,这里的数据不包括包头的大小 对于http消息,不包括http header大小 |
- vertx server endpoints 统计信息
Name | Tag keys | Tag values | 含义 |
---|---|---|---|
servicecomb .vertx .endpoints |
type | server | |
address | ${ip}:${port} | 监听的ip:port | |
statistic | connectCount | 当前周期内共接入多少次连接 | |
disconnectCount | 当前周期内断连的次数 | ||
rejectByConnectionLimit | 当前周期内因超出连接数限制而主动断连的次数 | ||
connections | 当前时刻的连接数 | ||
bytesRead | 当前周期内平均每秒发送的字节数(Bps) 业务层的统计,相对从网卡获取的数据,这里的数据不包括包头的大小 对于http消息,不包括http header大小 |
||
bytesWritten | 当前周期内平均每秒接收的字节数(Bps) 业务层的统计,相对从网卡获取的数据,这里的数据不包括包头的大小 对于http消息,不包括http header大小 |
- 时延分布概览
Name | Tag keys | Tag values | 含义 |
---|---|---|---|
servicecomb .invocation |
role | CONSUMER、PRODUCER、EDGE | 是CONSUMER、PRODUCER还是EDGE端的统计 |
operation | ${microserviceName} .${schemaId} .${operationName} |
调用的方法名 | |
transport | highway或rest | 调用是在哪个传输通道上发生的 | |
status | http status code | ||
type | latencyDistribution | 调用时延分布 | |
scope | [${min}, ${max}) | 当前周期内调用时延大于等于min,小于max的次数 [${min},)表示max为无限大 |
- consumer 详细时延分布
Name | Tag keys | Tag values | 含义 |
---|---|---|---|
servicecomb .invocation |
role | CONSUMER | CONSUMER端的统计 |
operation | ${microserviceName} .${schemaId} .${operationName} |
调用的方法名 | |
transport | highway或rest | 调用是在哪个传输通道上发生的 | |
status | http status code | ||
type | stage | stage时延 | |
stage | total | 全流程 | |
prepare | 初始化 | ||
handlers_request | handler链请求流程 | ||
client_filters_request | http client filter链请求流程 只有走rest transport才有本阶段 |
||
consumer_send_request | 发送请求阶段,包括consumer_get_connection和consumer_write_to_buf | ||
consumer_get_connection | 从连接池获取连接 | ||
consumer_write_to_buf | 向网络缓冲区写数据 | ||
consumer_wait_response | 等待服务端应答 | ||
consumer_wake_consumer | 同步流程中,收到应答后,从唤醒等待线程,到等待线程开始处理应答的耗时 | ||
client_filters_response | http client filter链应答流程 | ||
handlers_response | handler链应答流程 | ||
statistic | count | 平均每秒调用次数,即TPS count=统计周期内的调用次数/周期(秒) |
|
totalTime | 单位为秒 totalTime=当前周期内的调用耗时总时长/周期(秒) totalTime除以count即可得到平均时延 |
||
max | 单位为秒 当前周期内最大耗时 |
- provider 详细时延分布
Name | Tag keys | Tag values | 含义 |
---|---|---|---|
servicecomb .invocation |
role | PRODUCER | PRODUCER端的统计 |
operation | ${microserviceName} .${schemaId} .${operationName} |
调用的方法名 | |
transport | highway或rest | 调用是在哪个传输通道上发生的 | |
status | http status code | ||
type | stage | stage时延 | |
stage | total | 全流程 | |
prepare | 初始化 | ||
queue | 仅在使用线程池时有意义 表示调用在线程池中排队的时长 |
||
server_filters_request | http server filter链请求流程 只有走rest transport才有本阶段 |
||
handlers_request | handler链请求流程 | ||
execution | 业务方法 | ||
handlers_response | handler链应答流程 | ||
server_filters_response | http server filter链应答流程 | ||
producer_send_response | 发送应答 | ||
statistic | count | 平均每秒调用次数,即TPS count=统计周期内的调用次数/周期(秒) |
|
totalTime | 单位为秒 totalTime=当前周期内的调用耗时总时长/周期(秒) totalTime除以count即可得到平均时延 |
||
max | 单位为秒 当前周期内最大耗时 |
- edge service 详细时延分布
Name | Tag keys | Tag values | 含义 |
---|---|---|---|
servicecomb .invocation |
role | EDGE | EDGE的统计 |
operation | ${microserviceName} .${schemaId} .${operationName} |
调用的方法名 | |
transport | highway或rest | 调用是在哪个传输通道上发生的 | |
status | http status code | ||
type | stage | stage时延 | |
stage | total | 全流程 | |
prepare | 初始化 | ||
queue | 仅在使用线程池时有意义 表示调用在线程池中排队的时长 |
||
server_filters_request | http server filter链请求流程 | ||
handlers_request | handler链请求流程 | ||
client_filters_request | http client filter链请求流程 | ||
consumer_send_request | 发送请求阶段,包括consumer_get_connection和consumer_write_to_buf | ||
consumer_get_connection | 从连接池获取连接 | ||
consumer_write_to_buf | 向网络缓冲区写数据 | ||
consumer_wait_response | 等待服务端应答 | ||
consumer_wake_consumer | 同步流程中,收到应答后,从唤醒等待线程,到等待线程开始处理应答的耗时 | ||
client_filters_response | http client filter链应答流程 | ||
handlers_response | handler链应答流程 | ||
server_filters_response | http server filter链应答流程 | ||
producer_send_response | 发送应答 | ||
statistic | count | 平均每秒调用次数,即TPS count=统计周期内的调用次数/周期(秒) |
|
totalTime | 单位为秒 totalTime=当前周期内的调用耗时总时长/周期(秒) totalTime除以count即可得到平均时延 |
||
max | 单位为秒 当前周期内最大耗时 |
- 线程池信息
Name | Tag keys | Tag values | 含义 |
---|---|---|---|
threadpool.corePoolSize | id | ${threadPoolName} | 最小线程数 |
threadpool.maxThreads | 最大允许的线程数 | ||
threadpool.poolSize | 当前实际线程数 | ||
threadpool.currentThreadsBusy | 当前的活动线程数,即当前正在执行的任务数 | ||
threadpool.queueSize | 当前正在排队的任务数 | ||
threadpool.rejectedCount | 当前周期内平均每秒被拒绝的任务数 | ||
threadpool.taskCount | 统计周期内平均每秒提交的任务数 taskCount=(completed + queue + active)/周期(秒) |
||
threadpool.completedTaskCount | 统计周期内平均每秒完成的任务数 completedTaskCount=completed/周期(秒) |
开发者信息和高级课题
- 实现原理
1. 基于[netflix spectator](https://github.com/Netflix/spectator)
2. Foundation-metrics通过SPI机制加载所有MetricsInitializer实现,实现者可以通过MetricsInitializer中的getOrder规划执行顺序,order数字越小,越先执行。
3. Metrics-core实现3类MetricsInitializer:
1. DefaultRegistryInitializer: 实例化并注册spectator-reg-servo,设置较小的order,保证比下面2类MetricsInitializer先执行
2. Meters Initializer: 实现TPS、时延、线程池、jvm资源等等数据的统计
3. Publisher: 输出统计结果,内置了日志输出,以及通过RESTful接口输出
4. Metrics-prometheus提供与prometheus对接的能力
- 业务定制
因为ServiceComb已经初始化了servo的registry,所以业务不必再创建registry。实现MetricsInitializer接口,定 义业务级的Meters,或实现定制的Publisher,再通过SPI机制声明自己的实现即可。
1.Meters
创建Meters能力均由spectator提供,可查阅[netflix spectator](https://github.com/Netflix/spectator)文档
2.Publisher
周期性输出的场景,比如日志场景,通过eventBus订阅org.apache.servicecomb.foundation.metrics.PolledEvent,PolledEvent.getMeters()即是本周期的统计结果
非周期性输出的场景,比如通过RESTful接口访问,通过globalRegistry.iterator()即可得到本周期的统计结果