亿级流量电商详情页系统实战-49.hystrix metric和dashboard

小灰灰 2022-11-04 11:28 157阅读 0赞

# 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

<table> 
 <thead> 
  <tr> 
   <th>event type</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>EMIT</td> 
   <td>observable command返回一个value</td> 
  </tr> 
  <tr> 
   <td>SUCCESS</td> 
   <td>完成执行，并且没有报错</td> 
  </tr> 
  <tr> 
   <td>FAILURE</td> 
   <td>执行时抛出了一个异常，会触发fallback</td> 
  </tr> 
  <tr> 
   <td>TIMEOUT</td> 
   <td>开始执行了，但是在指定时间内没有完成执行，会触发fallback</td> 
  </tr> 
  <tr> 
   <td>BAD_REQUEST</td> 
   <td>执行的时候抛出了一个HystrixBadRequestException</td> 
  </tr> 
  <tr> 
   <td>SHORT_CIRCUITED</td> 
   <td>短路器打开了，触发fallback</td> 
  </tr> 
  <tr> 
   <td>THREAD_POOL_REJECTED</td> 
   <td>线程成的容量满了，被reject，触发fallback</td> 
  </tr> 
  <tr> 
   <td>SEMAPHORE_REJECTED</td> 
   <td>信号量的容量满了，被reject，触发fallback</td> 
  </tr> 
 </tbody> 
</table>

(2) fallback event type

<table> 
 <thead> 
  <tr> 
   <th>event type</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>FALLBACK_EMIT</td> 
   <td>observable command，fallback value被返回了</td> 
  </tr> 
  <tr> 
   <td>FALLBACK_SUCCESS</td> 
   <td>fallback逻辑执行没有报错</td> 
  </tr> 
  <tr> 
   <td>FALLBACK_FAILURE</td> 
   <td>fallback逻辑抛出了异常，会报错</td> 
  </tr> 
  <tr> 
   <td>FALLBACK_REJECTION</td> 
   <td>fallback的信号量容量满了，fallback不执行，报错</td> 
  </tr> 
  <tr> 
   <td>FALLBACK_MISSING</td> 
   <td>fallback没有实现，会报错</td> 
  </tr> 
 </tbody> 
</table>

(3) 其他的event type

<table> 
 <thead> 
  <tr> 
   <th>event type</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>EXCEPTION_THROWN</td> 
   <td>command生命自周期是否抛出了异常</td> 
  </tr> 
  <tr> 
   <td>RESPONSE_FROM_CACHE</td> 
   <td>command是否在cache中查找到了结果</td> 
  </tr> 
  <tr> 
   <td>COLLAPSED</td> 
   <td>command是否是一个合并batch中的一个</td> 
  </tr> 
 </tbody> 
</table>

(4) thread pool event type

<table> 
 <thead> 
  <tr> 
   <th>event type</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>EXECUTED</td> 
   <td>线程池有空间，允许command去执行了</td> 
  </tr> 
  <tr> 
   <td>REJECTED</td> 
   <td>线程池没有空间，不允许command执行，reject掉了</td> 
  </tr> 
 </tbody> 
</table>

(5) collapser event type

<table> 
 <thead> 
  <tr> 
   <th>event type</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>BATCH_EXECUTED</td> 
   <td>collapser合并了一个batch，并且执行了其中的command</td> 
  </tr> 
  <tr> 
   <td>ADDED_TO_BATCH</td> 
   <td>command加入了一个collapser batch</td> 
  </tr> 
  <tr> 
   <td>RESPONSE_FROM_CACHE</td> 
   <td>没有加入batch，而是直接取了request cache中的数据</td> 
  </tr> 
 </tbody> 
</table>

## 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时间，则统计信息如下图：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjg2ODYzOA_size_16_color_FFFFFF_t_70]
 *  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包 ##

1.  安装tomcat7
2.  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 ##

1.  hystrix的dashboard可以支持实时监控metric
2.  netflix开始用这个dashboard的时候，大幅度优化了工程运维的操作，帮助节约了恢复系统的时间。大多数生产系统的故障持续时间变得很短，而且影响幅度小了很多，主要是因为hystrix dashborad提供了可视化的监控。
3.  dashboard上的指标都是什么？  
    (1) 圆圈的颜色和大小代表了健康状况以及流量，折线代表了最近2分钟的请求流量  
    (2) 集群中的机器数量，请求延时的中位数以及平均值  
    (3) 最近10秒内的异常请求比例，请求QPS，每台机器的QPS，以及整个集群的QPS  
    (4) 断路器的状态  
    最近一分钟的请求延时百分比，TP90，TP99，TP99.5  
    (5) 几个有颜色的数字，代表了最近10秒钟的统计，以1秒钟为粒度  
    成功的请求数量，绿颜色的数字; 短路的请求数量，蓝色的数字; timeout超时的请求数量，黄色的数字; 线程池reject的请求数量，紫色的数字; 请求失败，抛出异常的请求数量，红色的数字

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjg2ODYzOA_size_16_color_FFFFFF_t_70]: /images/20221023/7d7558d71951425c8eba0ef69b0695a6.png