turbine: + aggregator: + clusterConfig: CUSTOMERS + appConfig: customers+
From 53f499e20772366123beea6d22ec808e9f494a9a Mon Sep 17 00:00:00 2001
From: Dave Syer Environment.
The Config Service serves property sources from /{name}/{env}/{label}, where the default bindings are
The Config Service serves property sources from /{name}/{env}/{label}, where the default bindings in the
+client app are
You can extend the context hierarchy by simply setting the parent
context of any ApplicationContext you create, e.g. using its own
interface, or with the SpringApplicationBuilder convenience methods
-(parent(), child() and sibling()). Note that the
-SpringApplicationBuilder allows you to share an Environment
-amongst the whole hierarchy, but that is not the default. Thus,
-sibling contexts in particular do not need to have the same profiles
-or property sources, even though they will share common things with
-their parent. Every context in the hierarchy will have its own
-"bootstrap" property source (possibly empty) to avoid promoting values
-inadvertently from parents down to their descendants. Every context in
-the hierarchy can also (in principle) have a different
-spring.application.name and hence a different remote property source
-if there is a Config Server. Remember that properties from a child
-context override those in the parent.
parent(), child() and sibling()). The bootstrap context will be
+the parent of the most senior ancestor that you create yourself.
+Every context in the hierarchy will have its own "bootstrap" property
+source (possibly empty) to avoid promoting values inadvertently from
+parents down to their descendants. Every context in the hierarchy can
+also (in principle) have a different spring.application.name and
+hence a different remote property source if there is a Config
+Server. Normal Spring application context behaviour rules apply to
+property resolution: properties from a child context override those in
+the parent, by name and also by property source name (if the child has
+a property source with the same name as the parent, the one from the
+parent is not included in the child).
+Note that the SpringApplicationBuilder allows you to share an
+Environment amongst the whole hierarchy, but that is not the
+default. Thus, sibling contexts in particular do not need to have the
+same profiles or property sources, even though they will share common
+things with their parent.
Looking at an individual instances Hystrix data is not very useful in terms of the overall health of the system. Turbine is an application that aggregates all of the relevant /hystrix.stream endpoints into a combined /turbine.stream for use in the Hystrix Dashboard. Individual instances are located via Eureka. Running Turbine is as simple as annotating your main class with the @EnableTurbine annotation.
turbine.appConfig is a list of eureka serviceId’s that turbine will use to lookup instances. turbine.aggregator.clusterConfig is used to group instances together. This comes from the eureka InstanceInfo. The clusterName is a SPEL expression evaluated against the InstanceInfo. The default clusterNameExpression is appName. The turbine stream is then used in the Hystrix dashboard using a url that looks like: http://my.turbine.sever:8080/turbine.stream?cluster=CUSTOMERS
The cluster parameter must match an entry in turbine.aggregator.clusterConfig.
turbine: + aggregator: + clusterConfig: CUSTOMERS + appConfig: customers+
The clusterName can be customized by a SPEL expression in turbine.clusterNameExpression. For example, turbine.clusterNameExpression=aSGName would get the clustername from the AWS ASG name.