How it works
When defining your software architecture model using the client library, HTTP-based health checks can be added to the Container Instances in your deployment model. Each health check is defined by a name, an endpoint URL, a polling interval (e.g. 60 seconds), a timeout (e.g. 1000 milliseconds), and optionally one or more HTTP headers.
When the workspace is loaded into your web browser, the health checks are executed and the results are summarised by colour coding the diagram elements (red, amber, green) and indicating the percentage of the health checks that have passed for each element.
The health checks are executed from within your web browser, so HTTPS URLs must be used (rather than plain HTTP).
Also, the response sent back from your servers must include the
to allow the cross-origin request to be made. Returning anything other than a HTTP 200 status code will cause the health check to be marked as failed.
The health check endpoints can either be existing endpoints, or custom ones that you build into your applications. For example, you could add a
/health endpoint to an existing
web application that simply returns a HTTP 200 response to indicate that it's okay. Alternatively, you could build a more complex collection of health endpoints that check whether the
back-end data stores are accessible.
The health check feature is not designed to replace monitoring systems such as Pingdom, New Relic, Nagios, etc. Instead, it can be used to augment existing information radiators and dashboards, to provide an "at a glance" view of whether the software system is running and which parts are down in the event of a failure. It can also be used in diagnosing problems with a given deployment environment.