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
Bound apps:
Tags:
Plan: standard
Description: Circuit Breaker Dashboard for Spring Cloud® Applications
Documentation url: http://docs.pivotal.io/spring-cloud-services/
Dashboard: https://spring-cloud-broker.apps.wise.com/dashboard/p-circuit-breaker-dashboard/97869d78-5d4e-410b-9c71-bb622ca49f7d

Last Operation
Status: create succeeded
Message:
Started: 2016-06-29T19:13:13Z
Updated: 2016-06-29T19:16:19Z

Visit the URL given for “Dashboard”.

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

With the “Agency” example application (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.wise.com; done

With the Company application running and available via the Service Registry instance (see the Writing Client Applications topic), the Agency application 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 application 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 application never returns an HTTP status code other than 200 to the requester.