16.hystrix的metric统计相关的各种高阶配置

1、为什么需要监控与报警？


HystrixCommand执行的时候，会生成一些执行耗时等方面的统计信息。这些信息对于系统的运维来说，是很有帮助的，因为我们通过这些统计信息可以看到整个系统是怎么运行的。hystrix对每个command key都会提供一份metric，而且是秒级统计粒度的。


这些统计信息，无论是单独看，还是聚合起来看，都是很有用的。如果将一个请求中的多个command的统计信息拿出来单独查看，包括耗时的统计，对debug系统是很有帮助的。聚合起来的metric对于系统层面的行为来说，是很有帮助的，很适合做报警或者报表。hystrix dashboard就很适合。


2、hystrix的事件类型


对于hystrix command来说，只会返回一个值，execute只有一个event type，fallback也只有一个event type，那么返回一个SUCCESS就代表着命令执行的结束


对于hystrix observable command来说，多个值可能被返回，所以emit event代表一个value被返回，success代表成功，failure代表异常


（1）execute 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


FALLBACK_EMIT observable command，fallback value被返回了
FALLBACK_SUCCESS fallback逻辑执行没有报错
FALLBACK_FAILURE fallback逻辑抛出了异常，会报错
FALLBACK_REJECTION fallback的信号量容量满了，fallback不执行，报错
FALLBACK_MISSING fallback没有实现，会报错


（3）其他的event type


EXCEPTION_THROWN command生命自周期是否抛出了异常
RESPONSE_FROM_CACHE command是否在cache中查找到了结果
COLLAPSED command是否是一个合并batch中的一个


（4）thread pool event type


EXECUTED 线程池有空间，允许command去执行了
REJECTED 线程池没有空间，不允许command执行，reject掉了


（5）collapser event type


BATCH_EXECUTED collapser合并了一个batch，并且执行了其中的command
ADDED_TO_BATCH command加入了一个collapser batch
RESPONSE_FROM_CACHE 没有加入batch，而是直接取了request cache中的数据


3、metric storage


metric被生成之后，就会按照一段时间来存储，存储了一段时间的数据才会推送到其他系统中，比如hystrix dashboard


另外一种方式，就是每次生成metric就实时推送metric流到其他地方，但是这样的话，会给系统带来很大的压力


hystrix的方式是将metric写入一个内存中的数据结构中，在一段时间之后就可以查询到


hystrix 1.5x之后，采取的是为每个command key都生成一个start event和completion event流，而且可以订阅这个流。每个thread pool key也是一样的，包括每个collapser key也是一样的。


每个command的event是发送给一个线程安全的RxJava中的rx.Subject，因为是线程安全的，所以不需要进行线程同步


因此每个command级别的，threadpool级别的，每个collapser级别的，event都会发送到对应的RxJava的rx.Subject对象中。这些rx.Subject对象接着就会被暴露出Observable接口，可以被订阅。


5、metric统计相关的配置


（1）metrics.rollingStats.timeInMilliseconds


设置统计的rolling window，单位是毫秒，hystrix只会维持这段时间内的metric供短路器统计使用


这个属性是不允许热修改的，默认值是10000，就是10秒钟


HystrixCommandProperties.Setter()
   .withMetricsRollingStatisticalWindowInMilliseconds(int value)


（2）metrics.rollingStats.numBuckets


该属性设置每个滑动窗口被拆分成多少个bucket，而且滑动窗口对这个参数必须可以整除，同样不允许热修改


默认值是10，也就是说，每秒钟是一个bucket


随着时间的滚动，比如又过了一秒钟，那么最久的一秒钟的bucket就会被丢弃，然后新的一秒的bucket会被创建


HystrixCommandProperties.Setter()
   .withMetricsRollingStatisticalWindowBuckets(int value)


（3）metrics.rollingPercentile.enabled


控制是否追踪请求耗时，以及通过百分比方式来统计，默认是true


HystrixCommandProperties.Setter()
   .withMetricsRollingPercentileEnabled(boolean value)


（4）metrics.rollingPercentile.timeInMilliseconds


设置rolling window被持久化保存的时间，这样才能计算一些请求耗时的百分比，默认是60000，60s，不允许热修改


相当于是一个大的rolling window，专门用于计算请求执行耗时的百分比


HystrixCommandProperties.Setter()
   .withMetricsRollingPercentileWindowInMilliseconds(int value)


（5）metrics.rollingPercentile.numBuckets


设置rolling percentile window被拆分成的bucket数量，上面那个参数除以这个参数必须能够整除，不允许热修改


默认值是6，也就是每10s被拆分成一个bucket


HystrixCommandProperties.Setter()
   .withMetricsRollingPercentileWindowBuckets(int value)


（6）metrics.rollingPercentile.bucketSize


设置每个bucket的请求执行次数被保存的最大数量，如果再一个bucket内，执行次数超过了这个值，那么就会重新覆盖从bucket的开始再写


举例来说，如果bucket size设置为100，而且每个bucket代表一个10秒钟的窗口，但是在这个bucket内发生了500次请求执行，那么这个bucket内仅仅会保留100次执行


如果调大这个参数，就会提升需要耗费的内存，来存储相关的统计值，不允许热修改


默认值是100


HystrixCommandProperties.Setter()
   .withMetricsRollingPercentileBucketSize(int value)


（7）metrics.healthSnapshot.intervalInMilliseconds


控制成功和失败的百分比计算，与影响短路器之间的等待时间，默认值是500毫秒


HystrixCommandProperties.Setter()
   .withMetricsHealthSnapshotIntervalInMilliseconds(int value)