1.metric统计
1.1 为什么需要监控与报警?
HystrixCommand执行的时候,会生成一些执行耗时等方面的统计信息。这些信息对于系统的运维来说,是很有帮助的,因为我们通过这些统计信息可以看到整个系统是怎么运行的。hystrix对每个command key都会提供一份metric,而且是秒级统计粒度的。
这些统计信息,无论是单独看,还是聚合起来看,都是很有用的。如果将一个请求中的多个command的统计信息拿出来单独查看,包括耗时的统计,对debug系统是很有帮助的。聚合起来的metric对于系统层面的行为来说,是很有帮助的,很适合做报警或者报表。hystrix dashboard就很适合。
1.2 hystrix的事件类型
对于hystrix command来说,只会返回一个值,execute只有一个event type,fallback也只有一个event type,那么返回一个SUCCESS就代表着命令执行的结束。
对于hystrix observable command来说,多个值可能被返回,所以emit event代表一个value被返回,success代表成功,failure代表异常。
(1) execute event type
event type | 描述 |
---|---|
EMIT | observable command返回一个value |
SUCCESS | 完成执行,并且没有报错 |
FAILURE | 执行时抛出了一个异常,会触发fallback |
TIMEOUT | 开始执行了,但是在指定时间内没有完成执行,会触发fallback |
BAD_REQUEST | 执行的时候抛出了一个HystrixBadRequestException |
SHORT_CIRCUITED | 短路器打开了,触发fallback |
THREAD_POOL_REJECTED | 线程成的容量满了,被reject,触发fallback |
SEMAPHORE_REJECTED | 信号量的容量满了,被reject,触发fallback |
(2) fallback event type
event type | 描述 |
---|---|
FALLBACK_EMIT | observable command,fallback value被返回了 |
FALLBACK_SUCCESS | fallback逻辑执行没有报错 |
FALLBACK_FAILURE | fallback逻辑抛出了异常,会报错 |
FALLBACK_REJECTION | fallback的信号量容量满了,fallback不执行,报错 |
FALLBACK_MISSING | fallback没有实现,会报错 |
(3) 其他的event type
event type | 描述 |
---|---|
EXCEPTION_THROWN | command生命自周期是否抛出了异常 |
RESPONSE_FROM_CACHE | command是否在cache中查找到了结果 |
COLLAPSED | command是否是一个合并batch中的一个 |
(4) thread pool event type
event type | 描述 |
---|---|
EXECUTED | 线程池有空间,允许command去执行了 |
REJECTED | 线程池没有空间,不允许command执行,reject掉了 |
(5) collapser event type
event type | 描述 |
---|---|
BATCH_EXECUTED | collapser合并了一个batch,并且执行了其中的command |
ADDED_TO_BATCH | command加入了一个collapser batch |
RESPONSE_FROM_CACHE | 没有加入batch,而是直接取了request cache中的数据 |
1.3 metric storage
(1) metric被生成之后,就会按照一段时间来存储,存储了一段时间的数据才会推送到其他系统中,比如hystrix dashboard
(2) 另外一种方式,就是每次生成metric就实时推送metric流到其他地方,但是这样的话,会给系统带来很大的压力
(3) hystrix的方式是将metric写入一个内存中的数据结构中,在一段时间之后就可以查询到
(4) hystrix 1.5x之后,采取的是为每个command key都生成一个start event和completion event流,而且可以订阅这个流。每个thread pool key也是一样的,包括每个collapser key也是一样的。
(5) 每个command的event是发送给一个线程安全的RxJava中的rx.Subject,因为是线程安全的,所以不需要进行线程同步
(6) 因此每个command级别的,threadpool级别的,每个collapser级别的,event都会发送到对应的RxJava的rx.Subject对象中。这些rx.Subject对象接着就会被暴露出Observable接口,可以被订阅。
1.4 metric统计相关的配置
-
metrics.rollingStats.timeInMilliseconds
HystrixCommandProperties.Setter() .withMetricsRollingStatisticalWindowInMilliseconds(int value)
(1) 设置统计的rolling window,单位是毫秒,hystrix只会维持这段时间内的metric供短路器统计使用
(2) 这个属性是不允许热修改的,默认值是10000,就是10秒钟 -
metrics.rollingStats.numBuckets
HystrixCommandProperties.Setter() .withMetricsRollingStatisticalWindowBuckets(int value)
(1) 该属性设置每个滑动窗口被拆分成多少个bucket,而且滑动窗口对这个参数必须可以整除,同样不允许热修改。默认值是10,也就是说,每秒钟是一个bucket
(2) 随着时间的滚动,比如又过了一秒钟,那么最久的一秒钟的bucket就会被丢弃,然后新的一秒的bucket会被创建
(3) 如果将timeInMilliseconds设置为10s,numBuckets设置为10个桶,即每个桶表示1s时间,则统计信息如下图:
-
metrics.rollingPercentile.enabled
HystrixCommandProperties.Setter() .withMetricsRollingPercentileEnabled(boolean value)
控制是否追踪请求耗时,以及通过百分比方式来统计,默认是true
-
metrics.rollingPercentile.timeInMilliseconds
HystrixCommandProperties.Setter() .withMetricsRollingPercentileWindowInMilliseconds(int value)
(1) 设置rolling window被持久化保存的时间,这样才能计算一些请求耗时的百分比,默认是60000,60s,不允许热修改
(2) 相当于是一个大的rolling window,专门用于计算请求执行耗时的百分比
-
metrics.rollingPercentile.numBuckets
HystrixCommandProperties.Setter() .withMetricsRollingPercentileWindowBuckets(int value)
设置rolling percentile window被拆分成的bucket数量,上面那个参数除以这个参数必须能够整除,不允许热修改。默认值是6,也就是每10s被拆分成一个bucket
-
metrics.rollingPercentile.bucketSize
HystrixCommandProperties.Setter() .withMetricsRollingPercentileBucketSize(int value)
(1) 设置每个bucket的请求执行次数被保存的最大数量,如果在一个bucket内,执行次数超过了这个值,那么就会重新覆盖从bucket的开始再写。
(2) 举例来说,如果bucket size设置为100,而且每个bucket代表一个10秒钟的窗口,但是在这个bucket内发生了500次请求执行,那么这个bucket内仅仅会保留100次执行
(3) 如果调大这个参数,就会提升需要耗费的内存,来存储相关的统计值,不允许热修改,默认值是100。
-
metrics.healthSnapshot.intervalInMilliseconds
HystrixCommandProperties.Setter() .withMetricsHealthSnapshotIntervalInMilliseconds(int value)
控制成功和失败的百分比计算,与影响短路器之间的等待时间,默认值是500毫秒
2.dashboard
2.1 安装metrics stream
<dependency>
<groupId>com.netflix.hystrix</groupId>
<artifactId>hystrix-metrics-event-stream</artifactId>
<version>1.4.10</version>
</dependency>
@Bean
public ServletRegistrationBean indexServletRegistration() {
ServletRegistrationBean registration = new ServletRegistrationBean(new HystrixMetricsStreamServlet());
registration.addUrlMappings("/hystrix.stream");
return registration;
}
2.2 安装gradle
类似于maven,一种java里面的打包和构建的工具,hystrix是用gradle去管理打包和构建的
配置环境变量,GRADLE_HOME
配置PATH,%GRADLE_HOME%/bin
gradle -v
2.3 部署dashboard war包
- 安装tomcat7
- cp hystrix-dashboard-.war apache-tomcat-7./webapps/hystrix-dashboard.war
2.4 turbin
turbin是用来监控一个集群的,可以将一个集群的所有机器都配置在这里
cp turbine-web/build/libs/turbine-web-*.war ./apache-tomcat-7.*/webapps/turbine.war
在/WEB-INF/classes下放置配置文件
config.properties
turbine.ConfigPropertyBasedDiscovery.default.instances=localhost
turbine.instanceUrlSuffix=:8081/hystrix.stream
2.4 启动tomcat中的hystrix dashboard和turbin、以业务
localhost:8080/hystrix-dashboard
http://localhost:8081/hystrix.stream,监控单个机器
http://localhost:8080/turbine/turbine.stream,监控整个集群
2.5 发送几个请求,看看效果
2.6 hystrix dashboard
-
hystrix的dashboard可以支持实时监控metric
-
netflix开始用这个dashboard的时候,大幅度优化了工程运维的操作,帮助节约了恢复系统的时间。大多数生产系统的故障持续时间变得很短,而且影响幅度小了很多,主要是因为hystrix dashborad提供了可视化的监控。
-
dashboard上的指标都是什么?
(1) 圆圈的颜色和大小代表了健康状况以及流量,折线代表了最近2分钟的请求流量
(2) 集群中的机器数量,请求延时的中位数以及平均值
(3) 最近10秒内的异常请求比例,请求QPS,每台机器的QPS,以及整个集群的QPS
(4) 断路器的状态
最近一分钟的请求延时百分比,TP90,TP99,TP99.5
(5) 几个有颜色的数字,代表了最近10秒钟的统计,以1秒钟为粒度
成功的请求数量,绿颜色的数字; 短路的请求数量,蓝色的数字; timeout超时的请求数量,黄色的数字; 线程池reject的请求数量,紫色的数字; 请求失败,抛出异常的请求数量,红色的数字