附7 turbine
2016-09-01 16:37
127 查看
一、作用
聚集同一个微服务的相同的commandKey、Threadpool、commandGroupKey数据进行聚合
二、配置
1、集群(cluster)(turbine聚集数据的粒度)
说明:
turbine会对同一个集群下的相同的commandKey、Threadpool、commandGroupKey数据进行聚合。
通常,我们会将相同环境的相同微服务化为一个集群(如上),当然也可以设置成myserviceA-dev1,myserviceA-dev2这样的分别进行统计。
2、host连接配置(turbine连接hystrix-dashboard的url)
全局:
单个指定:
说明:
turbine的host链接指定的优先级:单个指定>全局,只有在某个集群没有单个指定的时候,才使用全局指定
3、server配置(InstanceDiscovery,用于指定某个集群下有哪些server要连接)
以上三者的关系:1指定常量(用在2和3中),2和3拼装成访问的url,如上,myserviceA-dev的turbine访问路径就是把11.0.11.11:8001/hystrix.stream和22.0.22.22:8001/hystrix.steam的metrics统计在一起,然后在turbineIP:turbinePORT/turbine/turbine.stream?cluster=myserviceA-dev下进行展示。
注意:turbine的访问路径下必须有cluster名字的指定,除非在配置文件中cluster使用default,如下:
![](https://images2015.cnblogs.com/blog/866881/201609/866881-20160901163622980-811827408.png)
这样的话,所有的服务都属于一个集群,我们把所有的机器实例配在instances处就可以。这样做的话,有几点疑问:
疑问1:要把所有的机器实例ip都配在instances部分,这样的话,每添加一个服务,都要在这里添加几个IP吗?这个是怎样做到自动化的?
疑问2:instanceUrlSuffix部分的端口设置为8001,这样的话,每一个服务都必须以8001端口启动才行?
疑问3:假设服务A和服务B中都有name为hello的commandKey,那这两个commandKey的metrics岂不是就会汇聚在一起,这样的话不是就不准确了吗?
参考:
https://github.com/Netflix/Turbine/wiki/Getting-Started-(1.x) https://github.com/Netflix/Turbine/wiki/Configuration-(1.x)
聚集同一个微服务的相同的commandKey、Threadpool、commandGroupKey数据进行聚合
二、配置
1、集群(cluster)(turbine聚集数据的粒度)
turbine.aggregator.clusterConfig=myserviceA-dev,myserviceA-prod,myserviceB-dev,myserviceB-prod
说明:
turbine会对同一个集群下的相同的commandKey、Threadpool、commandGroupKey数据进行聚合。
通常,我们会将相同环境的相同微服务化为一个集群(如上),当然也可以设置成myserviceA-dev1,myserviceA-dev2这样的分别进行统计。
2、host连接配置(turbine连接hystrix-dashboard的url)
全局:
turbine.instanceUrlSuffix=:7080/hystrix.stream
单个指定:
turbine.instanceUrlSuffix.myserviceA-dev=:8001/hystrix.stream
turbine.instanceUrlSuffix.myserviceA-prod=:8001/hystrix.stream
turbine.instanceUrlSuffix.myserviceB-dev=:8001/hystrix.stream
turbine.instanceUrlSuffix.myserviceB-prod=:8001/hystrix.stream
说明:
turbine的host链接指定的优先级:单个指定>全局,只有在某个集群没有单个指定的时候,才使用全局指定
3、server配置(InstanceDiscovery,用于指定某个集群下有哪些server要连接)
turbine.ConfigPropertyBasedDiscovery.myserviceA-dev.instances = 11.0.11.11,22.0.22.22
以上三者的关系:1指定常量(用在2和3中),2和3拼装成访问的url,如上,myserviceA-dev的turbine访问路径就是把11.0.11.11:8001/hystrix.stream和22.0.22.22:8001/hystrix.steam的metrics统计在一起,然后在turbineIP:turbinePORT/turbine/turbine.stream?cluster=myserviceA-dev下进行展示。
注意:turbine的访问路径下必须有cluster名字的指定,除非在配置文件中cluster使用default,如下:
![](https://images2015.cnblogs.com/blog/866881/201609/866881-20160901163622980-811827408.png)
这样的话,所有的服务都属于一个集群,我们把所有的机器实例配在instances处就可以。这样做的话,有几点疑问:
疑问1:要把所有的机器实例ip都配在instances部分,这样的话,每添加一个服务,都要在这里添加几个IP吗?这个是怎样做到自动化的?
疑问2:instanceUrlSuffix部分的端口设置为8001,这样的话,每一个服务都必须以8001端口启动才行?
疑问3:假设服务A和服务B中都有name为hello的commandKey,那这两个commandKey的metrics岂不是就会汇聚在一起,这样的话不是就不准确了吗?
参考:
https://github.com/Netflix/Turbine/wiki/Getting-Started-(1.x) https://github.com/Netflix/Turbine/wiki/Configuration-(1.x)
相关文章推荐
- Turbine实战
- Struts VS Turbine
- 在Turbine里使用Velocity
- springcloud(第五篇)springcloud turbine
- 史上最简单的SpringCloud教程 | 第十三篇: 断路器聚合监控(Hystrix Turbine)
- 服务容错保护断路器Hystrix之四:turbine集群监控
- Cloud中Hystrix仪表盘与Turbine集群监控
- 史上最简单的SpringCloud教程 | 第十三篇: 断路器聚合监控(Hystrix Turbine)
- springcloud(5):熔断监控Hystrix Dashboard和Turbine
- Turbine——Hystrix集群监控
- turbine下的数据库连接
- Struts VS Turbine
- turbine系统架构说明
- 第二十六章 hystrix-dashboard + turbine
- boot admin turbine
- springcloud微服务实战:Eureka+Zuul+Feign/Ribbon+Hystrix Turbine+SpringConfig+sleuth+zipkin
- Cloud中Hystrix仪表盘与Turbine集群监控
- spring cloud 的监控turbine-rabbitmq
- 4.Webx基础层次之Webx Turbine简介
- Spring Boot + Spring Cloud 构建微服务系统(六):熔断监控集群(Turbine)