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