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