Using the Dashboard
Page last updated:
To find the dashboard, navigate in Pivotal Cloud Foundry® 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:
$ 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.