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最終落盤，可對資料進行更全面的分析監控以及結合公司的監控體系讓他發揮更大的作用，後面有時間再寫。