Spring Cloud Hystrix Dashboard熔断器-Turbine集群监控（六）

序言

上一篇说啦hystrix的使用方法与配置还有工作流程及为何存在，我去，上一篇这么屌，去看看吧，没这么屌的话，我贴的有官方文档，好好仔细看看

hystrix除啦基本的熔断器功能之外，还可以对接口的qps、是否短路、成功调用、失败调用、线程池状态等进行实时监控。

Hystrix Dashboard是作为断路器状态的一个组件，提供了数据监控和友好的图形化界面。

内置的监控：Hystrix Dashboard

先上个图看下监控页面长啥样有个概念。

• 绿色计数: 表示成功的请求数

• 蓝色计数: 表示断路器打开后，直接被短路的请求数

• 黄色计数: 表示请求超时数

• 紫色计数: 表示因为线程池满而被拒绝的请求数

• 红色计数: 表示因为异常而导致失败的请求数

• 灰色百分比: 表示的是10秒内的错误率统计

• Hosts: 应用个数

• Median: Command 的中位数时间

• Mean: Command 的平均时间

• 90th/99th/99.5th: P90、P99、P99.5 时间

• Rolling 10 second counters: 说明一下计数都是在一个10秒的滚动窗口内统计的

• with 1 second granularity: 这个滚动窗口是以1秒为粒度进行统计的

所有技术和百分比的统计窗口都是10秒（默认值）

Hystrix Dashboard工作过程与搭建

接口通过hystrix封装调用后，可以被/actuator/hystrix.stream发送ping来获取到接口状态，然后通过hystrix dashboad包装展现成为友好的可视化图表。

依赖包

<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
        </dependency>

ServletRegistrationBean 

@Bean
    public ServletRegistrationBean getServlet(){
        HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet();
        ServletRegistrationBean registrationBean = new ServletRegistrationBean(streamServlet);
        registrationBean.setLoadOnStartup(1);
        registrationBean.addUrlMappings("/actuator/hystrix.stream");
        registrationBean.setName("HystrixMetricsStreamServlet");
        return registrationBean;
    }

起始文件注解

@EnableHystrixDashboard
public class StartMain {
    public static void main(String[] args) {
        SpringApplication.run(StartMain.class, args);
    }
}

ok，启动项目

输入:http://localhost:8083/hystrix

输入http://localhost:8083/actuator/hystrix.stream

会一直无限循环ping

hystrix.stream放到第一个界面中，点击monitor stream，出现下面的页面

Turbine集群监控

配置文件

spring.application.name=shouhou-turbine
server.port=8086
turbine.appConfig=TRADE-ORDER
turbine.aggregator.clusterConfig= default
turbine.clusterNameExpression= new String("default")
turbine.combine-host-port=true

eureka.client.serviceUrl.defaultZone=http://localhost:8081/eureka/

note：

• clusterConfig: default # 指定聚合哪些集群，多个使用","分割，默认为default。可使用http://.../turbine.stream?cluster={clusterConfig之一}访问
• appConfig: service_a,service_b # 配置Eureka中的serviceId列表，表明监控哪些服务 
• clusterNameExpression: new String("default")

1.  clusterNameExpression指定集群名称，默认表达式appName；此时：turbine.aggregator.clusterConfig需要配置想要监控的应用名称
2. 当clusterNameExpression: default时，turbine.aggregator.clusterConfig可以不写，因为默认就是default
3. 当clusterNameExpression: metadata['cluster']时，假设想要监控的应用配置了eureka.instance.metadata-map.cluster: ABC，则需要配置，同时turbine.aggregator.clusterConfig: ABC

package trade.shouhou.api;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.hystrix.dashboard.EnableHystrixDashboard;
import org.springframework.cloud.netflix.turbine.EnableTurbine;


@SpringBootApplication
@EnableTurbine
@EnableHystrixDashboard
public class StartMain {
    public static void main(String[] args) {
        SpringApplication.run(StartMain.class, args);
    }
}

 <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-netflix-turbine</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
        </dependency>

输入:http://localhost:8031/turbine.stream,将ping你配置服务中的所有实例接口hystrix监控数据。

至此就所有的搞完啦，具体你关心细节的配置参见官方文档啊。 

Hystrix Metrics 的优缺点

优点：统计粒度小：时间粒度和监控单元粒度。可以帮助我们发现粗粒度监控时不容易发现的问题。

缺点：数据没有持久化，无法查看历史数据 

报警

注：这一段内容和 Hystrix 本身的使用没有直接关系，而是和 Hystrix 相关的微服务治理相关的内容。但建议负责技术、架构，以及负责基础组件和服务研发的同学阅读

在有了监控数据之后，报警功能也是水到渠成，所以这里不谈如何实现基于 Hystrix 监控数据的报警功能。这里我们讨论一下我们是否需要基于 Hystrix 监控数据的报警功能？如果需要，都需要针对哪些指标添加报警？

之所以讨论这个问题，是因为有很多全链路监控解决方案，例如 Spring Cloud Sleuth、Pinpoint 等，都支持对 Hystrix 的监控。所以，监控报警功能并不依赖于 Hystrix 自带的监控数据输出。所以，如果只需要基本的监控报警功能，完全是不需要 Hystrix Metrics 和 Dashboard 功能的。

但 Hystrix 相关的监控数据不同于其它技术，除了超时和错误的监控，还有其它很多细粒度的监控数据。例如，熔断次数、线程池拒绝次数等等。

对于这些细粒度的监控数据，我认为不应该将它们同超时和错误监控等同看待。前者更多的是用于配置调优，后者则主要是一种常规的监控方式。如果我们将 Hystrix Metrics 所提供的所有数据都纳入监控，不仅监控系统，而且，更重要的是，技术人员可能会不堪重sao负rao。过多的监控有时会起到相反的作用，即让技术人员忽视监控。

我认为 Hystrix 相关的报警的一个原则是，报警还应该局限于主要的指标（请求时间、异常）。对于 Hystrix 特有的、细粒度的运行数据，我们需要做到有据可查。以方便开发人员调优.

总结

具体还有怎么让hystrix的监控数据写入Q最终落盘，可对数据进行更全面的分析监控以及结合公司的监控体系让他发挥更大的作用，后面有时间再写。