Skip to content

Instantly share code, notes, and snippets.

@aparnachaudhary

aparnachaudhary/MicroServicesHealthCheck.adoc

Last active November 18, 2018 15:52
Show Gist options
  • Save aparnachaudhary/ccfc5c3ec72964f017e02d0ea3d19a53 to your computer and use it in GitHub Desktop.
Save aparnachaudhary/ccfc5c3ec72964f017e02d0ea3d19a53 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
MicroServicesHealthCheck.adoc

Liveness:

  • Include only those checks which you think, if fails, will get cured with a pod restart

  • Health-check endpoints are called frequently and within fixed intervals, therefore your latencies should ideally be small. Enforce an overall upper bound for your health-check response and make sure to cancel any pending checks to the downstream dependencies in case of timeout.

  • If you are performing multiple dependency checks over the network, try to process them concurrently, if possible, to reduce the overall response time.

Readiness:

  • Checks that would prevent faulty app from deployment e.g. wrong URL’s for depdenencies

  • Readiness probes should include the viability of connections to downstream services in their result when there isn’t an acceptable fallback if the downstream service is unavailable. This does not mean calling the health check provided by the downstream service directly, as infrastructure will be checking that for you. Instead, consider verifying the health of the existing references your application has to downstream services: this might be a JMS connection to WebSphere MQ, or an initialized Kafka consumer or producer. If you do check the viability of internal references to downstream services, cache the result to minimize the impact health checking has on your application.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment