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

序言

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

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

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

内置的监控：Hystrix Dashboard

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

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

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

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

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

• 红色计数: 表示由于异常而致使失败的请求数

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

• Hosts: 应用个数

• Median: Command 的中位数时间

• Mean: Command 的平均时间

• 90th/99th/99.5th: P90、P9九、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最终落盘，可对数据进行更全面的分析监控以及结合公司的监控体系让他发挥更大的做用，后面有时间再写。