Using the Dashboard

To find the dashboard, navigate in Pivotal Web Services Apps Manager to the Circuit Breaker Dashboard service instance’s space, click the listing for the service instance, and then click Manage.

If you are using version 6.8.0 or later of the Cloud Foundry Command Line Interface (cf CLI), you can also use cf service SERVICE_NAME, where SERVICE_NAME is the name of the Circuit Breaker Dashboard service instance:

$ cf service circuit-breaker-dashboard

Service instance: circuit-breaker-dashboard
Service: p-circuit-breaker-dashboard
[...]
Dashboard: https://spring-cloud-broker.apps.example.com/dashboard/p-circuit-breaker-dashboard/97869d78-5d4e-410b-9c71-bb622ca49f7d

Visit the URL given for “Dashboard”.

To see breaker statuses on the dashboard, configure an app as described in Writing Client Applications, using @HystrixCommand annotations to apply circuit breakers. Then push the app and bind it to the Circuit Breaker Dashboard service instance. Once bound and restaged, the app will update the dashboard with metrics that describe the health of its monitored service calls.

With the “Agency” example app (see the “traveler” repository) receiving no load, the dashboard displays the following:

To see the circuit breaker in action, use curl, JMeter, Apache Bench, or similar to simulate load.

$ while true; do curl agency.example.com; done

With the Company app running and available via the Service Registry instance (see Writing Client Applications), the Agency app responds with a guide name, indicating a successful service call. If you stop Company, Agency will respond with a “None available” message, indicating that the call to its getGuide() method failed and was redirected to the fallback method.

When service calls are succeeding, the circuit is closed, and the dashboard graph shows the rate of calls per second and successful calls per 10 seconds.

When calls begin to fail, the graph shows the rate of failed calls in red.

When failures exceed the configured threshold (the default is 20 failures in 5 seconds), the breaker opens the circuit. The dashboard shows the rate of short-circuited calls—calls which are going straight to the fallback method—in blue. The app is still allowing calls to the failing method at a rate of 1 every 5 seconds, as indicated in red; this is necessary to determine if calls are succeeding again and if the circuit can be closed.

With the circuit breaker in place on its getGuide() method, the Agency example app never returns an HTTP status code other than 200 to the requester.