{
+ "status":"UP"
+}If you don’t use HTTPS and user credentials, SSH should also work out
+of the box when you store keys in the default directories (~/.ssh)
+and the uri is points to an SSH location,
+e.g. "git@github.com:configuration/cloud-configuration". The
+repository is accessed using JGit, so any documentation you find on
+that should be applicable.
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.
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. All of the documented configuration properties from the Turbine 1 wiki apply. The only difference is that the turbine.instanceUrlSuffix does not need the port prepended as this is handled automatically unless turbine.instanceInsertPort=false.
Configuration key turbine.appConfig is a list of eureka serviceId’s that turbine will use to lookup instances. The turbine stream is then used in the Hystrix dashboard using a url that looks like: http://my.turbine.sever:8080/turbine.stream?cluster=<CLUSTERNAME>; (the cluster parameter can be omitted if the name is "default"). The cluster parameter must match an entry in turbine.aggregator.clusterConfig. Value returned from eureka are uppercase, thus we expect this example to work if there is an app registered with Eureka called "customers":
On the server side Just create a Spring Boot application and annotate it with @EnableTurbineAmqp and by default it will come up on port 8989 (point your Hystrix dashboard to that port, any path). You can customize the port using either server.port or turbine.amqp.port. If you have spring-boot-starter-web and spring-boot-starter-actuator on the classpath as well, then you can open up the Actuator endpoints on a separate port (with Tomcat by default) by providing a management.port which is different.
You can then point the Hystrix Dashboard to the Turbine AMQP Server instead of individual Hystrix streams. If Turbine AMQP is running on port 8989 on myhost, then put http://myhost:8989 in the stream input field in the Hystrix Dashboard. Circuits will be prefixed by their respective serviceId, followed by a dot, then the circuit name.
Spring Cloud provides a spring-cloud-starter-turbine-amqp that has all the dependencies you need to get a Turbine AMQP server running. You need Java 8 to run the app because it is Netty-based.
maps all paths in "/api/**" to the Zuul filter chain.
Do you have non-jvm languages you want to take advantage of Eureka, Ribbon and +Config Server? The Spring Cloud Netflix Sidecar was inspired by +Netflix Prana. It includes a simple http api +to get all of the instances (ie host and port) for a given service. You can +also proxy service calls through an embedded Zuul proxy which gets its route +entries from Eureka. The Spring Cloud Config Server can be accessed directly +via host lookup or through the Zuul Proxy. The non-jvm app should implement +a health check so the Sidecar can report to eureka if the app is up or down.
+To enable the Sidecar, create a Spring Boot application with @EnableSidecar.
+This annotation includes @EnableCircuitBreaker, @EnableDiscoveryClient,
+and @EnableZuulProxy. Run the resulting application on the same host as the
+non-jvm application.
To configure the side car add sidecar.port and sidecar.health-uri to application.yml.
+The sidecar.port property is the port the non-jvm app is listening on. This
+is so the Sidecar can properly register the app with Eureka. The sidecar.health-uri
+is a uri accessible on the non-jvm app that mimicks a Spring Boot health
+indicator. It should return a json document like the following:
{
+ "status":"UP"
+}Here is an example application.yml for a Sidecar application:
+server:
+ port: 5678
+spring:
+ application:
+ name: sidecar
+
+sidecar:
+ port: 8000
+ health-uri: http://localhost:8000/health.jsonThe api for the DiscoveryClient.getInstances() method is /hosts/{serviceId}.
+Here is an example response for /hosts/customers that returns two instances on
+different hosts. This api is accessible to the non-jvm app (if the sidecar is
+on port 5678) at http://localhost:5678/hosts/{serviceId}.
[
+ {
+ "host": "myhost",
+ "port": 9000,
+ "uri": "http://myhost:9000",
+ "serviceId": "CUSTOMERS",
+ "secure": false
+ },
+ {
+ "host": "myhost2",
+ "port": 9000,
+ "uri": "http://myhost2:9000",
+ "serviceId": "CUSTOMERS",
+ "secure": false
+ }
+]The Zuul proxy automatically adds routes for each service known in eureka to
+/<serviceId>, so the customers service is available at /customers. The
+Non-jvm app can access the customer service via http://localhost:5678/customers
+(assuming the sidecar is listening on port 5678).
If the Config Server is registered with Eureka, non-jvm application can access
+it via the Zuul proxy. If the serviceId of the ConfigServer is configserver
+and the Sidecar is on port 5678, then it can be accessed at
+http://localhost:5678/configserver
Non-jvm app can take advantage of the Config Server’s ability to return YAML +documents. For example, a call to http://sidecar.local.spring.io:5678/configserver/default-master.yml +might result in a YAML document like the following
+eureka:
+ client:
+ serviceUrl:
+ defaultZone: http://localhost:8761/eureka/
+ password: password
+info:
+ description: Spring Cloud Samples
+ url: https://github.com/spring-cloud-samples